Format de la fiche de pair au standard URI/IRI

R&D
1

@kimamila pour ce dernier cas oui c’est normal le ‘/’ n’est pas obligatoire dans Duniter (Duniter le rajoute tout seul pour contacter le endpoint).

D’ailleurs dans WS2Pv2 il faudra choisir entre préfixer toujours le path par un ‘/’ ou jamais. Je propose de ne pas mettre le ‘/’ pour 2 raisons :

  1. On ne met pas les ‘:’ entre le host et le port, c’est le logiciel qui les rajoute tout seul. Par consistance il me semble plus logique de faire de même avec le path :slight_smile:
  2. Ça fait toujours 1 caractère de moins a transmettre. Si on se projette dans un avenir ou l’on a un réseau de 5000 nœuds comme pour d’autres cryptos ben ça fait toujours environ 5ko de moins a stocker et transférer sur le réseau.
3

ce que le document de peering cherche à faire d’après mois c’est très exactement la même chose que vous faites tout les jours, tellement souvent que vous en avez même plus conscience :slight_smile:

chaque fois que vous écrivez une URL dans votre navigateur vous accèdez a une ressource (un noeud) identifiable, ou devrais-je dire localisable ?

une grammaire spécifier et admise dans le monde entier on complétude qui dépassera vos besoin maintenant et plus tard.


je vous laisses admirez la complexité et l’universalité de la chose que je n’ai pas l’intention d’expliquer car justement si je l’utilise c’est pour ne pas et ne plus jamais avoir besoin de le faire :wink: .

supposons comme c’est vérifiable actuellement sur la tristement célébre et tristement redondante fiche de pair /network/ws2p/heads

que constate-t’on ? c’est crado et si c’est crado c’est parce que ça n’as pas été conçus pour être extensible, encore que je ne vois pas ce qui aurais empêché les mème champs d’accepter les deux version du protocole, le format semble retro compatible!!

qu’importe, la question c’est comment faire plus propre bin moi je trouves que les URL c’est pas mal les URI c’est mieux, les IRI c’est la classe international. (enfin, la classe, je sais pas mais international oui !)
C’est le standard accepté par tout les réseau telecom, le monde académique et industriel alors je vois pas de raison de refaire la roue si c’est pour la faire carré.

mes arguments :

  • c’est extensible, comme des urls, avec des paramètres (? X=… &Y=…), pour le sessid, bstamp, …
  • un id pour pointer vers un chapitre # (dans le lien wikipedia ci-dessus par ex.) on pourrais dire #WS2P, #BMA, …
  • des champs user and password qui, chez nous, ce traduisent par pubkey/signature (en plus c’est génial, ça formalise le champ avant et après signature, pas de soucis de séparateurs)

sur le coup j’y ai pas pensé non plus, j’aurais probablement fait la même erreur, (me dire que deux trois champs perso, ça suffira et puis un autre, et puis un autre, et puis merde …) mais je vous promet que quand vous y réfléchissez une seconde… c’est un peu comme la TRM, une fois que tu le sais tu peux plus vraiment le nier…

la liste de pair se simplifie en une simple liste d’URI, plus besoin de multiple champs et si tu veux vérifier les identifiants, signature, tu peux le faire dans le même format, c’est spécifié, formalisé, informatisé,

voila pourquoi je n’appellerais pas cela un protocole, une RFC, une spec ou une référence , car une liste d’URI, franchement mes amis, ça mérite pas de titre, tout juste un nom de variable. mais celui ci existant déjà (heads), pour moi, ça n’est plus une question de choix

2 Likes
4

Maintenant que tu le dis, ça parait évident que ça aurait été l’outil idéal quand on a conçu le format de la fiche de paire. On étais déja conscient de l’universalité de la chose à l’époque, mais en fait ça ne nous a pas du tout sauté aux yeux à quel point c’était adapté à notre besoin.

Il y a probablement quelque chose à faire ici !

2 Likes
5

