Clients v2 et Datapods v2

Merci encore de me forcer à expliquer ces points tôt, je pensais le faire dans une documentation plus tard, mais mieux vaut le faire dès maintenant !!


La solution la plus décentralisée pour la soumission de données aux datapods v2 est détaillée dans le projet “ddd-ui” (pour Duniter Datapods Demo User Interface) ici : /src/views/UploadView.vue#L69-L108. Cela consiste en :

  • ouvrir une connexion libp2p avec les nœuds du réseau Duniter Datapods
  • publier les dépendances de la donnée (par exemple image) sur un noeud IPFS local (ici Helia)
  • publier la donnée (par exemple profil Cesium+) sur le noeud IPFS local
  • publier la demande d’indexation (IndexRequest) signée sur le noeud IPFS local
  • publier le CID de la demande d’indexation signée sur un canal pubsub dédié (TOPIC ‘ddd’ en l’occurence)

Mais cela implique qu’il ne faut pas immédiatement fermer l’application après avoir envoyé le message sur pubsub sinon la donnée ne pourra pas être récupérée. Il faut que je fasse des tests en conditions réelle (smartphone sur réseau 3G) mais je m’attends à ce que ça prenne moins de cinq secondes même dans de mauvaises conditions tant que le donnée est légère.

Il y a aussi une autre option plus centralisée : créer des passerelles qui permettent de tout soumettre d’un coup de manière plus classique (HTTP) et qui s’occupent de partager les documents sur IPFS et l’annonce sur pubsub. Pour l’instant je n’ai pas développé ça parce que je voulais d’abord m’assurer de la nécessité. Mais ça permettrait de retomber sur des bases bien connues (http plutôt que libp2p).

1 Like

Je ne comprends pas trop. Sur un smartphone, l’usage d’un noeud IPFS local me partait difficile à imposer. Cela doit rester une option.

On peut en effet, comme pour le Pod Cs+, faire confiance à un fournisseur de service tier, comme un datapod. D’ailleurs les datapod pourrait publier leur identité dans la WoT (comme les fiches de pair des Pod Cs+).
De toute manière le datapod n’a pas moyen de tricher, dès lors que la signature de IndexRequest est faite par l’app cliente.
La seule “triche” qu’il pourrait réaliser, c’est de ne pas soumettre (à IPFS et/ou au topic PubSub), mais alors cela se verrait vite, et les utilisateurs diraient “ca ne marche pas sur ce datapod là, essaie avec celui-là”. Non ?

Par ailleurs l’app client peut très bien conserver en mémoire les documents envoyé, pour les resoumettre plus tard s’il n’ont pas été recu dans les autre datapod. Ca me parait plus simple…