Suite aux discussions récentes sur les approches pour les données hors chaîne, j’ai l’impression qu’il y a deux équipes qui se distinguent. L’une “idéaliste” très attachée à la logique p2p stricte (chaque acteur sur le réseau a à peu près le même rôle), l’autre “pragmatique” (ok pour une logique client/serveur du moment qu’on a une fédération).
Équipe “p2p prioritaire”
Personnes motivées par le p2p pur pour son élégance, sa résilience, ses enjeux politiques, ou autres motivations propres :
Équipe “chouette mais pas prioritaire”
Personnes motivées par le p2p, mais pas si cela vient avec une complexité supplémentaire et qui n’est pas un besoin strict pour les utilisateurs. Préfère la décentralisation par fédération.
Choisir une stratégie
@Flow nous a fait remarquer récemment quelque chose qui a toujours été vrai pour le projet : qu’on partait un peu dans tous les sens :
Je suis d’accord avec lui sur le fait que pour ce sujet en particulier, il vaudrait mieux ne pas trop disperser les efforts, ça me paraît dans l’intérêt de la communauté Ğ1 qu’on pourrait éviter de fragmenter davantage.
Et j’ai lu beaucoup d’argument de @elois en faveur d’un système “client/serveur first” plutôt que “full p2p” dans le cas de la Ǧ1 :
peu de vrai cas d’usage
nécessité d’un client loud
pas d’avantage réel
pas réaliste / pragmatique
Ma conclusion
Ma conclusion est que pour l’instant, je suis plus favorable à adopter les Dunipod, pour remplacer squid et pour leur couche de stockage hors chaîne. On se retrouvera donc avec deux endpoints seulement (duniter et dunipod) plutôt que trois (duniter, squid et cesium plus pods).
Mais je compte bien continuer ma R&D sur une solution entièrement p2p pour d’autres cas d’usage, pas forcément pour la Ğ1 qui est déjà “centralisée” sur une blockchain.
Concrètement ça veut dire :
- Mon projet “Ǧeopod” s’arrête. C’était essentiellement une expérimentation d’un client lourd basé sur des Datapods p2p, et la logique voudrait qu’on le remplace par une appli légère branchée sur Dunipod en GraphQL.
- Toutes les applis de la Ğ1 doivent migrer leur couche de données de Cesium+pods à Dunipod pour éviter la fragmentation des données.
- Je vais continuer mes expérimentation p2p sur d’autres cas d’usage, donc consacrer du temps à des choses hors Ğ1, donc passer moins de mon “temps informatique bénévole” à la Ğ1.
- Je compte quand même explorer l’intégration de Dunipod à un client lourd p2p, mais je pense que je serai bloqué par le couplage entre les données et l’index. Il n’est pour l’instant pas possible de récupérer un index sans récupérer les données.
N’hésitez pas à vous positionner dans une équipe dans le sondage suivant, et à donner votre avis ci-dessous.
En général, dans quelle équipe êtes-vous ?
- équipe “fonctionnalités” (archi client/serveur, fédération)
- équipe “p2p pur” (client lourd p2p)
- ne se positionne pas
Pour la Ǧ1, quelle est votre stratégie court terme ?
- priorité “fonctionnalités” (ok pour archi client/serveur, fédération)
- priorité “p2p pur” (client lourd p2p)
- ne se positionne pas