j’aimerais bien décrire les documents en format RDF pour continuer dans la même idée de format universel et admis partout et par tous. Et devinez, quoi le RDF utilise des URI :wink:

6

faisons preuve d’opportunisme, et profitons d’une nouvel api GraphQL pour tester l’affaire

1 Like
7

Concernant le format des HEADs et des fiches de peer ça impacte également WS2P, du coup si on part sur ta proposition il faut revoir les spec de WS2P.
On peut profiter du passage de WS2Pv2 a WS2pv2 pour intégrer tes propositions :slight_smile:

Ici tu a le format texte sur lequel j’étais parti pour les fiches de peer WS2Pv2 (ce n’est qu’une reprise du format créer par cgeek mais épuré pour avoir juste les infos nécessaires) : rfc/0006_ws2p_v2.md · ws2p_v2 · nodes / common / doc · GitLab

Si tu propose un format URI permettant d’obtenir les mêmes informations je l’intégrerai volontiers :slight_smile:

Le NODE_ID est un nombre généré aléatoirement qui permet de différencier plusieurs nœuds qui auraient la même clé publique, aujourd’hui c’est un entier de 4 octets représenté sous forme hexadécimale.

A partir d’un exemple de ta part pour les fiches de peer je peut essayer de faire un format URI pour les HEADs (a moins que tu ne veuille le faire toi), c’est en faisant qu’on apprend :slight_smile:

8

example

[scheme] :// [pubkey] : [signature] @ [host | ip4 | ip6] : [port] [path] ? sessisd=___ & head=___ & EndPointType=___ & …

les arguments étant optionnels et nommés tu peux rajouter désormais tout ce que tu veux sans changer le mécanisme de signature. reste a déterminer comment exactement on hash l’URI ou l’IRI

9

En fait on à une relation one to many entre la fiche de peer et les endpoints. De plus la fiche de peer indique déjà la pubkey et la signature donc ces infos ne sont pas nécessaires dans le endpoint :wink:

Les conventions URI/IRI semblent adaptées pour un endpoint mais pas pour toute la fiche de peer, quitte a passer les endpoints en URI/IRI peut-être serait t’il plus pertinent de passer la fiche de peer au format RDF ?

D’après cette page du CNRS il y a plusieurs variantes récentes du RDF dont certaines moins verbeuses (notamment le Turtle).

Pour le endpoint que dirait tu de partir sur quelque chose comme ça :

[scheme]://[host | ip4 | ip6] : [port] [path]?feat1=val1&feat2=val2#API_TYPE

Avec par exemple pour un endpoint WS2Pv2 en hidden service tor avec des features :

ws://2k3ylvodphbt3g4j.onion:80?&v=2&def&low&rbf#WS2P

Pour la fiche de peer je ne maîtrise pas suffisamment RDF pour faire une proposition, il y a 5 champs qui doivent être présente au minimum en plus de la liste des endpoints :

  • VERSION
  • CURRENCY
  • NODE_ID
  • PUBLIC_KEY
  • BLOCKSTAMP

Est t’il pertinent de faire une URI/IRI pour représenter ces 5 champs ? Comment met on se groupe de données en relation one to many avec les endpoints ?

J’ai omis la signature qui est un peu a part, faut déjà trouver un format sans la signature car c’est lui qui sera hashé et signé :slight_smile:

10

t’as pas lus ce que j’ai écris, ou alors tu le déforme pour le rendre incohérent

  • t’as enlevé le pubkey@signature qui remplace le user@pass

  • je m’en fou de la relation one to many, je la simplifie en une liste de endpoint que je signe individuellement, c’est tout l’intérêt.

si tu compte les reconstruirent tu peu parce qu’il existe des argument que tu as omis mais moi je m’en fou parce que c’est plus simple, tout le monde comprends et ya plus besoin de doc pour l’expliquer … ou pour l’embrouiller

relis ou alors merci de ne pas déformer ce que j’ai dis pour argumenté dessus !

11

