لا يمكنني العثور عليه في الوثائق الآن ، لكنني أتذكر شرحًا على غرار الأسطر التالية:
IPFS هو نظام ملفات ولأنظمة الملفات تستخدم المسارات بدلاً من عناوين URL. يمكن فهم عناوين URL على أنها قبح يمثل فشلًا في توحيد الوصول على جهازك المحلي وعلى الأجهزة البعيدة. يتجنب IPFS هذا القبح من خلال التعامل مع الملفات المحلية والبعيدة بنفس الطريقة وطريقة معالجة الملفات هي مسار قياسي.

قد يكون من المفيد تخيل تركيب IPFS بالكامل ضمن / ipfs ثم الوصول إلى الملفات كما هي: الملفات في نظام الملفات الخاص بك.

مواد قراءة إضافية:

مناقشة طويلة: https://github.com/ipfs/go-ipfs/issues/1678
ملخص قصير للإجماع الحالي: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

أيضًا ، هناك عمل مستمر للتوفيق بين عناوين IPFS المطلقة مع دقة عنوان URL القياسية ومعالجة تحديد الأصول باستخدام (أو بدون؟) مسارات fs:.

و https://github.com/ipfs/in-web-browsers/issues/28 مع رابط لمسودة المواصفات. سي سي lgierth

