Ça m’a pris plus d’efforts que je pensais de passer ça en prod et ce n’est pas fini, mais je le mets quand même en ligne pour que vous puissiez expérimenter de votre côté.
DDD-UI pour Duniter Datapods Demo – User Interface est un client pour les datapods. Pour l’utiliser, il faut pour l’instant se rendre dans une passerelle locale (avec Brave ou kubo) et ça ne fonctionne pas sur Firefox.
⚠️ pour utilisateur averti
👉 un pair qui a les données
/dns/datapod.coinduf.eu/tcp/4001/p2p/12D3KooWFp4JsoDo5FX8CFLtyJjaWWRZ8q3gr8uT2s9To2GYzRNA
👉 CID de la version 0.1.1
ipfs://bafybeiek25le73gy7v3omn6jqsjmutcnl5wxnbb4fhdxm7c6jdv456emoe
http://bafybeiek25le73gy7v3omn6jqsjmutcnl5wxnbb4fhdxm7c6jdv456emoe.ipfs.localhost:8080/
J’ai galéré sur le sélecteur de version qui permet de chercher si une version plus à jour existe et de basculer dessus, mais ça m’a permis d’apprendre beaucoup de choses sur la couche libp2p.
Parmi les trucs les plus chiants qu’il me reste à faire, il y a obtenir un certificat wildcard pour permettre de servir des sites sur ma “subgateway”. Si quelqu’un a un tuyau pour ça, je suis intéressé.
Sinon, pour l’utiliser, aller dans /login pour se connecter puis /upload pour publier un document. Et ensuite on peut le voir en faisant la requête graphql adaptée (cf Les datapods partent en prod) à condition d’arriver à maintenir la connexion avec mon nœud parce que moi pour l’instant ça ne fonctionne que si j’ai une passerelle locale, les webtransports avec mon datapod ne durent pas assez longtemps.
Cette démo m’a permis de me rendre compte que l’architecture que j’avais pensé convient à un système vraiment pair à pair, mais qu’il n’est pas possible de faire du vrai p2p dans un navigateur standard (firefox, chrome, safari, edge…). Brave et d’autres embarquent de quoi faire du vrai p2p, donc on a deux choix :
utiliser un navigateur p2p (ça peut être une app standalone à installer aussi)
faire du “faux p2p” en utilisant le delegated routing
Dans mon app démo, je vais essayer de détecter au démarrage si on est dans un contexte où on peut faire du vrai p2p (endpoint ipfs local disponible) et sinon basculer en mode delegated routing.
L’avantage de cette technique est qu’on bénéficie d’un vrai p2p tant que possible (donc avec une bonne décentralisation de la donnée), et que si c’est impossible on se rabat sur une solution transparente pour l’utilisateur.
L’inconvénient est que ça va demander plus de travail à concevoir (deux systèmes réseau) et plus de travail à débugger (tests à réaliser dans deux contextes réseau différents).
Note : Ça devrait me prendre deux semaines de boulot pour stabiliser tout ça donc j’hésite : est-ce que je le fais dès maintenant ou est-ce que je remets à plus tard pour avancer sur Duniter, sa doc, et l’objectif “migration sans fork”. D’un côté ça me rassurerait d’avoir un système de stockage de données intégrable dans les clients le plus tôt possible, notamment pour les commentaires de transaction et le carnet d’adresse de certification, de l’autre j’ai accumulé pas mal de retard sur les MR Duniter (la !258 date d’il y a un mois) et je sens qu’on va vite avoir besoin de moi pour produire des explications sur ce qu’apporte la migration.
Moi je pense qu’au stade où on en est, il ne faut pas précipiter les choses inutilement.
Je préférerai te voir finir et boucler ces datapod IPFS, dans tout contexte, séparer suffisamment les responsabilités pour la maintenance, avec quelques tests pour l’exemple qu’on puisse les continuer, suite à quoi j’ai hâte de m’emparer de la stack. Mais tu es en plein dedans donc c’est toi le mieux placé pour finir ça, et actuellement on est encore le cul entre deux chaises.
Il faut clarifier le statut de notre swarm, notre système de whitelist, mais on va pouvoir voir ça ensemble étant donné que j’arrive ce soir
Parce que les DHT client et serveur sont isolées. Avec Boris on avait essayé un truc qui utilise un relai WebRTC/IPFS, mais il vaudrait mieux que la libp2p intègre une communication WebRTC… A vérifier quand…
En attendant, pour solutionner la chose j’envoie les credentials d’une clef à mon API serveur (1234), qui ajoute ou enlève cette “ipfs key” qui peut être utilisée pour écrire par API ipfs (5001)
De cette façon les données restent persistantes.
En plus un brassage s’effectue entre les noeuds de l’essaim ce qui en répartit l’accès (et la vitesse de propagation) aux autres passerelles http.
Reste plus qu’à y mettre des données et être nombreux si on veut rester dans ipfs public. Ou activer un private swarm.
