# Dépréciation des datapods ipfs
**URL:** https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383
**Category:** Datapods
**Created:** [4 October 2025 16:21 UTC](https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383 "2025-10-04T16:21:23Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 October 2025 16:21 UTC](https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383/1 "2025-10-04T16:21:23Z")
> [@Je ne suis plus à plein temps! (2025)](https://forum.duniter.org/t/je-ne-suis-plus-a-plein-temps-2025/12756/21):
>
> déprécier les datapods ipfs
> [@Je ne suis plus à plein temps! (2025)](https://forum.duniter.org/t/je-ne-suis-plus-a-plein-temps-2025/12756/22):
>
> RQ : que veut dire “_déprécier ipfs_” dans ton vocable ?
>
> dans ta review, est-ce qu’il y a le registre : “anticiper” sur la migration vers une architecture ipfs, que tu avais explorée ? Est-ce que tu avais documenté pour une reprise ou transmission sur un nouveau dev la préparation de ce terrain ? et le chantier est-il soumis à des inconnues ou incertitudes non encore résolues, ou est-ce “seulement” une question de mobilisation concentrée de 1 ou 2 dev sur un trimestre dans cette stack dense ?
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](https://duniter.org/wiki/duniter-v2/datapod/))
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 :
- [Notifications : construire un standard interopérable pour l'ensemble de l'écosystème Ǧ1](https://forum.duniter.org/t/notifications-construire-un-standard-interoperable-pour-lensemble-de-lecosysteme-1/13082)
- [Gchange v2: modération ou/et fédération?](https://forum.duniter.org/t/gchange-v2-moderation-ou-et-federation/12910)
- [Messagerie sécurisée externe](https://forum.duniter.org/t/messagerie-securisee-externe/12768)
- [Réflexion sur les datapods décentralisés](https://forum.duniter.org/t/reflexion-sur-les-datapods-decentralises/12030)
> [@Je ne suis plus à plein temps! (2025)](https://forum.duniter.org/t/je-ne-suis-plus-a-plein-temps-2025/12756/22):
>
> que veut dire “_déprécier ipfs_” dans ton vocable ?
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)](https://fr.wikipedia.org/wiki/Obsolescence_(informatique))
> Une fonctionnalité obsolète est souvent dite _deprecated_ voire « dépréciée » par [anglicisme](https://fr.wikipedia.org/wiki/Anglicisme).
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [16 November 2025 15:39 UTC](https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383/2 "2025-11-16T15:39:09Z")
> [@HugoTrentesaux](#):
>
> 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
Je suppose que cela à trait à ces options dans Cesium :
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](https://git.duniter.org/clients/cesium-grp/cesium2s/-/merge_requests/44), je me pose la question de retirer ces options des settings et de débrancher le service associé.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [16 November 2025 18:41 UTC](https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383/3 "2025-11-16T18:41:29Z")
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.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [16 November 2025 19:46 UTC](https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383/4 "2025-11-16T19:46:40Z")
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.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [16 November 2025 20:07 UTC](https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383/5 "2025-11-16T20:07:20Z")
> [@cgeek](#):
>
> Pour le coup je propose qu’on reste en nœud centralisé tel que c’est déjà fait
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.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [21 November 2025 11:03 UTC](https://forum.duniter.org/t/depreciation-des-datapods-ipfs/13383/6 "2025-11-21T11:03:03Z")
> [@cgeek](#):
>
> Que je comprenne bien : est-ce juste le côté IPFS qui est remis en question ici ou bien carrément les Datapods ?
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)