Peering document: endpoint has strange suffix `%eth0` or `%wlan0` (Duniter v1.6.29)


#1

Bonjour à vous,

Depuis quelques temps, sur mon noeud g1.duniter.fr/network/peers (resté en v1.6.29) je vois passer des endpoints comme celui là :

BASIC_MERKLED_API artisannumerique.fr 37.187.100.37 fe80::222:4dff:feaa:cb4e%eth0 10900

ou

BASIC_MERKLED_API 192.168.43.5 fe80::c8c4:3999:79c5:54f8%wlan0 10900

A quoi correspon ce suffixe %eth0, et %wlan0 ?
Est-ce un bug de Duniter 1.6 ?
cc @cgeek


#2

Cela me pose problème pour l’indexation des endpoints, dans les pod Cesium+


#3

Je tombe aussi sur plusieurs autres cas :

  • des endpoints du type BMAS g1.cgeek.fr (sans le port)- jusqu’ici il était obligatoire, non ?
  • des endpoints WS2P dont le path est ws2p et non /ws2p.

Est-ce normal, ou bien s’agit-il d’erreur ?


#4

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

#5

Ce message a été signalé par la communauté et temporairement masqué.


#6

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


#7

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 !


#8

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:


#9

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