Je ne le trouve pas dans la documentation maintenant, mais je me souviens d'une explication dans le sens suivant:
IPFS est un système de fichiers et pour les systèmes de fichiers, vous utilisez des chemins plutôt que des URL. Les URL peuvent être comprises comme une laideur qui représente un échec à unifier l'accès sur votre machine locale et sur les machines distantes. IPFS évite cette laideur en traitant les fichiers locaux et distants de la même manière et la méthode d'adressage des fichiers est un chemin standard.

Il peut être utile d'imaginer monter l'intégralité de l'IPFS sous /ipfs, puis d'accéder aux fichiers comme s'ils n'étaient que cela : des fichiers dans votre système de fichiers.

Matériel de lecture supplémentaire :

Longue discussion : https://github.com/ipfs/go-ipfs/issues/1678
Bref résumé du consensus actuel : https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

De plus, des travaux sont en cours pour réconcilier les adresses absolues IPFS avec la résolution d'URL standard et pour s'attaquer à l'identification des origines avec (ou sans ?) fs: paths .

Et https://github.com/ipfs/in-web-browsers/issues/28 avec un lien vers un projet de spécification. cc @lgierth

:( Après avoir lu ipfs/go-ipfs#1678, je ne suis même plus sûr de m'intéresser à IPFS :( . C'était une terrible non-discussion.

Je n'ai vraiment pas envie d'entrer dans le hangar à vélos, mais ça

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.
n'est pas une idée qui m'excite. J'imagine tout d'un coup avoir une racine système qui ressemble à
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

Ce n'est pas un concept qui m'attire. J'ai l'habitude d'organiser mon système comme je l'aime et de monter mes systèmes de fichiers comme je le souhaite. Mais ce n'est pas vraiment ce qui me rebute. Vous êtes libre de monter ipfs où vous voulez. Je suis découragé par l'approche mégalomaniaque du "réinventons tout". Je suis venu à IPFS parce que je voulais un CAS distribué. C'est tout ce qui m'intéressait. Je me fiche de fusionner Unix avec le Web. Mais après avoir lu cette discussion, IPFS ne semble plus être un produit qui m'aidera à obtenir un CAS distribué, cela ressemble à un produit qui dictera comment j'utilise et nomme le système de fichiers de mon ordinateur et une fois que les auteurs dictent une chose, ils auront peut-être quelques autres nouvelles idées sur la façon dont mon ordinateur doit être configuré et organisé. Je ne peux pas prédire l'avenir, mais je n'aime pas l'approche.

C'est dommage, car j'AIME VRAIMENT l'implémentation CAS distribuée d'IPFS. Je rêvais depuis longtemps d'avoir un CAS distribué :(. Il va donc falloir que je repasse en mode recherche et regarde d'autres CAS distribués...

@timthelion Je vois que vous (tout comme moi) vous souciez vraiment de CAS et IPFS.
Je ferai de mon mieux pour apaiser vos soucis.

Je suis sûr que vous pouvez utiliser IPFS comme CAS sans jamais le monter n'importe où dans votre système.
La façon dont je pense aux chemins /ipfs/Qm.. est qu'ils ne sont qu'un raccourci mental qui simplifie les conversations et les liens (tout comme les URL ordinaires).

Personnellement, je suis d'accord que la situation des "gestionnaires de protocole" et de la "sémantique d'adresse canonique" peut sembler un gâchis pour un spectateur en ce moment, mais de bonnes personnes travaillent sur des solutions pragmatiques peuvent fonctionner en ce moment (par exemple https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7).

C'est une conversation continue et ces choses prennent du temps.

La direction générale du projet (mon opinion personnelle) est de _"créer des outils utiles qui réutilisent les normes de l'industrie là où c'est pratique de le faire"_ plutôt que de _"tout réinventer quoi qu'il arrive"_.

Je ne pense pas que tu devrais t'inquiéter pour l'avenir. Les outils IPFS suivent _"la méthode unix"_, ce qui signifie que de nombreux petits outils, bibliothèques et commandes (similaires aux sous-commandes git ) qui font une chose peuvent être enchaînés pour créer quelque chose de plus grand.

C'est vous qui décidez quelles pièces sont utilisées. ⚙️ 🔧

J'espère que personne ne prendra mon dernier message dans le mauvais sens. Je ne veux pas dire "vous êtes tous des connards je pars". Je suppose que des milliers de personnes ont jeté un œil à IPFS, ont décidé qu'elles n'aimaient pas quelque chose, et sont parties, sans jamais écrire pourquoi... Je le fais souvent. Je regarde simplement une technologie avec désinvolture et j'en choisis une autre en fonction d'un petit détail qui me déplaît. J'ai décidé de ne pas le faire parce que je voulais ne pas être un membre silencieux d'une majorité silencieuse, et aussi, parce que je n'ai pas beaucoup d'autres choix :D, mais il semble que je vais devoir attendre ipfs pour prendre en charge fs:// ou tout ce que les chefs de projet choisissent avant de commencer à utiliser ipfs dans mon projet actuel et je ne pourrai sérieusement commencer à regarder IPFS que jusqu'à ce que de véritables URL normales existent.

Je suis découragé par l'approche mégalomaniaque du "réinventons tout".

Vous vous laissiez emporter, rien dans tout cela n'est "mégalomane" ou même une réinvention. Nous parlons de chemins de fichiers utilisés comme ils le sont toujours. Le montage sur /ipfs n'était qu'un exemple pour illustrer les choses, pas l'idée de base.

J'ai l'habitude d'organiser mon système comme je l'aime et de monter mes systèmes de fichiers comme je le souhaite.

Personne ne vous oblige à monter IPFS en tant que système de fichiers local @timthelion . Il s'agit d'une fonctionnalité que vous pouvez utiliser et vous pouvez décider des chemins à monter. Ne pas aimer une fonctionnalité désactivée par défaut me semble être une faible raison de rejeter IPFS dans son ensemble. Mais bon, j'espère que tu changeras d'avis à l'avenir et que tu nous rejoindras à nouveau.

Je n'ai pas vu un seul produit dont tout le monde aime chaque fonctionnalité.

Il convient également de mentionner que cela ne réinvente rien. C'est "désinventer" quelque chose.

Indépendamment de nos opinions divergentes, le gestionnaire fs:// - qui vous offrira le support transparent que vous souhaitez - est en cours d'implémentation au moment même où nous parlons, et vous pouvez déjà l'utiliser avec des extensions de navigateur . Nous travaillons également sur des implémentations PoC pour permettre aux navigateurs de l'utiliser de manière native. Vous pouvez également implémenter sa prise en charge dans des applications enveloppées d'électrons. Peut-être pouvez-vous contribuer à ces efforts pour les faire avancer plus vite.

"Tu t'emportais, rien dans tout ça n'est 'mégalomane' ou même une réinvention."

J'interprète https://github.com/multiformats/multiaddr comme étant magalomaniaque et réinventant. C'est un format différent d'une URL mais il représente les mêmes données. Vous avez besoin d'une sacrée bonne raison pour réinventer une norme aussi importante.

Je vais être un peu plus détaillé.

"Nous parlons de chemins de fichiers utilisés comme ils le sont toujours."

Je pense que j'obtiens où vous voulez en venir avec cette idée. L'"erreur" que vous essayez de corriger est-elle le fait que vous ne pouvez pas traiter les ressources Web comme des fichiers normaux ? Comme ça je ne peux pas faire cat http://google.com/index.html ? Je peux être d'accord avec vous que c'est triste que ce soit impossible. Si je devais écrire un système d'exploitation, je rendrais la fonction open capable d'ouvrir des URL vers des fichiers. Peut-être qu'un tel changement pourrait même être apporté à Linux. Votre approche est différente, vous essayez d'insérer des ressources Web dans la hiérarchie de fichiers POSIX. S'il y a une autre raison pour laquelle vous pensez que les URL sont une erreur, veuillez m'en informer.

Je peux certainement sympathiser avec votre objectif de faire en sorte que les ressources Web agissent comme des fichiers normaux. Votre méthode pour réparer "l'erreur", cependant, me semble être une pente assez glissante. Si je choisis de monter les systèmes de fichiers ipfs, leur point de montage est un nouveau comportement pour moi. Je ne vois aucun autre programme en mode utilisateur que je pourrais installer sur mon système, ce qui créerait plusieurs répertoires directement dans mon répertoire racine.

Aujourd'hui, quand je fais ls / j'obtiens :

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

Avec les chemins proposés par multiaddr je verrais plutôt :

$ 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

Et avant que vous m'accusiez d'avoir mal interprété la norme, je vous rappelle que je l'interprète de la manière exacte dont les chemins unix ont TOUJOURS été interprétés.

Évidemment, je ne vais pas vouloir faire un tel gâchis de mon répertoire racine. Donc donc, je choisirai de ne pas monter ces chemins.

Dans mon cas, ce n'est pas mon choix de toute façon, je veux écrire un logiciel qui utilise IPFS et ce n'est pas à moi de décider si l'utilisateur monte ou non ces chemins. Mais je veux toujours que mes utilisateurs puissent ouvrir un fichier partagé sur IPFS aussi facilement qu'un fichier sur leurs machines locales. Alors, comment écrire ce code ? Si ipfs utilisait des URL standard, je transmettrais simplement tout ce qui commençait par ipfs:// à ipfs et tout serait simple.

Mais lorsque mon programme regarde une chaîne qui commence par / , il l'interprète comme étant un chemin absolu vers un fichier ou un répertoire sur la machine de quelqu'un, généralement la machine sur laquelle le code s'exécute. Si on lui dit de visiter un chemin commençant par / , alors il l'interprétera CERTAINEMENT comme étant un chemin absolu vers un fichier ou un répertoire sur la machine locale. Si /ipfs n'existe pas sur ma machine, le programme devrait renvoyer une erreur de fichier introuvable. Je ne peux pas penser à un autre exemple où un chemin absolu que le programme est invité à visiter mène ailleurs qu'à un fichier ou un répertoire sur la machine locale. Donc pour moi, en tant qu'utilisateur/développeur Linux de longue date, c'est un nouveau comportement.

Si mon application essayait d'ajouter la prise en charge de multiaddr, les choses deviendraient assez rapidement poilues. Que se passe-t-il si l'utilisateur exécute :

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

et l'utilisateur dispose d'un serveur Web qui stocke ses fichiers html dans /http . Pas du tout inouï. Mon programme doit-il résoudre ce problème en une adresse multiaddr ou dans le fichier local ?

J'ai déjà écrit du code avec un support primitif pour ouvrir des URL en python. C'était assez facile. Mais comment changer mon code pour qu'il résolve sans ambiguïté à la fois les chemins multiaddr et les chemins de fichiers locaux ?

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

Je ne pense vraiment pas que ce soit possible. Par conséquent, il me reste à ne pas implémenter le support multiaddr et à ne supporter que les URL normales. Cela semble bien au début, mais les utilisateurs d'ipfs seront constamment exposés à des adresses multiaddr vers des objets ipfs, et mon programme, qui annonce le support IPFS, prétendra que ces chemins n'existent pas. Donc, peu importe comment j'implémente le support, mon programme va être brisé. Soit sa prise en charge d'ipfs sera interrompue, soit sa prise en charge du système de fichiers POSIX standard sera interrompue.

Il existe des moyens de résoudre ce problème, potentiellement. L'une serait d'abandonner complètement multiaddr. Une autre consisterait à modifier multiaddr afin qu'il limite au moins ces chemins à un seul sous-répertoire. Donc plutôt que d'écrire /ipfs/hash/blah on écrirait /webfs/ipfs/hash/blah . Et ls / renverrait :

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

Ce serait quelque chose avec lequel je pourrais vivre, et peut-être même prendre du retard. Mais la situation actuelle est que je ne connais aucun moyen satisfaisant d'implémenter le support ipfs.

Permettez-moi d'en venir à un exemple encore plus CONCRET. Imaginez que j'écrive un programme qui convertit le démarquage en PDF. Et je veux pouvoir prendre en charge l'inclusion d'images d'IPFS. Alors l'utilisateur écrit :

grenier.md
````

Des trucs que j'ai trouvé dans mon grenier

Une vieille boîte de pierres.

````

Et court

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

Comment mon programme est-il censé résoudre ces chemins d'image ? Est-il censé supposer que le système de fichiers /ipfs est monté ? Nous avons déjà convenu que les utilisateurs ne sont pas obligés de monter /ipfs . Le programme doit-il traiter /ipfs/ comme un préfixe spécial ? Cela semble bizarre et cassé. Le programme doit-il uniquement prendre en charge fs:// et renvoyer une erreur, fichier introuvable compte tenu de ces chemins ? cela semble raisonnable, mais confondra les utilisateurs habitués à la norme multiaddr. Il n'y a tout simplement pas de bonne façon de sortir du sac ! :/ :(

édité pour clarification

Merci d'avoir fourni des cas d'utilisation @timthelion. C'est formidable d'avoir des gens qui offrent des exemples concrets afin que nous puissions nous assurer que les protocoles fonctionnent pour de vraies personnes.

Clarification de l'exemple "tout monter sur /"

Comme @lidel l' a souligné, les gens travaillent actuellement sur la conception du schéma d'adresse, il n'y a donc pas encore de documentation. Il semble que l'exemple de montage de système de fichiers de @jbenet ait semé la confusion. C'est juste un exemple destiné à aider les gens à réfléchir au modèle conceptuel derrière le schéma d'adresse fs: ou dweb: . Il ne propose pas que nous forcions tout le monde à monter tous ces répertoires sur leurs systèmes de fichiers. Il propose plutôt que nous puissions _identifier_ le contenu avec des adresses qui se comportent comme si le contenu était monté sur votre système de fichiers local, car cela nous permettra d'interagir avec le contenu web/dweb à l'aide des outils unix/posix.

Lorsque nous rédigeons les docs, nous devrons veiller à ce que cela soit clair. Merci de l'avoir signalé.

En réponse à votre exemple de "trucs dans le grenier", je pense que l'idée est que vous utiliseriez fs:/ dans vos liens, comme ceci :

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)

Avoir des adresses simples ET unifier les schémas

Note latérale : Il y a aussi le problème de garder les adresses simples. Dans ce commentaire , @nicola a proposé un moyen astucieux de prendre en charge les adresses ipfs:/ et ipns:/ sans rompre avec le schéma d'adresse fs: / dweb: . La gymnastique de conception de protocole impliquée est (à mon humble avis) étrangement déroutante, mais au final, cela vous permettrait d'avoir des liens dans votre démarquage comme ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV tout en permettant aux gens d'adresser le même contenu que fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV ou juste /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV dans un contexte unix/posix.

Les chemins absolus dépendent du contexte

Concernant les chemins absolus, vous avez dit:

Si on lui dit de visiter un chemin commençant par /, alors il l'interprétera CERTAINEMENT comme étant un chemin absolu vers un fichier ou un répertoire sur la machine locale.

Gardez à l'esprit qu'il existe de nombreux précédents pour que les chemins absolus soient relatifs à _context_ plutôt que relatifs à la racine du système de fichiers. L'exemple le plus courant est celui des chemins absolus en HTML, qui sont relatifs à la racine du origin actuel, et non relatifs à la racine du système de fichiers du serveur. Si j'ai un code qui fonctionne dans un contexte qui suppose que tous les chemins sont fs: ou dweb: , il est tout à fait valide que ce code utilise des adresses commençant par /ipfs/ et il y a de nombreuses façons pour ce code de résoudre les chemins sans littéralement monter ipfs à /ipfs sur votre système de fichiers.

Ce sont mes 2 centimes :

• Chaque fichier est sous fs:/ , de la même manière que chaque domaine est sous http:/ .
• Je ne monte pas le système de noms de domaine sur / sur mon système de fichiers, de la même manière que je ne monte pas l'intégralité d'IPFS sur mon / . Dans les deux systèmes, le point de référence est / rapport au schéma ( http:/ , fs:/ ).

Je pense que dans la plupart de vos exemples, il y a cette notion que chaque système de fichiers a monté ipfs sur / . Donc, avoir fs:/ casse pas le format URI.

Il propose plutôt que nous puissions identifier le contenu avec des adresses qui se comportent comme si le contenu était monté sur votre système de fichiers local, car cela nous permettrait d'interagir avec le contenu web/dweb à l'aide des outils unix/posix.

"Cela nous permettra d'interagir avec le contenu web/dweb en utilisant les outils unix/posix." Pouvez-vous s'il vous plaît me donner un exemple concret d'un cas dans lequel la syntaxe non préfixée fs: serait utilisée avec un outil unix ? D'une manière ou d'une autre, je ne comprends toujours pas.

J'ai essayé de trouver un exemple moi-même, mais je ne vois aucun exemple dans lequel la syntaxe préfixée /ipfs conforme à multiaddr a du sens.

J'ai essayé de créer un script wrapper pour l'utilitaire diff dans bash qui prenait en charge ipfs en utilisant le schéma multiaddr :

````
Timothée @yoga ~/c/ipfs-multiaddr> chat multiaddr-diff

!/bin/bas

get_multiaddr_or_normal_file_getter(){
si [[ $1 == /ipfs/* ]] ;
ensuite
file_getter="chat ipfs $1"
autre
file_getter="chat $1"
Fi
echo $file_getter
}

fichier1= get_multiaddr_or_normal_file_getter $1
fichier2= get_multiaddr_or_normal_file_getter $2

différence <($fichier1) <($fichier2)
````

Cela fonctionne dans le cas naïf sur les fichiers normaux et les fichiers ipfs :

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

f) Sacrifiez votre premier-né au DIEU Laurath le premier
pleine lune de l'année paire suivante.

````

Mais lorsqu'il m'arrive d'essayer de l'utiliser pour opérer sur un vrai fichier existant dans un répertoire /ipfs/ que j'ai créé, j'obtiens une erreur :

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

Je ne sais pas comment je pourrais éditer cet utilitaire, afin qu'il puisse fonctionner de manière fiable avec les adresses multiaddr et les fichiers Unix normaux.

D'un autre côté, créer un wrapper diff qui ne prend en charge que la syntaxe de style d'url n'est pas plus difficile :

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

!/bin/bas

get_multiaddr_or_normal_file_getter(){
si [[ $1 == fs:* ]] ;
ensuite
préfixe="fs :"
chemin_interne=${1#$préfixe}
file_getter="chat ipfs $chemin_interne"
autre
file_getter="chat $1"
Fi
echo $file_getter
}

fichier1= get_multiaddr_or_normal_file_getter $1
fichier2= get_multiaddr_or_normal_file_getter $2
echo $fichier1
echo $fichier2
différence <($fichier1) <($fichier2)
````

Cela fonctionne aussi bien, et les 3 caractères supplémentaires ne font sûrement pas beaucoup de différence lorsque le hachage est déjà long d'un bazillion et demi de caractères.

````
Timothée @yoga ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
chat ../subuser/COPYING.LGPL
chat ipfs /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) Sacrifiez votre premier-né au DIEU Laurath le premier
pleine lune de l'année paire suivante.

Timothée @yoga ~/c/ipfs-multiaddr>
````

Et dans les cas étranges, il fonctionne admirablement comme on pourrait s'y attendre d'un utilitaire POSIX bien poli.

````
Timothée @yoga ~/c/ipfs-multiaddr> echo "barre" >barre
Timothée @yoga ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
barre de chat
chat /ipfs/foo
1c1

< barre

fou
````

Étant donné que la discussion sur fs : et dweb : semble être sans fin, j'ai encore besoin d'informations sur ce pr : https://github.com/ipfs/specs/pull/139

Utiliser ipfs : en attendant résout beaucoup de problèmes, du moins pour moi.

@pawal Sigh, quand j'ai vu votre commentaire, mon cœur s'est serré, car j'attendais avec impatience une réponse à mes préoccupations.

Ping @jbenet

Je suis également intéressé par les réponses à votre message précédent car il a mis en évidence une perspective sur le problème dont je n'étais pas au courant auparavant.

//edit: C'est-à-dire que je suis toujours le problème et que j'aurais répondu si j'avais une réponse satisfaisante à donner.

+1

Faites fonctionner 'ipfs://' - en standard. S'il te plaît.

(Ainsi, toutes nos applications peuvent supposer que cela fonctionne sur toutes les plates-formes, partout -
n'importe où, et sur des cartes de visite)

Merci.

Julien Smith
Blockfreight™

Les discussions autour de ipfs: contre fs: contre dweb: sont confuses et se déroulent depuis avant que je ne m'implique dans ce projet. J'ai finalement eu un peu de temps pour m'y retrouver pendant l' IPFS dans les navigateurs Web Sprint . J'écris une explication de l'ensemble du tableau, avec un aperçu des différentes options et arguments, que je soumettrai en tant que PR sur ipfs/specs plus tard dans la journée. J'inclurai des exemples et des références aux discussions que je connais. Espérons que cela apportera une certaine clarté et nous permettra d'avancer sur la voie la plus pragmatique sans commettre d'erreurs qui causent de gros problèmes à long terme.

J'ai tenté de fournir un contexte pour ces discussions ici : https://github.com/ipfs/specs/pull/152 Veuillez mettre à jour le PR avec des informations inexactes, incomplètes ou nécessitant généralement une amélioration.

Désolé pour mon ignorance, mais comment mettre à jour un PR ?

@timthelion Vous pouvez le faire comme @jbenet et ajouter des commentaires ici ou vous pouvez cloner le référentiel, vérifier la branche, modifier, valider, envoyer un correctif, etc.

@vasa-develop comme votre commentaire n'explique pas vraiment comment le logiciel améliore la situation, je le considère comme du spam.

Qu'en est-il des URI DID ? Comme did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

Identifiants décentralisés (DID)

Les DID sont des identifiants pour les personnes . Cependant, à la base, ce sont en fait des URN (je pense ?), donc une meilleure question est : "pourquoi pas des URN" ?

Vraiment, la réponse est que si les URL nous donnent la compatibilité du navigateur, les chemins nous donnent la compatibilité du système de fichiers (entre autres), mais les URN ne nous donnent pas vraiment grand-chose d'autre que de la bonne volonté avec certains organismes de normalisation.

Remarque : Nous avons en fait cédé sur la position de l'URL pour obtenir la compatibilité du navigateur. Autrement dit, le compagnon IPFS (extension de navigateur) prend en charge ipfs://... et ipns://... . Nous voulions utiliser dweb://ipfs/... etc. mais nous avions également besoin d'un support d'origine de sécurité approprié (ce qui signifie que nous avons besoin du hachage dans le premier composant).

Cependant, nous considérons que ipfs://... est équivalent à /ipfs/... et utilisons la syntaxe du chemin partout ailleurs.

@Stebalien , d'où vous vient l'idée que les DID sont pour les gens ? "personnes" n'y est pas mentionné une seule fois dans la spécification DID. Les identifiants URI peuvent identifier n'importe quelle ressource par définition.

Peu importe ce que vous considérez; si vous ne respectez pas les normes existantes, vous ne pouvez pas vous attendre à l'interopérabilité et à la prise en charge par l'infrastructure existante.

d'où vous vient l'idée que les DID sont pour les gens ? "personnes" n'y est pas mentionné une seule fois dans la spécification DID.

Les DID sont pour "l'identité numérique".

Les identifiants décentralisés (DID) sont un nouveau type d'identifiant pour une identité numérique vérifiable et "auto-souveraine".

Alors? Tout peut avoir une _identité_ : les personnes, les animaux, les bâtiments, les organisations, les choses, les idées, les documents, etc. C'est la beauté des URI.
Avez-vous réellement regardé dans la spécification DID? Je le répète, il n'y a rien de spécifique aux personnes.

Identifiant décentralisé (DID)

Identifiant unique au monde qui ne nécessite pas d'autorité d'enregistrement centralisée car il est enregistré avec la technologie de grand livre distribué ou une autre forme de réseau décentralisé. Le format générique d'un DID est défini dans cette spécification. Un schéma DID spécifique est défini dans une spécification de méthode DID.