Excuse moi ce n’étais pas mon intention, je t’ai bien lu et je n’avais pas compris que tu souhaitais passer a une liste de endpoints indépendants sans fiche de peer associée.

Donc maintenant qu’il me semble avoir mieux compris ce que tu propose (merci pour la précision), ça signifierai qu’il n’y a plus de fiche de pair, mais seulement une liste de endpoints. Je trouve ça dommage de supprimer la fiche de peer et ceux a plusieurs titres :

  • On ne peut plus faire de statistiques sur le nombre de nœuds sur le réseau, on n’a juste un nombre de endpoints. Chaque nœud étant identifié de manière unique par son couple (NODE_ID; PUBKEY) il faudrait que tout les endpoints d’un nœud redéclarent ce même NODE_ID afin qu’on puisse faire des stats faibles sur les nœuds, ce qui alourdi beaucoup.

  • On ne peut pas avoir la preuve qu’on a bien tout les endpoints d’un nœud, a moins qu’il signe un son groupe d’entpoints et que la fiche de peer devienne de fait ce groupe d’endpoints. Mais ça fait dupliquer N fois les champs CURRENCY, PUBKEY et BLOCKSTAMP, ce qui fait beaucoup de datas répliqués pour rien.

  • En tout les cas ça fait dupliquer PUBKEY et SIGNATURE, N fois pour N endpoints ce qui fait 96 octets en binaire et plus de 120 octets en String, c’est con de répéter N fois ces infos pour le même nœud.

Le blockcstamp est nécessaire pour pouvoir dater la fihe de peer et les endpoints qu’elle contient, ça permet de faire de l’élagage régulièrement pour ne pas garder les endpoints trop vieux.

La currency est nécessaire pour éviter les bug liés aux communications entre 2 nœuds qui ne sont pas sur la même monnaie.

Au final si on choisi ta proposition sans perte de fonctionnalité (donc avec tout les 5 champs commun au nœud sur chaque endpoint) ça fait au moins 200 octets de répliquer dans le vide pour rien. Si on se projette sur un réseau de 5000 nœuds riche en API (et plusieurs endpoints pour certaines api pour les passages de version) une moyenne de 4 endpoint par nœud est très raisonnable. Ça fait 32005000 octets soit environ 3 Mo de données en plus pour rien juste pour les documents du réseau.

Je vois pas ce qu’il y a de compliqué a déclarer a part ces 5 champs communs au nœud ? (currency, node_id, pubkey, blockstamp, signature).

J’aimerais bien l’avis de @cgeek sur cette question :slight_smile:

12

Mais tu reviens à la charge c’est incroyable,

mec si t’en veux pas tu l’utilise pas moi je proposerais ca pis c’est tout, tes calcul il sont foireux et t’est suffisement malin pour t’en rendre compte puisque tu l’as dit toi même rdf et par définitions, les uri ca ce compresse, tu n’est donc ni oblige de tout stocker ni obligé de tout transporter, ou même de le manipulé dans ce format.

si tu emplois mal la spec qui t’est fournis et n’arrive pas a comprendre que tu peux y mettre toute la fiche de pair, c’est ton probleme encore une fois tu as deformé ma prositions tu ne retombe pas sur tes patte et tu fait perdre le temps de tout le monde.

je vais donc te le répetter encore une fois, fou moi la paix, cherche les justification dans ton erreur plutot que de déformer des proposition qui n’ont pas les défaut que tu expose.

en revanche quand tu update une fiche de pair complète, avec tout les champs et la redondance complètement inutile toute les 5 minutes sur des nœuds qui n’en ont pas l’usage, la en effet avec ta méthode tu spam le réseau.

maintenant merci de ne plus commenter, mes propos, tu ne fait que les déformer de facon grossiere c’est insultant. tu me fait perdre mon temps, ma patience, et mon respect des règles du forum. si tu veux binariser, binarise!! et le jour ou tu prouvera faire mieux que mon gzip je t’écouterais mais pas avant. donc adieu

13

