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 :
identifier un contenu uniquement par un identifiant
indiquer une source possible ou le contenu est disponible
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 ?
# NIH
Posté par rakoo (site web personnel) . En réponse au journal Nommer les choses par leur contenu, une norme. É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 ?