मैं इसे अभी दस्तावेज़ीकरण में नहीं ढूँढ सकता, लेकिन मुझे निम्नलिखित पंक्तियों के साथ एक स्पष्टीकरण याद है:
आईपीएफएस एक फाइल सिस्टम है और फाइल सिस्टम के लिए आप यूआरएल के बजाय पथ का उपयोग करते हैं। URL को एक कुरूपता के रूप में समझा जा सकता है जो आपकी स्थानीय मशीन और दूरस्थ मशीनों पर पहुंच को एकीकृत करने में विफलता का प्रतिनिधित्व करता है। IPFS स्थानीय और दूरस्थ फ़ाइलों के साथ समान व्यवहार करके इस कुरूपता से बच रहा है और फ़ाइलों को संबोधित करने का तरीका एक मानक पथ है।

यह पूरे आईपीएफएस को /ipfs के तहत माउंट करने और फिर फाइलों तक पहुंचने की कल्पना करने में मदद कर सकता है जैसे वे हैं: आपके फाइल सिस्टम में फ़ाइलें।

अतिरिक्त पठन सामग्री:

लंबी चर्चा: https://github.com/ipfs/go-ipfs/issues/1678
वर्तमान आम सहमति का संक्षिप्त सारांश: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

साथ ही, मानक URL रिज़ॉल्यूशन के साथ IPFS निरपेक्ष पतों को (या बिना?) fs: path के साथ मूल की पहचान करने से

और https://github.com/ipfs/in-web-browsers/issues/28 ड्राफ्ट स्पेक के लिंक के साथ। cc @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/..

यह एक अवधारणा नहीं है जो मुझे आकर्षित करती है। मैं अपने सिस्टम को व्यवस्थित करने के लिए उपयोग किया जाता हूं कि मैं कैसे पसंद करता हूं और अपने फाइल सिस्टम को चुनता हूं। लेकिन यह वास्तव में वह नहीं है जो मुझे बंद कर रहा है। आप जहां चाहें आईपीएफ माउंट करने के लिए स्वतंत्र हैं। मैं megalomaniacal "सब कुछ फिर से आविष्कार करने देता है" दृष्टिकोण से बंद कर दिया गया है। मैं आईपीएफएस में आया क्योंकि मैं एक वितरित सीएएस चाहता था। मुझे बस इतना ही दिलचस्पी थी। मुझे यूनिक्स को वेब के साथ मिलाने की परवाह नहीं है। लेकिन उस चर्चा को पढ़ने के बाद आईपीएफएस अब एक उत्पाद की तरह नहीं लगता है जो मुझे एक वितरित सीएएस प्राप्त करने में मदद करेगा, यह एक ऐसे उत्पाद की तरह लगता है जो मेरे कंप्यूटर के फाइल सिस्टम का उपयोग और नामस्थान को निर्देशित करेगा और एक बार लेखक एक बात तय कर रहे हैं, तो शायद उनके पास होगा मेरे कंप्यूटर को कैसे कॉन्फ़िगर और व्यवस्थित किया जाना चाहिए, इसके लिए कुछ अन्य नए विचार। मैं भविष्य की भविष्यवाणी नहीं कर सकता, लेकिन मुझे दृष्टिकोण पसंद नहीं है।

