Dépréciation des datapods ipfs

Nodes Datapods
1

Je n’ai pas pris le temps de le faire proprement, mais je considère que l’expérimentation des datapods ipfs doit être mise en pause au vu des forces bénévoles actuellement présentes dans le projet. C’est hyper intéressant, j’ai beaucoup appris en les faisant, et je compte bien continuer plus tard, mais pas avant la migration, ce n’est pas le moment.

Donc en gros, pas la peine d’essayer de les mettre en marche avant nouvelle indication à ce sujet. Il me reste à :

  • retirer les datapods ipfs de la catégorie “nodes” du gitlab
  • retirer les datapods ipfs de duniter panel
  • retirer les datapods ipfs de la doc (Duniter | Datapods)

C’est toujours un sujet auquel je réfléchis beaucoup, mais il a encore besoin de maturer un moment avec de trouver un débouché concret utilisable facilement. Les réflexions touchent à des sujets comme :

Pour répondre précisément à la question, je veux dire :

  • ne plus en conseiller l’utilisation
  • ne plus m’engager à répondre aux questions à ce sujet

C’est issu d’un anglicisme expliqué ici :
https://fr.wikipedia.org/wiki/Obsolescence_(informatique)

Une fonctionnalité obsolète est souvent dite deprecated voire « dépréciée » par anglicisme.

5 Likes
2

Je suppose que cela à trait à ces options dans Cesium :

image
image624×220 8.09 KB

Que je comprenne bien : est-ce juste le côté IPFS qui est remis en question ici ou bien carrément les Datapods ?

Comme je suis en train de remettre à plat Cesium pour la connectivité réseau via MR !44, je me pose la question de retirer ces options des settings et de débrancher le service associé.

2 Likes
3

Je compte déprécier le service ipfs de cs2, et le remplacer par les pods cs1.
Tu veux le faire ?

@aya à prévus de lancer un pod cs1 de dev pour y brancher les apps gtest, mais pour le moment Ğecko est branché aux pods de prod Ğ1.

2 Likes
4

Non je préfère que tu le fasses j’ai eu ma dose côté réseau et je n’y connais pas grand-chose en Datapod.

Pour le coup je propose qu’on reste en nœud centralisé tel que c’est déjà fait, je comprends que ça fonctionne de toutes façons sur ce mode.

3 Likes
5

Oui c’est exactement ce que j’ai prévus, quelque chose de très simple unique endpoint côté datapod.

Prenons le temps nécessaire en R&D pour une stack IPFS sans pression.

5 Likes
6

Vu ma dispo, je ne serai pas en mesure d’amener ce prototype prometteur à l’état de système utilisable en conditions réelles. Il faut donc en effet retirer les datapods de Cesium+. Mais je reste convaincu de la stack :

  • IPLD pour la structure de la donnée (fondamental)
  • construction d’un arbre unique global
  • système de documents signés
  • propagation des messages via pubsub (optionnel mais très pratique)
  • indexation partielle sur base postgres avec graphql par dessus
  • partie bitswap de IPFS (optionnel côté client, mais bon pour la décentralisation)
  • passerelles web IPFS (optionnel si bitswap, mais pratique pour les petits clients)
  • l’API rpc publique vers un noeud IPFS pour l’upload temporaire (trouvaille intéressante)

Il faut juste revoir :

  1. la partie IPNS qui n’est pas mature en utilisant :
    • un état en blockchain pour le consensus
    • du dnslink pour la compatibilité web
  2. la partie réseau pour assurer une bonne connectivité dynamique entre les pods IPFS d’upload et les pods IPFS d’indexation
  3. la délégation IPFS avec une couche d’authentification et de quota pour l’épinglage plus sérieux de données non indexées (mais c’est secondaire)
3 Likes