La je pense qu’il ya qqch a faire avec les arbres de merkel, d’ailleurs on pourrait en imbriquer deux :
chaque nœud pourrait avoir un arbre de merkel du HEAD des nœuds auxquels il est directement connecté
Il serait ainsi très rapide de savoir quel head a été modifié 
C’est déjà le cas avec les nœuds membres calculant.
“zéro config” donc a terme quand cet API sera stable elle sera activée par défaut sur tout nœud duniter avec une clé membre, tout comme le calcul de blocks s’active par défaut, c’est transparent pour l’utilisateur 
edit : grilled par Eloïs.
En quoi la situation aujourd’hui serait moins centralisée justement ?
En fait, il me semble que l’exposition doit être le comportement par défaut s’il est possible. Sinon, on peut vite tomber dans une situation délicate où « plus rien ne se partage », notamment les blocs. Blockchain arrêtée, fin de l’histoire. Aujourd’hui cette partie fonctionne bien car les utilisateurs mettent un point d’honneur à ce que leur nœud soit bien visible en vert dans Sakia / Cesium.
Donc pourquoi pas avoir l’exposition activée par défaut ? Notamment si UPnP est présent et fonctionne, ça me semble important.
Mais après il y a une problématique encore plus profonde … c’est justement d’être « exposé » publiquement. S’il y a une liste publiquement consultables des nœuds existants, alors une personne avec suffisamment de moyens peut assaillir ces nœuds de connexions zombies. Je ne sais pas dans quelle mesure c’est possible, mais j’y pense et ça fait froid dans le dos.
L’idéal serait donc que ce point de connexion soit a minima privé, et même mieux, dynamique.
Mais je n’en suis pas là 
Aujourd’hui, les gens n’ont pas le choix d’exposer s’ils veulent calculer. Il y aura donc bien une différence avec des nœuds écrivains de la blockchain exposés qui ont un poids plus important que des nœuds écrivains de la blockchain non exposés.
Demain les gens en revanche auront le choix sauf si leur box est mal configurée et autorise UPnP et dans ce cas on leur force la main. C’est une solution…
On peut imaginer que Remuniter rémunère au double les noeuds qu’il arrive à contacter depuis l’extérieur par exemple…
A noter que pour les clients, ces noeuds n’apparaitront toujours pas en vert. Mais au moins, ils répartiront bien le calcul !
Ah non, regardes Galuel n’expose pas son nœud et calcule quand il le veut. C’est possible parce que le nœud Duniter pull également, ce qui est juste l’ancêtre HTTP de WS2P.
Dans ce cas autant pour moi, cette asymétrie existe déjà.
Après, même si l’on “force” la main, l’UPnP même aujourd’hui est toujours temporaire, je fais bien attention à ça.
De même, le logiciel peut avertir l’utilisateur de ce comportement, il n’y a pas à lui cacher. Enfin bon, Duniter est annoncé comme un logiciel réseau P2P aussi, donc ça devrait pas être une surprise non plus 
Première proposition :
Hésitez pas à relancer d’autres idées qui vous paraîtrait mieux
cgeek
tu peux developper ce a quoi tu pense quand tu souhaite une communication “bidirectionnelle” dans ce dernier post ?
.Protocole d’API gRPC pour l’api WS2P?
On a toujours le meme modele,
Couche TCP
un client qui instancie une requete sur un serveur.
Tant que ni l’un ni l’autre ne rompt cette communication, elle est “bidirectionnelle”.
ex du réseau internet et les navigateurs web.
client instancie une requete. Le serveur répond est clos aussi tôt la connexion.
D’où, les websockets, au dela d’une consideration de sécurité en +:
client instancie une requete, le serveur maintient la connection.
la connection se faisant de point à point, TCP assure la négociation à contrario de la couche UDP
qui n’assure pas “ce deal” de la connectivité. Faut l’implementer, ce qui n’est pas forcement mauvais puisqu’il faut se faire un petit protocol de la trame de donnée, qui plus est tu peux gérer (+ ou -) cette notion de bande passante que l’on souligné précédemment.
Cependant UDP permet le broadcast et donc de transmettre les datas a plusieurs points simultanement.
C’est pourquoi je m’interroge sur ce que tu as besoin comme type de connexions ?
Si je comprends bien, c’est pour communiquer une liste -publiquement - d’adresse (les noeuds duniter)
à partir des quels l’on peut se connecter ?
J’ai pas encore la vision en tête globale et de proposition a faire,
je me demande si la capacité de pouvoir broadcaster les infos peut être envisagé ?
Oui, mais dans le sujet gRPC celui-ci est construit sur un mode client/serveur, et donc ne permet pas de pousser de données depuis le serveur vers le client. A fortiori si ledit client est derrière un NAT+firewall.
edit : je sais bien, en théorie gRPC peut le faire. Mais ils ne l’ont pas fait, ça ne fonctionne pas, faut patcher gRPC pour ça.
J’ai besoin d’une communication bidirectionnelle, type serveur/serveur, même si l’un des 2 est derrière un NAT+firewall avec tous ses ports fermés. Qui plus est, je ne veux pas réimplémenter une couche réseau mais me servir de technos déjà éprouvées.
Le WebSocket remplit pleinement cet objectif aujourd’hui, en plus d’être largement adopté.
Auxquels se connecter, oui.
En théorie oui, mais ça ne me paraît pas indiqué pour toutes les situations. Un simple multicast (les WebSocket) avec rebond suffit.
Autre terminologie que j’aimerais adopter : parler de « document pool » ou « docpool » pour signifier piscine en anglais.
C’est pas mieux ?
A propos des noeuds ou des piscines ? Je ne suis pas sur de comprendre.
À propos des piscines. Dire sandbox me paraît moyen.
Je disais ça vu que tu parlais terminologie.
Ok, je suis d’accord que sandbox ça n’a… Aucun rapport avec ce qu’on souhaite exprimer 
pool = piscine
sandbox = bac a sable
pool, un ensemble d’elements en traitement – peu importe les données, donc faut se mettre d’accord sur quels sont les éléments traiter.
sandbox pour effectuer des tests, on joue dans le bac
cgeek
As-tu prévu un financement participatif pour ceux qui souhaitent rémunérer ton travail sur cette nouvelle API ?
Non, on va dire que c’est “cadeau” pour celle-là.
La v1.6 est la dernière version que je ferai gratuitement, ensuite je laisserai ma place à d’autres pour les développements de nouvelles fonctions.
Il faut savoir passer la main
En fait je compte introduire la syntaxe suivante dans la fiche de pair :
WS2P [identifiant] [hôte] [port]
Où :
identifiant est une chaîne de 8 caractères hexadécimauxhôte est une chaîne caractères (non limitée)port est un nombre (non limité)Je ne mets pas de limite de taille pour 2 des champs car quoi qu’il en soit on peut fixer une limite de taille totale par endpoint (je vais mettre 255 caractères arbitrairement, je remarque que ce n’est pas fait).
Par exemple :
WS2P f8e637ba0 duniter.org 443
Je rajoute donc un champ d’identifiant de nœud, car sinon est en cas de multiples nœuds avec la même clé publique ça devient vraiment galère de savoir quel endpoint nous appartient ou pas, et donc de savoir si on peut le retirer de la fiche ou pas.
J’avais réussi avec BMA mais c’est vraiment compliqué et implique un surcoût réseau (échanges pour savoir qui est qui, si le endpoint a toujours quelqu’un en face, etc). Donc je préfère améliorer cette situation avec un identifiant.
Bon, je ne vais malheureusement pas pouvoir développer les points suivants par manque de temps :
Je comptais faire en sorte qu’un nœud se connecte prioritairement auprès des nœuds calculant des blocs. Je vais finalement faire plus simple : se connecter en priorité aux nœuds membres.
Je ne vais pas développer la couche automatisant ce travail : on pourra quand même configurer des nœuds auxquels se connecter soi-même et configurer des nœuds invités pour lesquels on accepte systématiquement la connexion. Mais il n’y aura pas de message réseau demandant aux nœuds invités de se connecter : il faudra que les 2 administrateurs aient conclu cela de façon manuelle en dehors du réseau, et adapté leurs configurations pour que ça fonctionne.
Comme l’accès à BMA sera désactivé par défaut, les clients comme Sakia / Silkaj / Cesium ne pourront plus connaître l’état du HEAD de chaque nœud en leur demandant directement. Il faut donc un autre mécanisme indiquant l’état du réseau. Je vais réaliser ce mécanisme, mais dans une version très basique et largement optimisable.