Il y a des tas de sortes d'identificateurs pour désigner les trucs (les choses, les objets, les ressources) qu'on récupère sur le réseau. Une technique amusante est que l'identificateur dépende du contenu de l'objet, ce qui permet de vérifier qu'on a récupéré le bon objet, quelle qu'était la source. C'est le cas des magnets de BitTorrent, par exemple :
http://fr.wikipedia.org/wiki/Magnet_(standard)
Freenet avait déjà montré la voie il y a bien longtemps, avec ses CHK (Content Hash Key).
Voici une nouvelle déclinaison du concept, cette fois sous forme d'une norme, le RFC 6920, qui standardise les NI (Named Information) :
# NIH
Posté par rakoo (site web personnel) . Évalué à 10.
Merci pour cette article de vulgarisation qui me permet de tirer quelques conclusions que j'espère pas trop hâtives. Là, ma première question c'est : que résoud le RFC 6920 que ne résoud pas le lien magnet ? Je vais essayer de voir ce qui différencie les deux, parce que pour moi les liens magnets répondent déjà à pas mal de choses.
Le cahier des charges est plutôt simple :
Des deux côtés, le contenu est identifié via une somme de contrôle. Celle-ci est plus ou moins sujette à collisions, mais sa nature (MD5, SHA1, …) est toujours spécifiée. Chacune des solutions est également capable de répondre au deuxième point, via le paramètre as ou le paramètre xs pour le lien magnet, et via l'_autorité_ pour ni.
La première différence apparait ici : les liens magnet autorisent plusieurs sources acceptables alors que ni n'en autorise qu'une seule. Naïvement, on pourrait se demander quel est l'intérêt de ne proposer qu'une seule source puisque cette source est facultative et interchangeable ? C'est peut-être pour garder la hiérarchie connue d'une URI classique, qui n'autorise qu'une seule source, mais du coup ça fait perdre en possibilités.
Le deuxième point faible que je vois dans ni est que l'URL alternative est quasi imposée : c'est forcément du HTTP(S), c'est forcément dans la hiérarchie
.well_known/ni/sha256/<blabla>. Je ne vois pas de problème particulier avec le deuxième point, mais par contre pour le premier, on peut se demander : pourquoi HTTP seulement ? Note que rien n'empêche un client de tester autre chose (disons FTP) mais rien ne permet de dire qu'il trouvera quelque chose (à moins d'attendre que le RFC en parle et commence à mettre du SHOULD). À l'inverse, avec un lien magnet, le protocole alternatif est précisé.Le seul vrai avantage que je trouve à ni est nih: une réflexion sur comment communiquer un hash via un moyen qui peut couper les mots ou être facilement dégradé. Ça donne des trucs presque lisibles.
Au final, j'ai l'impression qu'on se retrouve avec la même situation qu'IRC et XMPP : on a d'un côté un protocole bidouillé au fil des âges, sans vrai documentation (il y a bien des RFC pour IRC, mais il semblerait que chacun fasse plus ou moins ce qu'il veut dans son coin…), mais utilisé par plusieurs milliers de personnes, qui fait ce qu'on lui demande et même plus, et de l'autre côté un protocole très bien documenté, qui est le fruit de nombreuses discussions, et qui du coup peut être un guide pour le développeur perdu, mais qui a du mal à prendre parce qu'il ne se démarque pas suffisamment de ce qui existe déjà (en dehors de Google et Jabber.org, quel grand nom utilise une version ouverte de XMPP ?). Les liens magnets sont déjà utilisés par des millions de personnes, est-ce que le changement vers ni a du sens ?
# URN ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
À ce que je vois, il s'agit d'URI de type URL. Est-ce vraiment pertinent ? Tout comme les schémas news, mid et magnet, cela me semble un mésusage des URL pour ce qui devrait être des URN…
[^] # Re: URN ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Non, les URI "ni" ne sont pas forcément des URL. Ils peuvent l'être (si on met l'autorité) mais ce n'est pas obligatoire.
Et le but est justement de faire mieux que les URN. Ceux-ci ne sont pas « actionnables », on ne peut pas s'en servir pour récupérer une ressource. C'est bien pour cela que les URN ont eu peu de succès en pratique. (Avant les "ni", il y avait eu une proposition de faire la même chose avec des URN, draft-thiemann-hash-urn, mais elle n'avait pas abouti.)
# Sacré Graal
Posté par BAud (site web personnel) . Évalué à 5.
Heureusement qu'il y a des RFC comme celle-ci et les chevaliers qui disent
ni!Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.