:( بعد قراءة ipfs / go-ipfs # 1678 ، لست متأكدًا حتى مما إذا كنت مهتمًا بـ IPFS بعد الآن :(. كان هذا عدم نقاش رهيب.

أنا حقًا لا أريد أن أدخل إلى مقصورة الدراجة ، لكن هذا

It might help to imagine mounting the entire IPFS under /ipfs and then accessing the files like they are just that: Files in your file system.
ليست فكرة تثيرني. أتخيل فجأة وجود جذر نظام يبدو
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

هذا ليس مفهوم يروق لي. أنا معتاد على تنظيم نظامي بالطريقة التي أحبها وتركيب أنظمة الملفات الخاصة بي على النحو الذي أختاره. لكن هذا ليس حقًا ما يطفئني. أنت حر في تحميل ipfs أينما تريد. لقد أزعجني نهج جنون العظمة "فلنعيد ابتكار كل شيء". لقد جئت إلى IPFS لأنني أردت توزيع CAS. هذا كل ما كنت مهتمًا به. لا يهمني دمج يونكس مع الويب. ولكن بعد قراءة هذا النقاش ، لم يعد IPFS يبدو كمنتج سيساعدني في الحصول على CAS الموزع ، يبدو أنه منتج سيحدد كيفية استخدام ومساحة اسم نظام ملفات الكمبيوتر الخاص بي وبمجرد أن يملي المؤلفون شيئًا واحدًا ، ربما سيكون لديهم بعض الأفكار الجديدة الأخرى حول كيفية تكوين جهاز الكمبيوتر الخاص بي وتنظيمه. لا أستطيع التنبؤ بالمستقبل ، لكني لا أحب النهج.

هذا سيء للغاية ، لأنني أحب تطبيق CAS الموزع لـ IPFS. لقد كنت أحلم بامتلاك CAS موزعة لفترة طويلة :(. لذلك سأعود إلى وضع البحث وإلقاء نظرة على بعض الحالات الأخرى الموزعة ...

timthelion أراك (مثلي تمامًا) تهتم حقًا بـ CAS و IPFS.
سأبذل قصارى جهدي لتخفيف همومك.

أنا متأكد تمامًا من أنه يمكنك استخدام IPFS باعتباره CAS دون تثبيته في أي مكان في نظامك ، على الإطلاق.
الطريقة التي أفكر بها في مسارات /ipfs/Qm.. هي أنها مجرد اختصار ذهني يبسط المحادثات والربط (تمامًا مثل عناوين URL العادية).

أنا شخصياً أوافق على أن موقف "معالجات البروتوكول" و "دلالات العنوان المتعارف عليه" قد يبدو وكأنه فوضى بالنسبة لأحد المارة في الوقت الحالي ، لكن الأشخاص الطيبين يعملون على حلول عملية قد تعمل في الوقت الحالي (على سبيل المثال ، https://github.com/ ipfs / متصفحات الويب / المشكلات / 3 ، https://github.com/ipfs/in-web-browsers/issues/7).

هذه محادثة مستمرة وهذه الأشياء تستغرق وقتًا.

الاتجاه العام للمشروع (رأيي الشخصي) هو _ "صنع أدوات مفيدة تعيد استخدام معايير الصناعة حيث يكون من العملي فعل ذلك" _ بدلاً من _ "إعادة اختراع كل شيء مهما كان" _.

لا أعتقد أنه يجب أن تقلق بشأن المستقبل. تتبع أدوات IPFS _ "طريقة unix" _ ، مما يعني أن العديد من الأدوات والمكتبات والأوامر الصغيرة (على غرار الأوامر الفرعية git ) التي تقوم بشيء واحد يمكن ربطها معًا لبناء شيء أكبر.

أنت من يقرر القطع التي سيتم استخدامها. ⚙️ 🔧

آمل ألا يأخذ أي شخص آخر مشاركة لي بطريقة خاطئة. لا أقصد أن أقول "أنتم جميعًا ثقوب الحمار سأرحل عنها". أفترض أن الآلاف من الأشخاص قد ألقوا نظرة على IPFS ، وقرروا أنهم لا يحبون شيئًا ما ، وغادروا ، دون أن أكتب أبدًا لماذا ... غالبًا ما أفعل ذلك. أنا فقط أنظر بشكل عرضي إلى تقنية وأختار تقنية مختلفة بناءً على بعض التفاصيل الصغيرة التي تفركني بطريقة خاطئة. قررت عدم القيام بذلك لأنني أردت ألا أكون عضوًا صامتًا في الأغلبية الصامتة ، وأيضًا ، لأنه ليس لدي الكثير من الخيارات الأخرى: D ، ولكن يبدو أنني سأضطر إلى الانتظار حتى ipfs لدعم fs: // أو أيًا كان ما يختاره رؤساء المشروع قبل أن أبدأ في استخدام ipfs في مشروعي الحالي وسأكون قادرًا بجدية فقط على البدء في البحث في IPFS حتى توجد بعض عناوين URL العادية الحقيقية.

لقد أزعجني نهج جنون العظمة "فلنعيد ابتكار كل شيء".

لقد كنت منجرفًا ، فلا شيء بخصوص هذا "مصاب بجنون العظمة" أو حتى إعادة اختراع. نحن نتحدث عن مسارات الملفات التي يتم استخدامها كما هي دائمًا. كان التثبيت على / ipfs مجرد مثال لتوضيح الأشياء ، وليس الفكرة الأساسية.

أنا معتاد على تنظيم نظامي بالطريقة التي أحبها وتركيب أنظمة الملفات الخاصة بي على النحو الذي أختاره.

لا أحد يفرض عليك تحميل IPFS كنظام ملفات محلي timthelion . هذه ميزة يمكنك استخدامها ويمكنك تحديد المسارات التي يتم تثبيتها. يبدو لي عدم الإعجاب بالميزة المعطلة افتراضيًا سببًا ضعيفًا لرفض IPFS ككل. لكن حسنًا ، أتمنى أن تغير رأيك في المستقبل وتنضم إلينا مرة أخرى.

لم أر منتجًا واحدًا حيث يحب الجميع كل ميزة.

تجدر الإشارة أيضًا إلى أن هذا لا يعني إعادة اختراع أي شيء في الواقع. إنه شيء "غير مبتكر".

بغض النظر عن آرائنا المختلفة ، فإن المعالج fs:// - الذي سيمنحك الدعم السلس الذي تريده - يتم تنفيذه كما نتحدث ، ويمكنك بالفعل استخدامه مع ملحقات المتصفح . نحن نعمل أيضًا على تطبيقات PoC للسماح للمتصفحات باستخدامه محليًا. يمكنك أيضًا تنفيذ الدعم لها في التطبيقات المغلفة بالإلكترون. ربما يمكنك المساهمة في هذه الجهود لجعلها أسرع.

"لقد كنت منجرفًا ، لا شيء في هذا الأمر" مصاب بجنون العظمة "أو حتى إعادة اختراع".

أفسر https://github.com/multiformats/multiaddr على أنه مهووس بالجنون وإعادة اختراع. إنه تنسيق مختلف عن عنوان URL ولكنه يمثل نفس البيانات. أنت بحاجة إلى سبب وجيه لإعادة اختراع مثل هذا المعيار المهم.

سأكون أكثر تفصيلاً قليلاً.

"نحن نتحدث عن استخدام مسارات الملفات كما هي دائمًا."

أعتقد أنني وصلت إلى حيث تتجهون مع هذه الفكرة يا رفاق. هل "الخطأ" الذي تحاول إصلاحه هو حقيقة أنه لا يمكنك التعامل مع موارد الويب مثل الملفات العادية؟ مثل ذلك لا أستطيع أن أفعل cat http://google.com/index.html ؟ أستطيع أن أتفق معك في أنه من المحزن أن هذا مستحيل. إذا كنت سأكتب نظام تشغيل ، فسأجعل وظيفة open قادرة على فتح عناوين URL للملفات. ربما يمكن إجراء مثل هذا التغيير على لينكس. نهجك مختلف ، فأنت تحاول إدراج موارد الويب في التسلسل الهرمي لملفات POSIX. إذا كان هناك سبب آخر يجعلك تعتقد أن عناوين URL خاطئة ، فيرجى إبلاغي بذلك.

يمكنني بالتأكيد أن أتعاطف مع هدفك المتمثل في جعل موارد الويب تعمل كملفات عادية. ومع ذلك ، يبدو أن طريقتك في إصلاح "الخطأ" منحدر زلق تمامًا. إذا اخترت تثبيت أنظمة ملفات ipfs ، فإن نقطة التحميل الخاصة بهم هي سلوك جديد بالنسبة لي. لا يمكنني التفكير في أي برنامج وضع مستخدم آخر يمكنني تثبيته على نظامي ، والذي من شأنه إنشاء أدلة متعددة مباشرة في الدليل الجذر الخاص بي.

اليوم ، عندما أفعل ls / أحصل على:

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/

مع المسارات التي اقترحها Multiaddr أود أن أرى بدلاً من ذلك:

$ ls / bin/ bitcoin/ boot/ dev/ dns/ dns4/ dns6/ etc/ home/ http/ https/ initrd.img@ ipfs/ lib/ lib64/ libp2p-circuit-relay/ libp2p-webrtc-direct/ libp2p-webrtc-star/ media/ mnt/ onion/ opt/ p2p/ proc/ root/ run/ sbin/ sctp/ srv/ sys/ tmp/ udt/ unix/ usr/ utp/ var/ vmlinuz@
https://github.com/multiformats/multiaddr/blob/master/protocols.csv

وقبل أن تتهمني بإساءة تفسير المعيار ، سأذكّرك بأنني أفسرها بنفس الطريقة التي تم بها تفسير مسارات يونكس دائمًا.

من الواضح أنني لن أرغب في إحداث مثل هذه الفوضى في دليل الجذر الخاص بي. لذلك ، سأختار عدم ركوب هذه المسارات.

في حالتي ، هذا ليس خياري على أي حال ، أريد كتابة برنامج يستخدم IPFS وليس قراري ما إذا كان المستخدم يقوم بتركيب تلك المسارات أم لا. ولكني ما زلت أريد أن يتمكن المستخدمون من فتح ملف مشترك عبر IPFS بنفس السهولة التي يستطيعون بها ملفًا على أجهزتهم المحلية. فكيف أكتب هذا الرمز؟ إذا استخدمت ipfs عناوين url القياسية ، فسأقوم ببساطة بإعادة توجيه أي شيء بدأ بـ ipfs: // إلى ipfs وسيكون كل شيء بسيطًا.

ولكن عندما ينظر برنامجي إلى سلسلة تبدأ بـ / فإنه يفسر ذلك على أنه مسار مطلق لملف أو دليل على جهاز بعض الهيئات ، وعادةً ما يكون الجهاز الذي يعمل عليه الرمز. إذا طُلب منه زيارة مسار يبدأ بـ / ، فسيقوم بالتأكيد بتفسيره على أنه مسار مطلق لملف أو دليل على الجهاز المحلي. إذا لم يكن /ipfs موجودًا على جهازي ، فيجب على البرنامج إرجاع خطأ لم يتم العثور على الملف. لا يمكنني التفكير في مثال آخر حيث يؤدي المسار المطلق الذي يُطلب من البرنامج زيارته إلى مكان آخر غير الملف أو الدليل على الجهاز المحلي. بالنسبة لي ، بصفتي مستخدمًا / مطورًا لنظام Linux لفترة طويلة ، هذا سلوك جديد.

إذا حاول تطبيقي إضافة دعم لـ multiaddr ، فستصبح الأمور سريعة جدًا. ماذا لو قام المستخدم بتشغيل:

$tims-program-that-supports-normal-files-as-well-as-multiaddr /http/index.html
؟

ويحدث أن يكون لدى المستخدم خادم ويب يخزن ملفات html في /http . لم يسمع به على الإطلاق. هل يجب على برنامجي حل هذا إلى عنوان متعدد العناوين أو الملف المحلي؟

لقد قمت بالفعل بكتابة بعض التعليمات البرمجية بدعم بدائي لفتح عناوين URL في بيثون. القيام بذلك كان سهلا جدا. ولكن كيف يمكنني تغيير الكود الخاص بي بحيث يحل بشكل لا لبس فيه كلاً من مسارات multaddr ومسارات الملفات المحلية؟

if filename.startswith( "http://" ) or filename.startswith( "https://" ): import urllib.request try: with urllib.request.urlopen(filename) as webgraph: self.json = webgraph.read().decode("utf-8") except urllib.error.URLError as e: raise OSError(str(e)) else: try: with open(filename) as fd: self.json = fd.read() except FileNotFoundError: pass

أنا حقا لا أعتقد أن هذا ممكن. لذلك ، بقيت مع عدم تنفيذ دعم multaddr ودعم عناوين URL العادية فقط. يبدو هذا جيدًا في البداية ، لكن مستخدمي ipfs سيتعرضون باستمرار لعناوين multaddr لكائنات ipfs ، وسوف يدعي برنامجي ، الذي يعلن عن دعم IPFS ، أن هذه المسارات غير موجودة. لذلك ، بغض النظر عن كيفية تنفيذ الدعم ، سيتم كسر برنامجي. إما سيتم كسر دعمها لـ ipfs ، أو سيتم كسر دعمها لنظام ملفات POSIX القياسي.

هناك طرق يمكن من خلالها إصلاح هذا الأمر. قد يكون أحدها أن تتخلى عن مولتيدير بالكامل. قد يكون الآخر هو تغيير متعدد العناوين بحيث يقتصر على الأقل على تلك المسارات في دليل فرعي واحد. لذا فبدلاً من كتابة /ipfs/hash/blah يكتب المرء /webfs/ipfs/hash/blah . وسيعود ls / :

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/ webfs/

سيكون هذا شيئًا يمكنني العيش معه ، وربما حتى التخلف عنه. لكن الوضع الحالي هو أنني لا أعرف أي طريقة مرضية لتنفيذ دعم ipfs على الإطلاق.

اسمحوا لي أن أحصل على مثال أكثر واقعية. تخيل أنني أكتب برنامجًا يحول تخفيض السعر إلى PDF. وأريد أن أكون قادرًا على دعم إدراج الصور من IPFS. لذلك يكتب المستخدم:

العلية
""

الأشياء التي وجدتها في العلية

صندوق قديم من الصخور.

""

ويدير

$ tims-md-to-pdf-with-ipfs-support attic.md > attic.pdf

كيف يفترض أن يحل برنامجي مسارات الصور تلك؟ هل يفترض أن نظام الملفات /ipfs مركب؟ لقد اتفقنا بالفعل على عدم إجبار المستخدمين على تحميل /ipfs . هل يجب أن يتعامل البرنامج مع /ipfs/ كبادئة خاصة؟ هذا يبدو غريبًا ومنكسرًا. هل يجب أن يدعم البرنامج fs:// فقط ويعيد الخطأ ، الملف غير موجود في ظل هذه المسارات؟ هذا يبدو معقولًا ، ولكنه سيخلط بين المستخدمين الذين اعتادوا على معيار multaddr. ليس هناك طريقة صحيحة للخروج من الحقيبة! : / :(

تم تحريره للتوضيح

نشكرك على تقديم بعض حالات الاستخدامimthelion. إنه لأمر رائع أن يقدم الأشخاص أمثلة من العالم الواقعي حتى نتمكن من التأكد من أن البروتوكولات تعمل مع أشخاص حقيقيين.

توضيح مثال "تركيب كل شيء في /"

كما أشار lidel ، يعمل الأشخاص حاليًا على تصميم مخطط العناوين ، لذلك لا توجد وثائق حتى الآن. يبدو أن مثالjbenet لحوامل نظام الملفات قد تسبب في حدوث ارتباك. إنه مجرد مثال يهدف إلى مساعدة الناس على التفكير من خلال النموذج المفاهيمي وراء مخطط العنوان fs: أو dweb: . إنه لا يقترح أن نجبر الجميع على تحميل كل تلك الأدلة على أنظمة الملفات الخاصة بهم. بدلاً من ذلك ، يقترح أنه يجب أن نكون قادرين على _ تحديد_المحتوى بعناوين تتصرف مثل المحتوى مثبت على نظام الملفات المحلي الخاص بك ، لأن ذلك سيسمح لنا بالتفاعل مع محتوى الويب / dweb باستخدام أدوات unix / posix.

عندما نكتب المستندات ، سيتعين علينا توخي الحذر لتوضيح ذلك. شكرا لك على وضع علامة عليه.

للإجابة على مثال "الأشياء الموجودة في العلية" ، أعتقد أن الفكرة هي أنك ستستخدم fs:/ في روابطك ، على النحو التالي:

Stuff I found in my attic
----------------------------------

![An old box of rocks](fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV)

An old box of rocks.

![A can of oil for water-proofing leather](fs:/ipfs/QmUPC5xbVtu6NxMwFBtmWVjrVM3XffuPtSMLpmDFGfTaKG)

وجود عناوين بسيطة وتوحيد المخططات

ملاحظة جانبية: هناك أيضًا مشكلة إبقاء العناوين بسيطة. في هذا التعليق ، اقترح nicola طريقة ذكية لدعم العناوين ipfs:/ و ipns:/ بدون الخروج من مخطط العناوين fs: / dweb: . تعتبر الجمباز في تصميم البروتوكول (IMHO) مربكة بشكل غريب ، ولكن في النهاية ستسمح لك بالحصول على روابط في تخفيض السعر مثل ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV بينما تسمح أيضًا للأشخاص بمعالجة نفس المحتوى مثل fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV أو فقط /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV في سياق unix / posix.

تعتمد المسارات المطلقة على السياق

في الدروب المطلقة ، قلت:

إذا طُلب منه زيارة مسار يبدأ بـ / ، فسيقوم بالتأكيد بتفسيره على أنه مسار مطلق لملف أو دليل على الجهاز المحلي.

ضع في اعتبارك أن هناك سابقة كبيرة لكون المسارات المطلقة مرتبطة بـ _context_ بدلاً من ارتباطها بجذر نظام الملفات. المثال الأكثر شيوعًا على ذلك هو المسارات المطلقة في HTML ، والتي ترتبط بجذر origin الحالي ، وليست مرتبطة بجذر نظام ملفات الخادم. إذا كان لدي رمز يعمل ضمن سياق يفترض أن جميع المسارات هي fs: أو dweb: ، فإنه صالح تمامًا لهذا الرمز لاستخدام العناوين التي تبدأ بـ /ipfs/ وهناك الكثير من الطرق لهذا الكود لحل المسارات بدون تركيب ipfs حرفيًا بسعر /ipfs على نظام الملفات الخاص بك.

هذه هي 2 سنتي:

• كل ملف أقل من fs:/ ، بنفس الطريقة التي يكون بها كل مجال أقل من http:/ .
• لا أقوم بتثبيت نظام اسم المجال على / على نظام الملفات الخاص بي ، بالطريقة نفسها التي لا أقوم فيها بتثبيت IPFS بالكامل على / . في كلا النظامين ، النقطة المرجعية هي / بالنسبة إلى المخطط ( http:/ ، fs:/ ).

أعتقد في معظم الأمثلة الخاصة بك أن هناك فكرة مفادها أن كل نظام ملفات قد قام بتثبيت ipfs على / . لذا فإن الحصول على fs:/ لا يكسر تنسيق URI.

بدلاً من ذلك ، يقترح أنه يجب أن نكون قادرين على تحديد المحتوى بالعناوين التي تتصرف مثل المحتوى المركب على نظام الملفات المحلي الخاص بك ، لأن ذلك سيسمح لنا بالتفاعل مع محتوى الويب / dweb باستخدام أدوات unix / posix.

"سيسمح لنا ذلك بالتفاعل مع محتوى الويب / dweb باستخدام أدوات unix / posix." هل يمكنك إعطائي مثالًا ملموسًا لحالة يتم فيها استخدام البنية غير المسبوقة بـ fs: مع أداة يونكس؟ بطريقة ما ، ما زلت لا أفهم.

لقد حاولت أن أتوصل إلى مثال بنفسي ، لكن لا يمكنني التفكير في أي أمثلة يكون فيها بناء الجملة المتوافق مع العنوان المتعدد /ipfs منطقيًا.

حاولت أن أجعل مُجمّعًا يتنقل إلى الأداة المساعدة diff في bash التي تدعم ipfs باستخدام مخطط multiaddr:

""
timothyyoga ~ / c / ipfs-multiaddr> cat multiaddr-diff

! / بن / باش

get_multiaddr_or_normal_file_getter () {
إذا [[$ 1 == / ipfs / *]] ؛
ومن بعد
file_getter = "ipfs cat $ 1"
آخر
file_getter = "قطة $ 1"
فاي
صدى $ file_getter
}

file1 = get_multiaddr_or_normal_file_getter $1
file2 = get_multiaddr_or_normal_file_getter $2

فرق <($ file1) <($ file2)
""

يعمل في حالة السذاجة على كل من الملفات العادية وملفات ipfs:

""
تيموثي yoga ~ / c / ipfs-multiaddr>
./multiaddr-diff ../subuser/COPYING.LGPL / ipfs / QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a 128،130

و) تضحي بطفلك البكر للإله لوراث في الأول
اكتمال القمر للسنة الزوجية التالية.

""

ولكن عندما حاولت استخدامه للعمل على ملف موجود بالفعل في دليل /ipfs/ الذي قمت بإنشائه ، يظهر لي خطأ:

timothy<strong i="39">@yoga</strong> ~/c/ipfs-multiaddr> su Password: root<strong i="40">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# mkdir /ipfs/ root<strong i="41">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# echo "foo">/ipfs/foo root<strong i="42">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# exit exit timothy<strong i="43">@yoga</strong> ~/c/ipfs-multiaddr> ./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/foo Error: selected encoding not supported ....

لست متأكدًا من كيفية تحرير هذه الأداة ، بحيث تكون قادرة على العمل بشكل موثوق مع كل من عناوين multaddr وملفات unix العادية.

من ناحية أخرى ، فإن إنشاء غلاف مختلف يدعم فقط sytax نمط url ليس بالأمر الصعب:

""
timothyyoga ~ / c / ipfs-multiaddr> cat url-syntax-diff

! / بن / باش

get_multiaddr_or_normal_file_getter () {
إذا [[$ 1 == fs: *]] ؛
ومن بعد
بادئة = "fs:"
Internal_path = $ {1 # $ بادئة}
file_getter = "ipfs cat $ internal_path"
آخر
file_getter = "قطة $ 1"
فاي
صدى $ file_getter
}

file1 = get_multiaddr_or_normal_file_getter $1
file2 = get_multiaddr_or_normal_file_getter $2
صدى $ file1
صدى $ file2
فرق <($ file1) <($ file2)
""

إنه يعمل أيضًا ، ومن المؤكد أن الأحرف الثلاثة الإضافية لن تحدث فرقًا كبيرًا عندما يكون حجم التجزئة عبارة عن قطعة مكونة من bazillion ونصف حرف.

""
تيموثي yoga ~ / c / ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs: / ipfs / QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
قط ../subuser/COPYING.LGPL
ipfs cat / ipfs / QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a 128،130

و) تضحي بطفلك البكر للإله لوراث في الأول
اكتمال القمر للسنة الزوجية التالية.

تيموثي yoga ~ / c / ipfs-multiaddr>
""

وفي حالات الحواف الغريبة ، يتم تشكيلها بشكل مثير للإعجاب كما يتوقع المرء من أداة POSIX المصقولة جيدًا.

""
timothyyoga ~ / c / ipfs-multiaddr> صدى "bar"> bar
timothyyoga ~ / c / ipfs-multiaddr> ./url-syntax-diff bar / ipfs / foo
شريط القط
cat / ipfs / foo
1c1

<شريط

فو
""

منذ المناقشة على fs: و dweb: يبدو أنه لا ينتهي أبدًا ، ما زلت بحاجة إلى بعض المدخلات على هذا العلاقات العامة: https://github.com/ipfs/specs/pull/139

استخدام ipfs: في هذه الأثناء يحل الكثير من المشكلات ، على الأقل بالنسبة لي.

pawal Sigh ، عندما رأيت تعليقك غرق قلبي ، لأنني كنت أنتظر الرد على مخاوفي بفارغ الصبر.

بينغ jbenet

أنا مهتم أيضًا بالردود على مشاركتك السابقة لأنها سلطت الضوء على منظور حول المشكلة لم أكن على دراية بها من قبل.

// تحرير: هذا يعني أنني ما زلت أتابع المشكلة وكنت سأجيب إذا كان لدي إجابة مرضية.

+1

اجعل "ipfs: //" تعمل - كمعيار. لو سمحت.

(لذلك يمكن أن تفترض جميع تطبيقاتنا أنها تعمل على جميع الأنظمة الأساسية وفي كل مكان -
في أي مكان وعلى بطاقات العمل)

شكرا.

جوليان سميث
Blockfreight ™

المناقشات حول ipfs: مقابل fs: مقابل dweb: هي مناقشة مربكة كانت مستمرة منذ قبل أن أشارك في هذا المشروع. لقد حصلت أخيرًا على بعض الوقت لأفكر في الأمر أثناء IPFS في Web Browsers Sprint . أنا أكتب شرحًا للصورة بأكملها ، مع مخطط تفصيلي للخيارات والحجج المختلفة ، التي سأقدمها كعلاقات عامة على ipfs / specs في وقت لاحق اليوم. سأقوم بتضمين أمثلة ومراجع للمناقشات التي أعرف عنها. نأمل أن يوفر ذلك بعض الوضوح ويسمح لنا بالمضي قدمًا على طول المسار الأكثر واقعية دون ارتكاب أي أخطاء تسبب مشاكل كبيرة على المدى الطويل.

لقد اتخذت خطوة أولية في تقديم خلفية لهذه المناقشات هنا: https://github.com/ipfs/specs/pull/152 يرجى تحديث العلاقات العامة بمعلومات غير دقيقة أو غير كاملة أو تريد بشكل عام التحسين.

آسف لجهلي ، ولكن كيف أقوم بتحديث PR؟

timthelion يمكنك فعل ذلك مثل jbenet وإضافة تعليقات هنا أو يمكنك استنساخ الريبو أو الخروج من الفرع أو التعديل أو الالتزام أو إرسال التصحيح وما إلى ذلك

@ vasa-Develop لأن تعليقك لا يشرح في الواقع كيف يعمل البرنامج على تحسين الموقف ، فأنا أعتبره بريدًا عشوائيًا.

ماذا عن DID URIs؟ مثل did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

المعرفات اللامركزية (DIDs)

اضطرابات الشخصية الانفصامية هي معرفات للأشخاص . ومع ذلك ، في جوهرهم ، هم في الواقع URN (أعتقد؟) لذا فإن السؤال الأفضل هو: "لماذا لا URNs"؟

حقًا ، الإجابة هي أنه في حين أن عناوين URL تمنحنا توافقًا مع المستعرض ، فإن المسارات تمنحنا توافق نظام الملفات (من بين أشياء أخرى) ، لكن URN لا تمنحنا حقًا الكثير بخلاف بعض النوايا الحسنة مع بعض الهيئات المعيارية.

ملاحظة: لقد استسلمنا بالفعل لموضع URL للحصول على توافق المتصفح. أي أن رفيق IPFS (الملحق المستعرض) يدعم ipfs://... و ipns://... . أردنا استخدام dweb://ipfs/... وما إلى ذلك ، لكننا احتجنا أيضًا إلى دعم أصل الأمان المناسب (مما يعني أننا بحاجة إلى التجزئة في المكون الأول ).

ومع ذلك ، فإننا نعتبر أن ipfs://... يعادل /ipfs/... ونستخدم بناء جملة المسار في أي مكان آخر.

@ Stebalien من أين لك فكرة أن اضطراب الشخصية الانفصامية للناس؟ لم يتم ذكر "الناس" هناك مرة واحدة في مواصفات إضطراب الشخصية الإنفصامية. يمكن لمعرفات URI تحديد أي مورد بالتعريف.

لا يهم ما تفكر فيه. إذا كنت لا تلتزم بالمعايير الحالية ، فلا يمكنك توقع إمكانية التشغيل البيني والدعم من خلال البنية التحتية الحالية.

من أين لك فكرة أن اضطراب الشخصية الانفصامية هو للناس؟ لم يتم ذكر "الناس" هناك مرة واحدة في مواصفات إضطراب الشخصية الإنفصامية.

DIDs هي لـ "الهوية الرقمية".

المعرّفات اللامركزية (DIDs) هي نوع جديد من المعرّفات للهوية الرقمية "ذاتية السيادة" التي يمكن التحقق منها.

لذا؟ يمكن أن يحتوي كل شيء على _ Identity_: أشخاص ، حيوانات ، مباني ، منظمات ، أشياء ، أفكار ، وثائق إلخ. هذا هو جمال URIs.
هل نظرت بالفعل في مواصفات DID؟ أكرر ، لا يوجد شيء خاص بالأشخاص.

المعرف اللامركزي (DID)

معرّف فريد عالميًا لا يتطلب سلطة تسجيل مركزية لأنه مسجل بتقنية دفتر الأستاذ الموزع أو أي شكل آخر من الشبكات اللامركزية. يتم تعريف التنسيق العام لاضطراب الشخصية الانفصامية في هذه المواصفات. يتم تعريف مخطط DID محدد في مواصفات طريقة DID.