Ich kann es jetzt nicht in der Dokumentation finden, aber ich erinnere mich an eine Erklärung in der folgenden Richtung:
IPFS ist ein Dateisystem und für Dateisysteme verwenden Sie Pfade anstelle von URLs. URLs können als Hässlichkeit verstanden werden, die einen Fehler bei der Vereinheitlichung des Zugriffs auf Ihrem lokalen Computer und auf Remotecomputern darstellt. IPFS vermeidet diese Hässlichkeit, indem lokale und entfernte Dateien gleich behandelt werden und die Methode zum Adressieren von Dateien ein Standardpfad ist.

Es könnte hilfreich sein, sich vorzustellen, das gesamte IPFS unter /ipfs zu mounten und dann auf die Dateien zuzugreifen, als wären sie genau das: Dateien in Ihrem Dateisystem.

Zusätzlicher Lesestoff:

Lange Diskussion: https://github.com/ipfs/go-ipfs/issues/1678
Kurze Zusammenfassung des aktuellen Konsenses: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

Außerdem wird daran gearbeitet, absolute IPFS-Adressen mit der Standard-URL-Auflösung in Einklang zu bringen und die Identifizierung von Ursprüngen mit (oder ohne?) fs:paths anzugehen .

Und https://github.com/ipfs/in-web-browsers/issues/28 mit Link zu einem Spezifikationsentwurf. cc @lgiert

