J’avais installé un serveur Cesium+, il y a 2 ans… La réplication inter “ElasticSearch” se faisait par échange d’une clef commune entre les noeuds. Un peu comme la swarm.key dans “ipfs”, mais sans la couche de gestion dynamique du “swarm” (essaim).
Cette approche a pour inconvénient de “centraliser” les données sans pouvoir y associer de règles d’accès personnelles. Elle laisse pour seule liberté un choix binaire entre publier des données cohérentes ou incohérentes car leur portée est publique et leur exploitation incontrôlable.
Dans ma conception du P2P, la notion de client ou de serveur n’est pas différenciée…
Dans l’approche actuelle, nous avons une couche technique qui opère un “backend” et une manne cliente qui s’y connecte… Pour moi, ce que tu nommes “P2P coté client” n’est que de la répartition de charge (load balancing)…
Il ne s’agit pas de mettre en concurrence qui ou quoi que ce soit. Il s’agit d’architecture réseau fondamentale. Un champs de ruches et un ensemble d’essaims ne sont pas la même chose.
Si on veux aller vers du vrai P2P, on ne peut pas le faire avec une logique d’apiculteur qui fabrique des ruches. Il faut équiper les abeilles de façon à ce que chacune puisse être sa propre ruche. La notion d’anoptique est cruciale.
Dans astroport, la jonction entre ipfs et scuttlebutt, permet à chaque abeille de former son propre essaim, indépendamment de toute ruche. Ainsi, l’abeille peut librement devenir l’apiculteur d’une autre et réciproquement, dans le respect de la chaîne de confiance qu’elle aura décidé.
Nota Bene
La cohérence de chaque système P2P est liée à la capacité de répliquer les données et la DHT (table de routage) correspondante. On utilise souvent le “discovery/broadcast” pour cela. Mais à une certaine échelle, cette approche sature le réseau. On active alors le mode “gossip” (bavardage) pour continuer de garantir au mieux la cohérence en tout point. Mais aucune DHT globale n’a jamais réussi à fonctionner à très grande échelle…
Le propos d’astroport est de dépasser cette limite en scindant le réseau global en de multiples “intranet”, mais dans ce cas, plus aucune ruche ne connaît toutes les abeilles et plus aucune abeille ne connaît toutes les ruches… Personnellement c’est cette solution que j’explore, dans ce cas, il vaut mieux y introduire le DU en référenciel relativiste (Galiléen)