Pas besoin de t’emporter de la sorte :slight_smile:

Je ne cherche pas a déformer les propos de qui que ce soit mais a comprendre tes propositions, merci de ne pas faire de procès d’intention en supposant que l’autre déforme tes propos la ils ceux ci n’ont simplement pas été compris :wink:

L’argument de la compression pour distinguer différemment formats n’est pas recevable car tout format peut être compressé. Et plus le format de départ est petit, plus le format compressé sera petit :wink:

Effectivement rien n’oblige a transmettre tout les champs de chaque endpoint, on peut n’envoyer qu’une fois les champs commun a tout les endpoints, une sorte de format compact ok. Il reste cependant 1 champ qui est dupliqué de force dans ta proposition, c’est la signature.

Je suis ok pour partir sur un format de fiche de peer qui n’est qu’une liste de endpoints en URI a 1 condition : que les endpoints ne soient pas signés individuellement mais que tout le groupe de endpoints du nœud soit signé une seule fois (la signature serait alors ajoutée en bas du document de fiche de peer).

Ce qui donnerai une fiche de peer comme ceci :

[scheme] ://[pubkey]@[host|ip4|ip6]:[port][path]?arg1=value1&arg2=value2#API_NAME
...
[scheme] ://[pubkey]@[host|ip4|ip6]:[port][path]?arg1=value1&arg2=value2#API_NAME
SIGNATURE

Ça me semble être un bon compromis entre simplicité et légèreté :wink:

14

non t’as toujours pas lus ma proposition #API_NAME n’as absolument rien a voir avec ?API_NAME=X,Y,Z ou ?API1=1 & API2=1 & … non seulement cette attribut est inutile car il est une redondance de scheme mais en plus je le factorise et c’est précisément la ou on peux mieux economiser les bits moisis que tu n’arrive plus a voir puisque tu a figer le modele.

donc relis toi, enlêve tout le pâté qui est complêtement faux et tu y vera vachement plus clair

Tu verra qu’une URI peut être plus concise que le format actuel .

c’est complètement con, comme si la densité du format n’avait aucune importance dans ton calcul.

Je vois mieux ce qu’il manque a ton raisonnement. le jours ou tu comprendra cela, tu t’apercevra que tu t’est bien fait chier pour pas grand chose. enfin si ça t’amuses mais si tu fais mieux fais le, arrête de polluer mes réponses merci

15

J’aimerai bien un exemple concret de fiche de paire transformée au format URI pour bien comprendre la proposition de @junidev.

3 Likes
16

Pourquoi passer ton temps a faire des débuts de proposition sans expliquer dans le détail puis ensuite te plaindre que l’on* ne comprend pas ou/et que l’on déforme tes propos ?

Ce forum technique est fait pour discuter de chaque propositions d’évol dans le détail, peser le pour le contre des différentes possibilités afin de faire les choix les plus éclairés possibles.
Pour cela il conviens d’apporter les éléments de compréhensions de tes propositions aux autres plutôt que de te plaindre que l’on ne comprend pas.
Y a t’il une personne a par toi qui comprenne intégralement ta proposition a ce stade de la discussion ? Y’a t’il en endroit ou tu a couché ça en détail a l’écrit ? A tu fait une RFC quelque part ?

*je dit on car @Inso aussi pose des questions :wink:

Au lieu d’apporter les éléments de détails qui permettrait de convaincre les autres, tu te plains que tes propos soient déformés, ça me semble une approche a la fois pas constructive, pas respectueuse, et qui ne peut que susciter l’inimitié (et donc t’isoler), est-ce vraiment ce que tu veut ?

17

Oui la @Junidev je comprends pas le ton que tu utilises… On a le droit de ne pas te comprendre du premier coup, sans pour autant être malveillant.
Restons s’il vous plait sur un ton calme.

Ta proposition est très certainement intéressante, mais la sera encore plus si chacun s’y retrouve, avec des besoins propres.

Enfin il me semble.

A toute pour la café ! :slight_smile:

1 Like