J’ai passé deux jours à me plonger dans IPFS et ça m’a ensuite occupé l’esprit tout le weekend.
Il m’est apparu évident qu’il fallait utiliser IPFS comme couche de stockage de données hors chaîne, ça me paraît même stupide de faire autrement.
Je m’y suis intéressé dans le cadre de
→ Étendre la toile de confiance sans consensus global
et du financement NGI, mais ça s’applique également aux datapods v2
→ Thinking about datapods v2
Attention, ça ne veut pas dire qu’on n’aurait pas de endpoint graphql “centralisé” comme elasticsearch ou
→ V2s-datapod: Hasura with Deno middleware to store profiles
mais que ce serait uniquement une couche d’indexation construite sur un stockage de données IPFS.
J’ai quand même identifié quelques points à creuser :
- comment gérer la demande d’indexation d’une nouvelle donnée → gossip libp2p / ipfs pubsub
- comment gérer l’indexation du contenu à épingler et indexer → orbitdb ou autre structure de donnée dans ipfs avec publication ipns
Je détaille :
Lors de l’émission d’une nouvelle donnée, par un téléphone, plusieurs options sont possibles :
- inscription auprès d’un “pinning service” centralisé, courant dans IPFS mais ne nous intéresse pas (centralisé)
- inscription en blockchain centralisée, également fréquent mais ne nous intéresse pas (centralisé)
- publication sur le réseau ipfs décentralisé via la fonction p2p pubsub (décentralisé)
A priori c’est vers cette dernière option qu’on aimerait se tourner. Mais cela pose une question :
“Comment un nouveau nœud ou un nœud qui était hors ligne un moment peut-il récupérer les données émises par le passé ?”
La réponse est une première couche d’indexation sur ipfs. Il faut développer un programme à brancher sur son noeud ipfs qui écoute les messages pubsub sur le réseau et les traite :
- le nouveau message (cid) est examiné
- s’il dépasse une certaine taille (par exemple > à l’espace libre sur disque dur), il l’ignore
- sinon il rapatrie le contenu et continue
- si le contenu est un message signé (ipld) il vérifie si la signature est valide et continue
- il peut ici optionnellement appliquer un filtre sur le contenu avant de continuer
- si la clé émettrice correspond à son critère de confiance, il ajoute le cid du message dans le set des messages émis par cette clé
Ce set de clés publique avec une set de messages émis par chaque clé publique constitue un index. Cet index est un objet ipfs publié via ipns. On ne recherche pas le consensus sur cet index mais tant que certains nœuds partagent des critères en commun, ils ont le même index.
Quand un nouveau nœud se connecte ou souhaite rattraper son retard après une déconnexion, il peut copier l’index de quelqu’un d’autre, et éventuellement le fusionner avec son index existant.
Cet index n’est finalement qu’une liste de cid. Chaque nœud ipfs peut appliquer ses propres critères pour épingler ou pas la donnée derrière ce cid. Par exemple, mon critère serait : j’épingle toute donnée <10 Mo de tous les membres de la Ğ1 sauf si un membre dépasse un quota de 1Go ou que ces données dépassent 100Go sur mon disque dur, ou si un cid fait partie de ma liste de blocage formulée selon mes critères et partagée sur ipfs.
D’autre part, à chaque fois que j’épingle un nouvelle donnée, je préviens mon indexeur (postgresql + hasura) pour qu’il l’indexe et la rende facilement explorable via une api graphql.
Voilà pour la théorie, mon programme de la semaine est de passer à la pratique en faisant une poc.
[edit] vidéos de poc :