यह बहुत बुरा है, क्योंकि मैं वास्तव में आईपीएफएस के वितरित सीएएस कार्यान्वयन को पसंद करता हूं। मैं लंबे समय से एक वितरित सीएएस होने का सपना देख रहा हूं :(। तो मुझे शोध मोड पर वापस जाना होगा और कुछ अन्य वितरित सीएएस देखना होगा ...

@timthelion मैं आपको देखता हूं (मेरी तरह ही) वास्तव में CAS और IPFS की परवाह करता हूं।
मैं आपकी चिंताओं को कम करने की पूरी कोशिश करूंगा।

मुझे पूरा यकीन है कि आप आईपीएफएस को सीएएस के रूप में अपने सिस्टम में कहीं भी माउंट किए बिना उपयोग कर सकते हैं।
जिस तरह से मैं /ipfs/Qm.. पथों के बारे में सोचता हूं वह यह है कि वे केवल एक मानसिक शॉर्टकट हैं जो बातचीत और लिंकिंग को सरल बनाता है (जैसे नियमित यूआरएल हैं)।

निजी तौर पर, मैं मानता हूं कि "प्रोटोकॉल हैंडलर" और "कैनोनिकल एड्रेस सेमेन्टिक्स" स्थिति अभी एक दर्शक के लिए एक गड़बड़ी की तरह लग सकती है, लेकिन व्यावहारिक समाधान पर काम कर रहे अच्छे लोग अभी काम कर सकते हैं (उदाहरण के लिए https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7)।

यह एक सतत बातचीत है और इन चीजों में समय लगता है।

परियोजना की सामान्य दिशा (मेरी व्यक्तिगत राय) _ "उपयोगी उपकरण बनाना है जो उद्योग मानकों का पुन: उपयोग करते हैं जहां ऐसा करना व्यावहारिक है"_ के बजाय _"सब कुछ फिर से आविष्कार करें चाहे कुछ भी हो"_।

मुझे नहीं लगता कि आपको भविष्य के बारे में चिंतित होना चाहिए। IPFS टूल _"यूनिक्स वे"_ का अनुसरण करते हैं, जिसका अर्थ है कई छोटे टूल, लाइब्रेरी और कमांड ( git उपकमांड के समान) जो एक काम करते हैं उन्हें कुछ बड़ा बनाने के लिए एक साथ जंजीर से बांधा जा सकता है।

आप ही तय करते हैं कि किन टुकड़ों का उपयोग किया जाए। ️

मुझे उम्मीद है कि कोई मेरी आखिरी पोस्ट को गलत तरीके से नहीं लेगा। मेरे कहने का मतलब यह नहीं है कि "तुम सब गधे हो जो मैं छोड़ रहा हूँ"। मुझे लगता है कि हजारों लोगों ने आईपीएफएस पर एक नज़र डाली है, फैसला किया है कि उन्हें कुछ पसंद नहीं है, और बिना यह लिखे कि क्यों... मैं अक्सर ऐसा करता हूं। मैं बस एक तकनीक को लापरवाही से देखता हूं और कुछ छोटे विवरण के आधार पर एक अलग चुनता हूं जो मुझे गलत तरीके से परेशान करता है। मैंने ऐसा नहीं करने का फैसला किया क्योंकि मैं मूक बहुमत का एक मूक सदस्य नहीं बनना चाहता था, और इसलिए भी, क्योंकि मेरे पास बहुत से अन्य विकल्प नहीं हैं: डी, ​​लेकिन ऐसा लगता है कि मुझे इसके लिए इंतजार करना होगा ipfs का समर्थन करने के लिए fs: // या जो कुछ भी परियोजना प्रमुख चुनते हैं, इससे पहले कि मैं अपने वर्तमान प्रोजेक्ट में ipfs का उपयोग करना शुरू कर दूं और मैं केवल गंभीरता से IPFS को देखना शुरू कर पाऊंगा जब तक कि कुछ वास्तविक सामान्य URL मौजूद न हों।

megalomaniacal द्वारा बंद कर दिया गया है "सब कुछ फिर से आविष्कार करने देता है" दृष्टिकोण।

आप बहक रहे थे, इसके बारे में कुछ भी 'मेगालोमैनियाकल' या यहां तक ​​​​कि एक पुन: आविष्कार नहीं है। हम फ़ाइल-पथों के उपयोग के बारे में बात कर रहे हैं जैसे वे हमेशा होते हैं। /ipfs पर बढ़ना चीजों को स्पष्ट करने के लिए सिर्फ एक उदाहरण था, न कि मूल विचार।

मैं अपने सिस्टम को व्यवस्थित करने के लिए उपयोग किया जाता हूं कि मैं कैसे पसंद करता हूं और अपने फाइल सिस्टम को चुनता हूं।

कोई भी आपको स्थानीय फाइल सिस्टम @timthelion के रूप में IPFS माउंट करने के लिए बाध्य नहीं कर रहा है। यह एक विशेषता है जिसका आप उपयोग कर सकते हैं और आप यह तय कर सकते हैं कि यह किन रास्तों पर आरोहित है। एक अक्षम-दर-डिफ़ॉल्ट सुविधा को नापसंद करना मुझे आईपीएफएस को समग्र रूप से खारिज करने का एक कमजोर कारण लगता है। लेकिन ठीक है, मुझे आशा है कि आप भविष्य में अपना विचार बदलेंगे और हमारे साथ फिर से जुड़ेंगे।

मैंने एक भी ऐसा उत्पाद नहीं देखा जहां हर कोई हर सुविधा को पसंद करता हो।

यह भी उल्लेखनीय है कि यह वास्तव में कुछ भी पुनर्निर्मित नहीं कर रहा है। यह कुछ "अनइन्वेंटिंग" है।

हमारे अलग-अलग मतों के बावजूद, fs:// हैंडलर -- जो आपको वह सहज समर्थन देगा जो आप चाहते हैं - जैसा कि हम बोलते हैं, लागू किया जा रहा है, और पहले से ही आप इसे ब्राउज़र एक्सटेंशन के साथ उपयोग करने में सक्षम हैं। हम पीओसी कार्यान्वयन पर भी काम कर रहे हैं ताकि ब्राउज़र इसे मूल रूप से उपयोग कर सकें। आप इलेक्ट्रान से लिपटे अनुप्रयोगों में इसके लिए समर्थन भी लागू कर सकते हैं। हो सकता है कि आप उन्हें तेजी से आगे बढ़ाने के उन प्रयासों में योगदान दे सकें।

"आप बहक रहे थे, इसके बारे में कुछ भी 'मेगालोमैनियाकल' या यहां तक ​​​​कि एक पुन: आविष्कार भी नहीं है।"

मैं https://github.com/multiformats/multiaddr को magalomaniacal और पुन: आविष्कार के रूप में व्याख्या करता हूं। यह URL से भिन्न प्रारूप है लेकिन यह समान डेटा का प्रतिनिधित्व करता है। इस तरह के एक महत्वपूर्ण मानक का पुन: आविष्कार करने के लिए आपको एक बहुत अच्छे कारण की आवश्यकता है।

मैं थोड़ा और विस्तृत हो जाऊंगा।

"हम हमेशा की तरह फ़ाइल-पथों के उपयोग के बारे में बात कर रहे हैं।"

मुझे लगता है कि मुझे वह मिलता है जहां आप लोग इस विचार के साथ जा रहे हैं। क्या "गलती" है कि आप इस तथ्य को ठीक करने का प्रयास कर रहे हैं कि आप वेब संसाधनों को सामान्य फ़ाइलों की तरह नहीं मान सकते हैं? उस तरह मैं cat http://google.com/index.html नहीं कर सकता? मैं आपसे सहमत हो सकता हूं कि यह दुख की बात है कि असंभव है। अगर मुझे एक ओएस लिखना होता, तो मैं open फ़ंक्शन को फाइलों में यूआरएल खोलने में सक्षम बनाता। शायद ऐसा बदलाव linux में भी किया जा सकता है। आपका दृष्टिकोण अलग है, आप वेब संसाधनों को 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/

मल्टीएड्र द्वारा प्रस्तावित रास्तों के साथ मैं इसके बजाय देखूंगा:

$ 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 ने मानक url का उपयोग किया है, तो मैं ipfs: // से ipfs से शुरू होने वाली किसी भी चीज़ को बस अग्रेषित कर दूंगा और सब कुछ सरल हो जाएगा।

लेकिन जब मेरा प्रोग्राम एक स्ट्रिंग को देखता है जो / से शुरू होता है तो यह व्याख्या करता है कि किसी मशीन पर फ़ाइल या निर्देशिका के लिए एक पूर्ण पथ होने के नाते, आमतौर पर वह मशीन जिस पर कोड चल रहा है। यदि इसे / से शुरू होने वाले पथ पर जाने के लिए कहा जाता है, तो यह निश्चित रूप से इसे स्थानीय मशीन पर फ़ाइल या निर्देशिका के लिए एक पूर्ण पथ के रूप में व्याख्या करेगा। यदि मेरी मशीन पर /ipfs मौजूद नहीं है तो प्रोग्राम को एक फ़ाइल-नहीं-मिली त्रुटि वापस करनी चाहिए। मैं एक और उदाहरण के बारे में नहीं सोच सकता जहां एक पूर्ण पथ जिसे प्रोग्राम को देखने के लिए कहा जाता है, स्थानीय मशीन पर फ़ाइल या निर्देशिका के अलावा कहीं और जाता है। तो मेरे लिए, लंबे समय तक लिनक्स उपयोगकर्ता/डेवलपर के रूप में, यह नया व्यवहार है।

अगर मेरे आवेदन ने मल्टीएड्र के लिए समर्थन जोड़ने का प्रयास किया है, तो चीजें बहुत जल्दी बालों वाली हो जाएंगी। क्या होगा यदि उपयोगकर्ता चलता है:

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

और उपयोगकर्ता के पास एक वेब सर्वर होता है जो अपनी html फ़ाइलों को /http में संग्रहीत करता है। बिल्कुल अनसुना नहीं। क्या मेरे प्रोग्राम को इसे एक मल्टीएडर पते या स्थानीय फ़ाइल में हल करना चाहिए?

मैंने पहले से ही अजगर में यूआरएल खोलने के लिए आदिम समर्थन के साथ कुछ कोड लिखा है। ऐसा करना काफी आसान था। लेकिन मैं अपना कोड कैसे बदलूं ताकि यह स्पष्ट रूप से मल्टीएड्र पथ और स्थानीय फ़ाइल पथ दोनों को हल कर सके?

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

मुझे सच में नहीं लगता कि यह संभव है। इसलिए, मेरे पास मल्टीएड्र समर्थन को लागू नहीं करने और केवल सामान्य यूआरएल का समर्थन करने के लिए छोड़ दिया गया है। यह पहली बार में ठीक लगता है, लेकिन ipfs के उपयोगकर्ता लगातार ipfs ऑब्जेक्ट्स के लिए मल्टीएड्र एड्रेस के संपर्क में आने वाले हैं, और मेरा प्रोग्राम, जो IPFS सपोर्ट का विज्ञापन करता है, दावा करेगा कि वे रास्ते मौजूद नहीं हैं। इसलिए कोई फर्क नहीं पड़ता कि मैं समर्थन कैसे लागू करता हूं, मेरा कार्यक्रम टूटने वाला है। या तो ipfs के लिए इसका समर्थन टूट जाएगा, या मानक POSIX फाइल सिस्टम के लिए इसका समर्थन टूट जाएगा।

ऐसे तरीके हैं जिनसे इसे संभावित रूप से ठीक किया जा सकता है। एक तो यह होगा कि मल्टीएड्र को पूरी तरह से छोड़ दिया जाए। एक और मल्टीएड्र को बदलना होगा ताकि कम से कम उन पथों को एक उपनिर्देशिका तक ही सीमित कर दिया जा सके। तो बजाय writting से /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/

यह कुछ ऐसा होगा जिसके साथ मैं रह सकता था, और शायद पीछे भी। लेकिन वर्तमान स्थिति यह है कि मुझे आईपीएफ समर्थन को लागू करने का कोई संतोषजनक तरीका नहीं पता है।

मुझे एक और अधिक ठोस उदाहरण प्राप्त करने दें। कल्पना कीजिए कि मैं एक प्रोग्राम लिख रहा हूं जो मार्कडाउन को पीडीएफ में परिवर्तित करता है। और मैं आईपीएफएस से छवियों को शामिल करने का समर्थन करने में सक्षम होना चाहता हूं। तो उपयोगकर्ता लिखता है:

अटारी.एमडी
````

सामान जो मैंने अपने अटारी में पाया

चट्टानों का एक पुराना डिब्बा।

````

और दौड़ता है

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

मेरे प्रोग्राम को उन छवि पथों को कैसे हल करना चाहिए? क्या यह मान लेना चाहिए कि /ipfs फाइल सिस्टम आरोहित है? हम पहले ही सहमत हैं कि उपयोगकर्ताओं को /ipfs माउंट करने के लिए बाध्य नहीं किया जाता है। क्या प्रोग्राम को /ipfs/ को एक विशेष उपसर्ग के रूप में मानना ​​चाहिए? यह अजीब और टूटा हुआ लगता है। क्या प्रोग्राम केवल fs:// समर्थन करता है और एक त्रुटि लौटाता है, फ़ाइल उन पथों को नहीं मिली है? यह उचित लगता है, लेकिन उन उपयोगकर्ताओं को भ्रमित करेगा जो मल्टीएड्र मानक के आदी हैं। बैग से बाहर निकलने का कोई सही रास्ता नहीं है! :/ :(

स्पष्टीकरण के लिए संपादित

कुछ उपयोग के मामले @timthelion प्रदान करने के लिए धन्यवाद। यह बहुत अच्छा है कि लोग वास्तविक दुनिया के उदाहरण पेश करें ताकि हम सुनिश्चित कर सकें कि प्रोटोकॉल वास्तविक लोगों के लिए काम करते हैं।

"सब कुछ / पर बढ़ते हुए" उदाहरण को स्पष्ट करना

जैसा कि @लिडेल ने बताया, लोग वर्तमान में पता योजना तैयार करने पर काम कर रहे हैं, इसलिए अभी तक कोई दस्तावेज नहीं है। ऐसा लगता है कि @jbenet के फाइल सिस्टम माउंट के उदाहरण ने भ्रम पैदा कर दिया है। यह सिर्फ एक उदाहरण है जो लोगों को fs: या dweb: पता योजना के पीछे के वैचारिक मॉडल के माध्यम से सोचने में मदद करने के लिए है। वह यह प्रस्तावित नहीं कर रहा है कि हम सभी को वास्तव में उन सभी निर्देशिकाओं को उनके फाइल सिस्टम पर माउंट करने के लिए मजबूर करें। इसके बजाय, उनका प्रस्ताव है कि हमें उन पतों के साथ _identify_ सामग्री में सक्षम होना चाहिए जो आपके स्थानीय फाइल सिस्टम पर सामग्री की तरह व्यवहार करते हैं, क्योंकि यह हमें यूनिक्स/पॉज़िक्स टूल का उपयोग करके वेब/डवेब सामग्री के साथ बातचीत करने की अनुमति देगा।

जब हम दस्तावेज़ लिखते हैं, तो हमें इसे स्पष्ट करने के लिए सावधान रहना होगा। इसे फ़्लैग करने के लिए धन्यवाद।

आपके 'अटारी में सामान' उदाहरण के उत्तर में, मुझे लगता है कि विचार यह है कि आप अपने लिंक में 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 ।

निरपेक्ष पथ संदर्भ पर निर्भर करता है

निरपेक्ष रास्तों के बारे में, आपने कहा:

यदि इसे / से शुरू होने वाले पथ पर जाने के लिए कहा जाता है, तो यह निश्चित रूप से इसे स्थानीय मशीन पर फ़ाइल या निर्देशिका के लिए एक पूर्ण पथ के रूप में व्याख्या करेगा।

ध्यान रखें कि फाइल सिस्टम की जड़ के सापेक्ष _context_ के सापेक्ष पूर्ण पथ होने के लिए पर्याप्त उदाहरण है। इसका सबसे सामान्य उदाहरण HTML में पूर्ण पथ है, जो वर्तमान origin की जड़ के सापेक्ष है, सर्वर के फाइल सिस्टम के रूट के सापेक्ष नहीं। अगर मेरे पास कोड है जो एक संदर्भ में काम कर रहा है जो मानता है कि सभी पथ fs: या dweb: , तो उस कोड के लिए /ipfs/ शुरू होने वाले पते का उपयोग करना पूरी तरह से मान्य है और वहां हैं आपके फाइल सिस्टम पर /ipfs पर ipfs को शाब्दिक रूप से बढ़ाए बिना पथों को हल करने के लिए उस कोड के बहुत सारे तरीके।

ये मेरे 2 सेंट हैं:

• प्रत्येक फ़ाइल fs:/ अंतर्गत है, उसी प्रकार प्रत्येक डोमेन http:/ अंतर्गत है।
• मैं अपने फ़ाइल सिस्टम पर डोमेन नाम सिस्टम को / पर माउंट नहीं करता, उसी तरह मैं अपने / पर IPFS की संपूर्णता को माउंट नहीं करता। दोनों प्रणालियों में योजना के सापेक्ष संदर्भ बिंदु / ( http:/ , fs:/ )।

मुझे लगता है कि आपके अधिकांश उदाहरणों में यह धारणा है कि प्रत्येक फ़ाइल सिस्टम ने ipfs को / पर आरोहित किया है। इसलिए fs:/ होने से URI प्रारूप नहीं टूटता है।

इसके बजाय, उनका प्रस्ताव है कि हमें उन पतों वाली सामग्री की पहचान करने में सक्षम होना चाहिए जो आपके स्थानीय फाइल सिस्टम पर सामग्री की तरह व्यवहार करती हैं, क्योंकि यह हमें यूनिक्स/पॉज़िक्स टूल का उपयोग करके वेब/डवेब सामग्री के साथ बातचीत करने की अनुमति देगा।

"यह हमें यूनिक्स/पॉज़िक्स टूल का उपयोग करके वेब/डवेब सामग्री के साथ बातचीत करने की अनुमति देगा।" क्या आप कृपया मुझे ऐसे मामले का एक ठोस उदाहरण दे सकते हैं जिसमें गैर- fs: उपसर्ग वाले सिंटैक्स का उपयोग यूनिक्स टूल के साथ किया जाएगा? किसी तरह, मुझे अभी भी यह नहीं मिल रहा है।

मैंने स्वयं एक उदाहरण के साथ आने की कोशिश की है, लेकिन मैं ऐसे किसी भी उदाहरण के बारे में नहीं सोच सकता जिसमें मल्टीएड्र अनुपालन /ipfs प्रीफ़िक्स्ड सिंटैक्स समझ में आता है।

मैंने बैश में भिन्न उपयोगिता के लिए एक रैपर स्किप्ट बनाने की कोशिश की, जिसने मल्टीएड्र योजना का उपयोग करके ipfs का समर्थन किया:

````
टिमोथी @योग ~/c/ipfs-multiaddr> कैट मल्टीएड्र-डिफ

!/बिन/बाश

get_multiaddr_or_normal_file_getter(){
अगर [[ $1 == /ipfs/* ]] ;
फिर
file_getter="ipfs cat $1"
अन्यथा
file_getter = "बिल्ली $1"
फाई
इको $file_getter
}

फ़ाइल1= get_multiaddr_or_normal_file_getter $1
file2= get_multiaddr_or_normal_file_getter $2

अंतर <($file1) <($file2)
````

यह सामान्य फ़ाइलों और ipfs फ़ाइलों दोनों पर भोले मामले में काम करता है:

````
टिमोथी @योग ~/c/ipfs-multiaddr>
./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,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 ....

मुझे यकीन नहीं है कि मैं उस उपयोगिता को कैसे संपादित कर सकता हूं, ताकि यह विश्वसनीय रूप से मल्टीएडर एड्रेस और सामान्य यूनिक्स फाइलों दोनों के साथ काम कर सके।

दूसरी ओर, एक अलग आवरण बनाना जो केवल url शैली sytax का समर्थन करता है, कठिन नहीं है:

````
टिमोथी @ योग ~/c/ipfs-multiaddr> बिल्ली url-वाक्यविन्यास-diff

!/बिन/बाश

get_multiaddr_or_normal_file_getter(){
अगर [[ $1 == fs:* ]] ;
फिर
उपसर्ग = "एफएस:"
आंतरिक_पथ=${1#$उपसर्ग}
file_getter="ipfs cat $internal_path"
अन्यथा
file_getter = "बिल्ली $1"
फाई
इको $file_getter
}

फ़ाइल1= get_multiaddr_or_normal_file_getter $1
file2= get_multiaddr_or_normal_file_getter $2
गूंज $file1
गूंज $file2
अंतर <($file1) <($file2)
````

यह ठीक उसी तरह काम करता है, और 3 अतिरिक्त वर्ण निश्चित रूप से बहुत फर्क नहीं करते हैं जब हैश पहले से ही एक अरब और आधा वर्ण लंबा होता है।

````
टिमोथी @योग ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
बिल्ली ../उप उपयोक्ता/कॉपींग.एलजीपीएल
ipfs बिल्ली /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

च) अपने पहले जन्म के बच्चे को पहले भगवान लौरथ को बलिदान करें
निम्नलिखित सम संख्या वाले वर्ष की पूर्णिमा।

टिमोथी @योग ~/c/ipfs-multiaddr>
````

और अजीब किनारे के मामलों में, यह एक अच्छी तरह से पॉलिश किए गए POSIX उपयोगिता से अपेक्षा के अनुरूप बेहतर प्रदर्शन करता है।

````
टिमोथी @yoga ~/c/ipfs-multiaddr> इको "बार">बार
टिमोथी @योग ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
बिल्ली बार
बिल्ली /ipfs/foo
1सी1

<बार

फू
````

चूंकि fs: और dweb: पर चर्चा कभी न खत्म होने वाली प्रतीत होती है, मुझे अभी भी इस जनसंपर्क पर कुछ इनपुट की आवश्यकता है: https://github.com/ipfs/specs/pull/139

ipfs का उपयोग करना: इस बीच कम से कम मेरे लिए बहुत सारे मुद्दों को हल करता है।

@ पावल आह, जब मैंने आपकी टिप्पणी देखी तो मेरा दिल डूब गया, क्योंकि मैं काफी बेसब्री से अपनी चिंताओं के जवाब की प्रतीक्षा कर रहा था।

पिंग @jbenet

मुझे आपकी पिछली पोस्ट के जवाबों में भी दिलचस्पी है क्योंकि इसने उस समस्या पर एक परिप्रेक्ष्य को उजागर किया है जिसके बारे में मुझे पहले जानकारी नहीं थी।

// संपादित करें: इसका मतलब यह है कि मैं अभी भी इस मुद्दे का अनुसरण कर रहा हूं और अगर मेरे पास देने के लिए संतोषजनक उत्तर होता तो मैं जवाब देता।

+1

मानक के रूप में 'ipfs: //' कार्य करें। कृपया।

(इसलिए हमारे सभी ऐप्स यह मान सकते हैं कि यह सभी प्लेटफॉर्म पर, हर जगह काम करता है -
कहीं भी, और व्यवसाय कार्ड पर)

धन्यवाद।

जूलियन स्मिथ
ब्लॉकफ्रेट™

ipfs: बनाम fs: बनाम dweb: के आसपास की चर्चा एक भ्रमित करने वाली बात है जो इस परियोजना में शामिल होने से पहले से चल रही है। वेब ब्राउजर स्प्रिंट में आईपीएफएस के दौरान मुझे अंतत: इसके चारों ओर अपना सिर पाने के लिए थोड़ा समय मिला। मैं विभिन्न विकल्पों और तर्कों की रूपरेखा के साथ पूरी तस्वीर का स्पष्टीकरण लिख रहा हूं, जिसे मैं आज बाद में ipfs/specs पर PR के रूप में प्रस्तुत करूंगा। मैं उन चर्चाओं के उदाहरण और संदर्भ शामिल करूंगा जिनके बारे में मैं जानता हूं। उम्मीद है कि यह कुछ स्पष्टता प्रदान करेगा और हमें बिना किसी गलती के सबसे व्यावहारिक मार्ग पर आगे बढ़ने की अनुमति देगा जो लंबे समय तक बड़ी समस्याएं पैदा करता है।

मैंने यहां इन चर्चाओं के लिए एक पृष्ठभूमि प्रदान करने पर एक प्रारंभिक कदम उठाया है: https://github.com/ipfs/specs/pull/152 कृपया पीआर को ऐसी जानकारी के साथ अपडेट करें जो गलत है, अधूरी है, या आम तौर पर सुधार के लिए चाहती है।

मेरी अज्ञानता के लिए क्षमा करें, लेकिन मैं पीआर को कैसे अपडेट करूं?

@timthelion आप इसे @jbenet की तरह कर सकते हैं और यहां टिप्पणियां जोड़ सकते हैं या आप रेपो को क्लोन कर सकते हैं, शाखा को चेकआउट कर सकते हैं, संशोधित कर सकते हैं, पैच भेज सकते हैं आदि

@ वासा-विकास के रूप में आपकी टिप्पणी वास्तव में यह नहीं बताती है कि सॉफ़्टवेयर स्थिति को कैसे सुधारता है, मैं इसे स्पैम मानता हूं।

डीआईडी ​​यूआरआई के बारे में कैसे? जैसे did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

विकेंद्रीकृत पहचानकर्ता (डीआईडी)

डीआईडी लोगों के लिए पहचानकर्ता हैं। हालांकि, उनके मूल में, वे वास्तव में यूआरएन हैं (मुझे लगता है?) तो एक बेहतर सवाल यह है: "यूआरएन क्यों नहीं"?

वास्तव में, इसका उत्तर यह है कि जहां URL हमें ब्राउज़र संगतता प्रदान करते हैं, पथ हमें फाइल सिस्टम संगतता (अन्य बातों के अलावा) देते हैं, लेकिन URN वास्तव में हमें कुछ मानक निकायों के साथ कुछ अच्छी इच्छा के अलावा बहुत कुछ नहीं देते हैं।

नोट: हमने वास्तव में ब्राउज़र संगतता प्राप्त करने के लिए URL स्थिति पर ध्यान दिया है। यानी, IPFS सहयोगी (ब्राउज़र एडऑन) ipfs://... और ipns://... का समर्थन करता है। हम dweb://ipfs/... आदि का उपयोग करना चाहते थे , लेकिन हमें उचित सुरक्षा मूल समर्थन की भी आवश्यकता थी (जिसका अर्थ है कि हमें पहले घटक में हैश की आवश्यकता है)।

हालांकि, हम ipfs://... को /ipfs/... के बराबर मानते हैं और हर जगह पथ सिंटैक्स का उपयोग करते हैं।

@Stebalien आपको यह विचार कहां से आता है कि DID लोगों के लिए हैं? डीआईडी ​​​​स्पेक में एक बार "लोगों" का उल्लेख नहीं किया गया है। यूआरआई पहचानकर्ता परिभाषा के अनुसार किसी भी संसाधन की पहचान कर सकते हैं।

इससे कोई फर्क नहीं पड़ता कि आप क्या मानते हैं; यदि आप मौजूदा मानकों का पालन नहीं कर रहे हैं, तो आप मौजूदा बुनियादी ढांचे से अंतर और समर्थन की उम्मीद नहीं कर सकते।

आपको यह विचार कहां से आया कि डीआईडी ​​लोगों के लिए हैं? डीआईडी ​​​​स्पेक में एक बार "लोगों" का उल्लेख नहीं किया गया है।

DIDs "डिजिटल पहचान" के लिए हैं।

विकेन्द्रीकृत पहचानकर्ता (डीआईडी) सत्यापन योग्य, "स्व-संप्रभु" डिजिटल पहचान के लिए एक नए प्रकार के पहचानकर्ता हैं।

इसलिए? सब कुछ _पहचान_ हो सकता है: लोग, जानवर, भवन, संगठन, चीजें, विचार, दस्तावेज इत्यादि। यही यूआरआई की सुंदरता है।
क्या आपने वास्तव में डीआईडी ​​​​स्पेक में देखा है? मैं दोहराता हूं, व्यक्तियों के लिए कुछ खास नहीं है।

विकेंद्रीकृत पहचानकर्ता (डीआईडी)

एक विश्व स्तर पर अद्वितीय पहचानकर्ता जिसे केंद्रीकृत पंजीकरण प्राधिकरण की आवश्यकता नहीं है क्योंकि यह वितरित खाता प्रौद्योगिकी या विकेन्द्रीकृत नेटवर्क के अन्य रूप के साथ पंजीकृत है। इस विनिर्देश में एक डीआईडी ​​​​का सामान्य प्रारूप परिभाषित किया गया है। एक विशिष्ट डीआईडी ​​योजना को डीआईडी ​​विधि विनिर्देश में परिभाषित किया गया है।