:( Nachdem ich ipfs/go-ipfs#1678 gelesen habe, bin ich mir nicht einmal sicher, ob ich mich noch für IPFS interessiere :( . Das war eine schreckliche Nichtdiskussion.

Den Fahrradschuppen möchte ich eigentlich nicht betreten, aber das hier

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.
ist keine Idee, die mich anmacht. Ich stelle mir vor, plötzlich einen Systemstamm zu haben, der so aussieht
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

Das ist kein Konzept, das mich anspricht. Ich bin es gewohnt, mein System nach Belieben zu organisieren und meine Dateisysteme nach Belieben zu mounten. Aber das ist es nicht wirklich, was mich abschreckt. Es steht Ihnen frei, ipfs zu montieren, wo immer Sie möchten. Ich bin abgeschreckt von dem größenwahnsinnigen „Lasst uns alles neu erfinden“-Ansatz. Ich bin zu IPFS gekommen, weil ich einen verteilten CAS wollte. Das ist alles, woran ich interessiert war. Ich interessiere mich nicht dafür, Unix mit dem Web zu verschmelzen. Aber nachdem ich diese Diskussion gelesen habe, scheint IPFS nicht mehr wie ein Produkt zu sein, das mir hilft, einen verteilten CAS zu bekommen, es scheint wie ein Produkt, das vorschreibt, wie ich das Dateisystem meines Computers verwende und benenne, und sobald die Autoren eine Sache diktieren, werden sie es vielleicht tun einige andere neue Ideen, wie mein Computer konfiguriert und organisiert werden sollte. Ich kann die Zukunft nicht vorhersagen, aber ich mag den Ansatz nicht.

Das ist schade, weil ich die verteilte CAS-Implementierung von IPFS WIRKLICH MAG. Ich habe lange davon geträumt, einen verteilten CAS zu haben :(. Also muss ich zurück in den Forschungsmodus gehen und mir einige andere verteilte CASs ansehen ...

@timthelion Ich sehe, Sie interessieren sich (genau wie ich) wirklich für CAS und IPFS.
Ich werde mein Bestes tun, um Ihre Sorgen zu lindern.

Ich bin mir ziemlich sicher, dass Sie IPFS als CAS verwenden können, ohne es jemals irgendwo in Ihrem System zu installieren.
Die Art und Weise, wie ich über /ipfs/Qm.. -Pfade denke, ist, dass sie nur eine mentale Abkürzung sind, die Konversationen und Verknüpfungen vereinfacht (genau wie normale URLs).

Persönlich stimme ich zu, dass die Situation in Bezug auf „Protokollhandler“ und „kanonische Adresssemantik“ für einen Unbeteiligten im Moment wie ein Durcheinander aussehen mag, aber gute Leute arbeiten an pragmatischen Lösungen, die möglicherweise gerade funktionieren (z. B. https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7).

Dies ist ein andauerndes Gespräch und diese Dinge brauchen Zeit.

Die allgemeine Richtung des Projekts (meine persönliche Meinung) besteht darin, _"nützliche Tools zu entwickeln, die Industriestandards wiederverwenden, wo es praktisch ist"_, anstatt _"alles neu zu erfinden, egal was passiert"_.

Ich denke nicht, dass du dir Sorgen um die Zukunft machen solltest. IPFS-Tools folgen _"dem Unix-Weg"_, was bedeutet, dass viele kleine Tools, Bibliotheken und Befehle (ähnlich den git -Unterbefehlen), die eine Sache tun, miteinander verkettet werden können, um etwas Größeres aufzubauen.

Sie entscheiden, welche Teile verwendet werden. ⚙️ 🔧

Ich hoffe, dass niemand meinen letzten Beitrag falsch auffasst. Ich will nicht sagen "Ihr seid alle Arschlöcher, die ich verlasse". Ich nehme an, dass Tausende von Menschen sich IPFS angesehen haben, entschieden haben, dass ihnen etwas nicht gefällt, und dann gegangen sind, ohne jemals zu schreiben, warum... Ich mache das oft. Ich schaue mir einfach beiläufig eine Technologie an und wähle eine andere basierend auf einem kleinen Detail, das mich in die falsche Richtung reibt. Ich habe mich dagegen entschieden, weil ich kein schweigendes Mitglied einer schweigenden Mehrheit sein wollte und auch, weil ich nicht viele andere Möglichkeiten habe :D, aber es sieht so aus, als müsste ich warten ipfs zur Unterstützung von fs:// oder was auch immer die Projektleiter wählen, bevor ich anfange, ipfs in meinem aktuellen Projekt zu verwenden, und ich werde nur ernsthaft in der Lage sein, IPFS zu betrachten, bis einige wirklich normale URLs existieren.

bin abgeschreckt von dem größenwahnsinnigen „Lasst uns alles neu erfinden“-Ansatz.

Du hast dich hinreißen lassen, nichts daran ist „größenwahnsinnig“ oder gar eine Neuerfindung. Wir sprechen davon, dass Dateipfade so verwendet werden, wie sie immer sind. Das Mounten auf /ipfs war nur ein Beispiel zur Veranschaulichung, nicht die Kernidee.

Ich bin es gewohnt, mein System nach Belieben zu organisieren und meine Dateisysteme nach Belieben zu mounten.

Niemand zwingt Sie, IPFS als lokales Dateisystem @timthelion zu mounten. Dies ist eine Funktion, die Sie verwenden können, und Sie können entscheiden, auf welchen Pfaden sie bereitgestellt wird. Eine standardmäßig deaktivierte Funktion nicht zu mögen, klingt für mich nach einem schwachen Grund, IPFS als Ganzes abzulehnen. Aber gut, ich hoffe, Sie ändern in Zukunft Ihre Meinung und schließen sich uns wieder an.

Ich habe noch kein einziges Produkt gesehen, bei dem jeder jede Funktion mag.

Erwähnenswert ist auch, dass dies nicht wirklich etwas neu erfindet. Es ist etwas "nicht erfinden".

Ungeachtet unserer unterschiedlichen Meinungen wird der fs:// -Handler – der Ihnen die gewünschte nahtlose Unterstützung bietet – derzeit implementiert, und Sie können ihn bereits mit Browsererweiterungen verwenden . Wir arbeiten auch an PoC-Implementierungen, damit Browser es nativ verwenden können. Sie können die Unterstützung auch in elektronengewickelten Anwendungen implementieren. Vielleicht können Sie zu diesen Bemühungen beitragen, damit sie schneller ablaufen.

„Du hast dich hinreißen lassen, nichts daran ist ‚größenwahnsinnig‘ oder gar eine Neuerfindung.“

Ich interpretiere https://github.com/multiformats/multiaddr als magalomanisch und neu erfindend. Es ist ein anderes Format als eine URL, stellt aber die gleichen Daten dar. Sie brauchen einen verdammt guten Grund, um einen so wichtigen Standard neu zu erfinden.

Ich werde etwas ausführlicher sein.

"Wir sprechen davon, dass Dateipfade so verwendet werden, wie sie immer sind."

Ich glaube, ich verstehe, wohin ihr mit dieser Idee geht. Ist der "Fehler", den Sie zu beheben versuchen, die Tatsache, dass Sie Webressourcen nicht wie normale Dateien behandeln können? So kann ich cat http://google.com/index.html nicht machen? Ich kann Ihnen zustimmen, dass es traurig ist, dass dies unmöglich ist. Wenn ich ein Betriebssystem schreiben würde, würde ich die Funktion open in die Lage versetzen, URLs zu Dateien zu öffnen. Vielleicht könnte eine solche Änderung sogar an Linux vorgenommen werden. Ihr Ansatz ist anders, Sie versuchen, Webressourcen in die POSIX-Dateihierarchie einzufügen. Wenn es einen anderen Grund gibt, warum Sie denken, dass URLs ein Fehler sind, informieren Sie mich bitte.

Ich kann definitiv mit Ihrem Ziel sympathisieren, Webressourcen dazu zu bringen, sich wie normale Dateien zu verhalten. Ihre Methode, "den Fehler" zu beheben, scheint mir jedoch ziemlich rutschig zu sein. Wenn ich mich dafür entscheide, die ipfs-Dateisysteme zu mounten, dann ist ihr Mount-Punkt ein neues Verhalten für mich. Ich kann mir kein anderes Benutzermodusprogramm vorstellen, das ich auf meinem System installieren könnte, das mehrere Verzeichnisse direkt in meinem Stammverzeichnis erstellen würde.

Wenn ich heute ls / mache, bekomme ich:

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

Mit den von multiaddr vorgeschlagenen Pfaden würde ich stattdessen sehen:

$ 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

Und bevor Sie mir vorwerfen, den Standard falsch zu interpretieren, möchte ich Sie daran erinnern, dass ich ihn genau so interpretiere, wie Unix-Pfade IMMER interpretiert wurden.

Natürlich möchte ich mein Root-Verzeichnis nicht so durcheinander bringen. Daher werde ich mich dafür entscheiden, diese Pfade nicht zu mounten.

In meinem Fall ist dies sowieso nicht meine Wahl, ich möchte Software schreiben, die IPFS verwendet, und es ist nicht meine Entscheidung, ob der Benutzer diese Pfade einbindet oder nicht. Aber ich möchte immer noch, dass meine Benutzer eine über IPFS freigegebene Datei so einfach öffnen können wie eine Datei auf ihren lokalen Computern. Wie schreibe ich diesen Code? Wenn ipfs Standard-URLs verwenden würde, würde ich einfach alles, was mit ipfs:// beginnt, an ipfs weiterleiten, und alles wäre einfach.

Aber wenn mein Programm einen String betrachtet, der mit / beginnt, interpretiert es das als absoluten Pfad zu einer Datei oder einem Verzeichnis auf einem Computer, normalerweise dem Computer, auf dem der Code läuft. Wenn es aufgefordert wird, einen Pfad zu besuchen, der mit / beginnt, wird es DEFINITIV als absoluter Pfad zu einer Datei oder einem Verzeichnis auf dem lokalen Computer interpretiert. Wenn /ipfs auf meinem Computer nicht vorhanden ist, sollte das Programm einen Datei-nicht-gefunden-Fehler zurückgeben. Mir fällt kein anderes Beispiel ein, bei dem ein absoluter Pfad, den das Programm besuchen soll, irgendwo anders hinführt als zu einer Datei oder einem Verzeichnis auf dem lokalen Rechner. Für mich als langjährigen Linux-Benutzer/-Entwickler ist dies also ein neues Verhalten.

Wenn meine Anwendung versuchen würde, Unterstützung für multiaddr hinzuzufügen, würden die Dinge ziemlich schnell haarig werden. Was ist, wenn der Benutzer Folgendes ausführt:

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

und der Benutzer hat zufällig einen Webserver, der seine HTML-Dateien in /http speichert. Gar nicht unerhört. Sollte mein Programm dies in eine Multiaddr-Adresse oder die lokale Datei auflösen?

Ich habe bereits Code mit primitiver Unterstützung zum Öffnen von URLs in Python geschrieben. Das war ziemlich einfach. Aber wie würde ich meinen Code so ändern, dass er sowohl multiaddr-Pfade als auch lokale Dateipfade eindeutig auflöst?

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

Ich glaube wirklich nicht, dass das möglich ist. Daher bleibt mir übrig, die Multiaddr-Unterstützung nicht zu implementieren und nur normale URLs zu unterstützen. Das scheint zunächst in Ordnung zu sein, aber Benutzer von ipfs werden ständig multiaddr-Adressen von ipfs-Objekten ausgesetzt sein, und mein Programm, das IPFS-Unterstützung ankündigt, wird behaupten, dass diese Pfade nicht existieren. Also, egal wie ich die Unterstützung implementiere, mein Programm wird kaputt gehen. Entweder wird seine Unterstützung für ipfs unterbrochen, oder seine Unterstützung für das standardmäßige POSIX-Dateisystem wird unterbrochen.

Es gibt Möglichkeiten, dies möglicherweise zu beheben. Eine wäre, multiaddr ganz aufzugeben. Eine andere wäre, multiaddr so zu ändern, dass es diese Pfade zumindest auf ein einziges Unterverzeichnis beschränkt. Anstatt also /ipfs/hash/blah zu schreiben, würde man /webfs/ipfs/hash/blah schreiben. Und ls / würde zurückgeben:

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

Damit könnte ich leben und vielleicht sogar hinterherkommen. Aber die aktuelle Situation ist, dass ich keine zufriedenstellende Möglichkeit kenne, ipfs-Unterstützung überhaupt zu implementieren.

Lassen Sie mich zu einem noch KONKRETEREN Beispiel kommen. Stellen Sie sich vor, ich schreibe ein Programm, das Markdown in PDF konvertiert. Und ich möchte in der Lage sein, die Aufnahme von Bildern aus IPFS zu unterstützen. Also schreibt der User:

Dachboden.md
````

Sachen, die ich auf meinem Dachboden gefunden habe

Eine alte Steinkiste.

````

Und läuft

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

Wie soll mein Programm diese Bildpfade auflösen? Soll davon ausgegangen werden, dass das Dateisystem /ipfs gemountet ist? Wir haben uns bereits darauf geeinigt, dass Benutzer nicht gezwungen sind, /ipfs einzuhängen. Soll das Programm /ipfs/ als spezielles Präfix behandeln? Das wirkt seltsam und kaputt. Sollte das Programm nur fs:// und einen Fehler zurückgeben, Datei nicht gefunden angesichts dieser Pfade? das erscheint vernünftig, wird aber Benutzer verwirren, die an den multiaddr-Standard gewöhnt sind. Es gibt einfach keinen richtigen Weg aus der Tasche! :/ :(

zur Klarstellung bearbeitet

Vielen Dank für die Bereitstellung einiger Anwendungsfälle @timthelion. Es ist großartig, dass Menschen Beispiele aus der realen Welt anbieten, damit wir sicherstellen können, dass die Protokolle für echte Menschen funktionieren.

Verdeutlichung des Beispiels "mounting everything at /".

Wie @lidel betonte, arbeiten die Leute derzeit an der Gestaltung des Adressschemas, daher gibt es noch keine Dokumentation. Es sieht so aus, als hätte das Beispiel von @jbenet für Dateisystem-Mounts Verwirrung gestiftet. Es ist nur ein Beispiel, das Leuten helfen soll, das konzeptionelle Modell hinter dem fs: - oder dweb: -Adressschema zu durchdenken. Er schlägt nicht vor, dass wir jeden dazu zwingen, alle diese Verzeichnisse tatsächlich in sein Dateisystem einzuhängen. Vielmehr schlägt er vor, dass wir in der Lage sein sollten, Inhalte mit Adressen zu _identifizieren_, die sich so verhalten, als wäre der Inhalt auf Ihrem lokalen Dateisystem gemountet, weil uns das erlaubt, mit Web/DWeb-Inhalten unter Verwendung von Unix/Posix-Tools zu interagieren.

Wenn wir die Dokumente schreiben, müssen wir darauf achten, dies deutlich zu machen. Danke, dass du es gemeldet hast.

Als Antwort auf Ihr Beispiel "Zeug auf dem Dachboden" denke ich, dass die Idee darin besteht, dass Sie fs:/ in Ihren Links wie folgt verwenden:

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)

Einfache Adressen haben UND die Schemas vereinheitlichen

Randnotiz: Es gibt auch das Problem, die Adressen einfach zu halten. In diesem Kommentar schlug @nicola einen cleveren Weg vor, ipfs:/ - und ipns:/ -Adressen zu unterstützen, ohne das Adressschema fs: / dweb: zu verlassen. Die beteiligten Protokolldesign-Gymastics sind (IMHO) seltsam verwirrend, aber am Ende würden Sie Links in Ihrem Markdown wie ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV haben und gleichzeitig den Leuten erlauben, denselben Inhalt als fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV oder zu adressieren nur /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV in einem Unix/Posix-Kontext.

Absolute Pfade hängen vom Kontext ab

In Bezug auf absolute Pfade sagten Sie:

Wenn ihm gesagt wird, dass er einen Pfad besuchen soll, der mit / beginnt, wird er DEFINITIV als absoluter Pfad zu einer Datei oder einem Verzeichnis auf dem lokalen Computer interpretiert.

Denken Sie daran, dass es zahlreiche Präzedenzfälle dafür gibt, dass absolute Pfade relativ zu _context_ und nicht relativ zum Stammverzeichnis des Dateisystems sind. Das häufigste Beispiel dafür sind absolute Pfade in HTML, die relativ zum Stammverzeichnis des aktuellen origin sind, nicht relativ zum Stammverzeichnis des Dateisystems des Servers. Wenn ich Code habe, der in einem Kontext arbeitet, der davon ausgeht, dass alle Pfade fs: oder dweb: sind, ist es für diesen Code völlig gültig, Adressen zu verwenden, die mit /ipfs/ beginnen und es gibt viele Möglichkeiten für diesen Code, die Pfade aufzulösen, ohne ipfs buchstäblich bei /ipfs in Ihrem Dateisystem zu mounten.

Das sind meine 2 Cent:

• Jede Datei ist unter fs:/ , ebenso ist jede Domain unter http:/ .
• Ich mounte das Domain Name System nicht auf / in meinem Dateisystem, ebenso wie ich nicht das gesamte IPFS auf meinem / mounte. In beiden Systemen ist der Bezugspunkt / relativ zum Schema ( http:/ , fs:/ ).

Ich denke, in den meisten Ihrer Beispiele gibt es diese Vorstellung, dass jedes Dateisystem ipfs auf / gemountet hat. Wenn Sie also fs:/ haben, wird das URI-Format nicht beschädigt.

Vielmehr schlägt er vor, dass wir in der Lage sein sollten, Inhalte mit Adressen zu identifizieren, die sich so verhalten, als ob die Inhalte auf Ihrem lokalen Dateisystem gemountet wären, da uns dies die Interaktion mit Web-/DWeb-Inhalten unter Verwendung von Unix-/Posix-Tools ermöglichen würde.

"Das wird es uns ermöglichen, mit Web/DWeb-Inhalten unter Verwendung von Unix/Posix-Tools zu interagieren." Können Sie mir bitte ein konkretes Beispiel für einen Fall geben, in dem die Syntax ohne Präfix fs: mit einem Unix-Tool verwendet wird? Irgendwie bekomme ich es immer noch nicht hin.

Ich habe versucht, selbst ein Beispiel zu finden, aber mir fallen keine Beispiele ein, in denen die multiaddr-konforme /ipfs -Syntax mit dem Präfix sinnvoll ist.

Ich habe versucht, ein Wrapper-Skript für das diff-Dienstprogramm in bash zu erstellen, das ipfs mit dem multiaddr-Schema unterstützt:

````
timothy @yoga ~/c/ipfs-multiaddr> cat multiaddr-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
wenn [[ $1 == /ipfs/* ]] ;
dann
file_getter="ipfs-Katze $1"
anders
file_getter="Katze $1"
fi
echo $file_getter
}

file1= get_multiaddr_or_normal_file_getter $1
file2= get_multiaddr_or_normal_file_getter $2

diff <($datei1) <($datei2)
````

Es funktioniert im naiven Fall sowohl bei normalen Dateien als auch bei ipfs-Dateien:

````
timothy @yoga ~/c/ipfs-multiaddr>
./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) Opfere dein erstgeborenes Kind am Ersten dem GOTT Laurath
Vollmond des folgenden geraden Jahres.

````

Aber wenn ich versuche, es zu verwenden, um mit einer real existierenden Datei in einem /ipfs/ -Verzeichnis zu arbeiten, das ich erstellt habe, erhalte ich eine Fehlermeldung:

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 ....

Ich bin mir nicht sicher, wie ich dieses Dienstprogramm bearbeiten könnte, damit es sowohl mit Multiaddr-Adressen als auch mit normalen Unix-Dateien zuverlässig funktioniert.

Andererseits ist es nicht schwieriger, einen Diff-Wrapper zu erstellen, der nur die Syntax im URL-Stil unterstützt:

````
timothy @yoga ~/c/ipfs-multiaddr> cat url-syntax-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
wenn [[ $1 == fs:* ]] ;
dann
Präfix = "fs:"
internal_path=${1#$prefix}
file_getter="ipfs cat $internal_path"
anders
file_getter="Katze $1"
fi
echo $file_getter
}

file1= get_multiaddr_or_normal_file_getter $1
file2= get_multiaddr_or_normal_file_getter $2
echo $datei1
Echo $Datei2
diff <($datei1) <($datei2)
````

Es funktioniert genauso gut, und die 3 zusätzlichen Zeichen machen sicherlich keinen großen Unterschied, wenn der Hash bereits anderthalb Milliarden Zeichen lang ist.

````
timothy @yoga ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
cat ../subuser/COPYING.LGPL
ipfs Katze /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) Opfere dein erstgeborenes Kind am Ersten dem GOTT Laurath
Vollmond des folgenden geraden Jahres.

timothy @yoga ~/c/ipfs-multiaddr>
````

Und in den seltsamen Grenzfällen funktioniert es bewundernswert, wie man es von einem gut ausgefeilten POSIX-Dienstprogramm erwarten würde.

````
timothy @yoga ~/c/ipfs-multiaddr> echo "bar" >bar
timothy @yoga ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
Katzenbar
Katze /ipfs/foo
1c1

< Balken

foo
````

Da die Diskussionen über fs: und dweb: endlos zu sein scheinen, brauche ich noch etwas Input zu diesem Pr: https://github.com/ipfs/specs/pull/139

Verwendung von ipfs: löst inzwischen viele Probleme, zumindest für mich.

@pawal Seufz , als ich deinen Kommentar sah, sank mir das Herz, weil ich ziemlich ungeduldig auf eine Antwort auf mein Anliegen gewartet habe.

Pingen Sie @jbenet

Ich bin auch an Antworten auf Ihren vorherigen Beitrag interessiert, da er eine Perspektive auf das Problem aufgezeigt hat, die mir zuvor nicht bewusst war.

//Bearbeiten: Das heißt, ich verfolge das Problem immer noch und hätte geantwortet, wenn ich eine zufriedenstellende Antwort hätte geben können.

+1

Lassen Sie 'ipfs://' funktionieren - als Standard. Bitte.

(Also können alle unsere Apps davon ausgehen, dass sie auf allen Plattformen und überall funktionieren -
überall und auf Visitenkarten)

Vielen Dank.

Julian Smith
Blockfracht™

Die Diskussionen um ipfs: vs. fs: vs. dweb: sind verwirrend und wurden schon geführt, bevor ich mich an diesem Projekt beteiligte. Beim IPFS in Web Browsers Sprint hatte ich endlich etwas Zeit, mich damit

Ich habe hier einen ersten Versuch unternommen, einen Hintergrund für diese Diskussionen bereitzustellen: https://github.com/ipfs/specs/pull/152 Bitte aktualisieren Sie die PR mit Informationen, die ungenau oder unvollständig sind oder allgemein verbessert werden müssen.

Entschuldigung für meine Unwissenheit, aber wie aktualisiere ich eine PR?

@timthelion Sie könnten es wie @jbenet machen und hier Kommentare hinzufügen, oder Sie könnten das Repo klonen, den Zweig auschecken, ändern, übergeben, Patch senden usw

@vasa-develop Da Ihr Kommentar nicht wirklich erklärt, wie die Software die Situation verbessert, betrachte ich ihn als Spam.

Wie wäre es mit DID-URIs? Wie zum Beispiel did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

Dezentrale Identifikatoren (DIDs)

DIDs sind Identifikatoren für Personen . In ihrem Kern sind sie jedoch eigentlich URNs (glaube ich?), also ist eine bessere Frage: "Warum keine URNs"?

Wirklich, die Antwort ist, dass uns URLs zwar Browser-Kompatibilität verschaffen, Pfade uns aber (unter anderem) Dateisystem-Kompatibilität verschaffen, aber URNs uns nicht wirklich viel geben, außer etwas Wohlwollen bei einigen Standardisierungsgremien.

Hinweis: Wir haben tatsächlich bei der URL-Position nachgegeben, um die Browserkompatibilität zu erhalten. Das heißt, der IPFS-Begleiter (Browser-Addon) unterstützt ipfs://... und ipns://... . Wir wollten dweb://ipfs/... usw. verwenden, aber wir brauchten auch eine angemessene Unterstützung des Sicherheitsursprungs (was bedeutet, dass wir den Hash in der ersten Komponente benötigen).

Wir betrachten ipfs://... jedoch als äquivalent zu /ipfs/... und verwenden überall sonst die Pfadsyntax.

@Stebalien woher kommt dir die Idee, dass DIDs für Menschen sind? "People" wird dort kein einziges Mal in der DID-Spezifikation erwähnt. URI-Bezeichner können jede Ressource per Definition identifizieren.

Es spielt keine Rolle, was Sie in Betracht ziehen; Wenn Sie sich nicht an vorhandene Standards halten, können Sie keine Interoperabilität und Unterstützung durch die vorhandene Infrastruktur erwarten.

Woher kommt die Idee, dass DIDs für Menschen sind? "People" wird dort kein einziges Mal in der DID-Spezifikation erwähnt.

DIDs stehen für "digitale Identität".

Dezentrale Identifikatoren (DIDs) sind eine neue Art von Identifikatoren für überprüfbare, „selbstständige“ digitale Identitäten.

So? Alles kann eine _Identität_ haben: Menschen, Tiere, Gebäude, Organisationen, Dinge, Ideen, Dokumente usw. Das ist das Schöne an URIs.
Hast du eigentlich in die DID-Spezifikation geschaut? Ich wiederhole, es gibt nichts Spezifisches für Personen.

Dezentrale Kennung (DID)

Eine global eindeutige Kennung, die keine zentrale Registrierungsstelle erfordert, da sie mit der Distributed-Ledger-Technologie oder einer anderen Form eines dezentralen Netzwerks registriert ist. Das generische Format einer DID ist in dieser Spezifikation definiert. Ein bestimmtes DID-Schema ist in einer DID-Verfahrensspezifikation definiert.