Pour tout te dire mon non plus je ne sais pas ce que c’est exactement ! Mais un regard rapide m’a dit que c’était une bonne idée d’avoir ces détails.
Je trouve la spec vraiment bizarre. Avoir un mélange entre un mot clef (WS2P) et des types (T, A, C, etc.) ne me parait pas intuitif ni facile à parser… Suis-je le seul à penser cela ?
J’aurais plus un vu un truc avec un champ séparé pour la liste de types, du genre :
WS2P:HEAD:TCA:(...)- ou
WS2P:HEAD:T,CA:(...)
EDIT: par aiileurs, je n’ai pas trouvé les explications sur la signification du “clear all”, “mixed”, etc.
Pour la compatibilité c’était plus simple d’ajouter les infos dans un champ existant, ça évite de changer les index, et puis la logique derrière c’est qu’il s’agit bien d’une info intrinsèque au type d’api.
CA : Contacte tout les nœuds en clair (=par l’internet classique)
XM : Contacte les nœuds spécifique a la couche réseau X via la couche réseau X, les autres noeuds via l’interent classique
XA : Contacte tout les nœuds via la couche réseau X
XS : Contacte uniquement les nœuds qui écoutent sur la couche réseau X
Quelle différence entre les 2 dernières options ? Notamment, je ne vois pas l’intéret car on ne peut pas contacter un noeud qui n’a pas déclaré la couche X, si ?
J’aurais plutot vu 2 cas : mixed ou strict, mais pas de all
Si dans le cas de certaines couches réseaux on peut. par exemple avec un noeud TOR je peut contacter les nœuds classiques a travers TOR ou a travers l’internet classique, il s’agit bien de deux comportements très différents 
mais alors à quoi sert le champs version ?
A mon avis, c’est plus clair de passer en WS2P:HEAD:2:(...)
La preuve, dans ce cas Cesium aurait continuer de marcher :
- si (version == 1) parsing comme Duniter < 1.6.14
- si (version == 2) use T, CA, …
1 Like
Du coup les index des champs se décalent en fonction de la version.
Par exemple : que se passera t il si tu as besoin d’un autre type, pour une raison quelconque ?
=> la regexp des anciennes versions de Duniter ne sera plus bonne (ni celle de Cesium), et peu importe la version du HEAD. Aucun intéret d’avoir la version, dans ce cas…
Je n’ai pas réfléchi par rapport aux clients mais par rapport au code du cœur, du point de vue du coeur le head est toujours au même format et ce parse toujours de la même façon. J’ai déjà prévu des heads v2, avec des champs en plus 
bon mais la prochain fois, penses à upgrader directement la version, stp
…et si tu peux repasser la liste de types dans un champ séparé, c’est mieux.
1 Like
Si cela se produit j’upgraderai la version, tu sais on fait ce qu’on peut mais c’est déjà difficile de prendre en compte tout les impacts d’une modification sur le cœur, alors sur les clients… on ne peut pas penser a tout !
1 Like
Voilà c’est noté pour les heads v3 : Planning the improvement of WS2P for duniter 2.0 (#1203) · Issues · nodes / typescript / duniter · GitLab
1 Like
Je sais bien, c’est bien pour cela qu’une spécification relue par plusieurs cerveaux évite quelques problèmes
4 Likes
Dans le message HEAD, quand il n’y a rien d’autre que WS2P:HEAD:, ca veux dire quoi, du coup ?
- privé seulement ?
- ou privé + public ?
EDIT: je pose la question autrement : comment connaitre les endpoints WS2P privés seulement ? cad les noeuds masqués
On ne peut pas savoir, ceci dit s’il existe dans ta bdd un endpoint WS2P avec le même uuid tu peut en déduire que ws2p public est très probablement activé
A partir de la prochaine version, cela correspondra aux head de la forme WS2POXM avec X la couche réseau et M le mode de communication (All, Mixed, ou Strict), dans la plupart des cas ce sera donc WS2POCA:HEAD