Soumission via endpoint http (centralisé) et format de signature

@kimamila a émis certaines remarques à propos de ma proposition de datapods que je reformulerais ainsi :

  • même si le mode “purement décentralisé pair-à-pair” (pubsub/ipfs) est idéal, une alternative “décentralisée uniquement côté serveur” (http côté client) serait souhaitable pour permettre le développement de clients sans embarquer de nœud ipfs (par exemple pour des applis autres que javascript)
  • le format de signature standardisé que je propose dans les datapods (prefix+time+kind+cid) impose de savoir calculer un cid (“multiformats” et autres), ce qui contraint à avoir des dépendance, on pourrait accepter d’autres formats de signature comme Cesium+
  • les données “v1” devraient être importées en l’état, sans conversion au niveau du stockage, même si une conversion peut être faite a posteriori pour servir les données de manière uniformisée

Il ne me reste plus qu’à implémenter ça :joy:

Mais pour l’instant je suis reparti sur Duniter qui avait besoin d’un peu de travail. Et il faut aussi régler la migration des données v1 historiques dans Duniter-Squid.

Accepter plusieurs formats c’est obliger les clients à implémenter tous ces formats, au moins partiellement. (si le commentaire a été envoyé depuis un client qui préfère l’autre format, il faut pouvoir le décoder et le vérifier)

L’idéal serait que les seules dépendances du codec soit un hash standard et une signature standard, ainsi chaque langage pourrait avoir sa bibliothèque client datapod très légère (sans compter la partie réseau). Il y a moyen de ne pas calculer de cid et de se contenter d’un SHA2, quitte à reconstruire le cid à partir de ce hash ?

Disons que si le développeur de Cesium développe son propre format qui convient à Cesium, ça forcera les autres client qui utilisent les données de Cesium et veulent vérifier la signature ou soumettre un document à implémenter ce format.
Et si un autre développeur veut développer une autre application, comme Ğchange ou Ğecko, il aura le choix entre reprendre les formats existants pour se mettre en compatibilité ou développer son propre format pour les documents qui concernent a priori uniquement son usage jusqu’alors. Par exemple pour un format chiffré de préférences d’application (affichage des prix en DU / Ğ1 par ex).
Le cid permet d’utiliser le format de hash qu’on veut, c’est juste que le cid-v1 demande d’expliciter :

  • multihash : l’algo de hash utilisé (par défaut sha2-256 je crois)
  • multibase : la base utilisée pour encoder ce hash (par défaut base32 je crois)

Coller un cid comme bafybeifmxpb2zuqfcj64swjle24eicb4mph4humrtsr3yb23ra6iww4ksq dans https://cid.ipfs.io/ pour l’inspecter.

Mais il faut quand même savoir ce qu’on hashe, et c’est le but du champ multicodec.

Je suis favorable à l’utilisation du cid avec multiformats, mais pas contre gérer les formats legacy comme celui de Cesium+.

Ma proposition est que l’App puisse publier ses données via une mutation GraphQL du datapod.
Cela ne dit rien que le choix du(des) datapod(s) à qui on envoit les données. Cette solution peut donc être aussi considérée comme “totalement décentralisée”. C’est juste de moyen de sélection des pairs qui change : libp2p, scan réseau maison, etc. plutot que forcément via noeud local ipfs (qui lui aussi va faire une sorte de scan réseau).

Je n’ai rien demandé de ce côté. Tu as du mal comprendre.
Cela ne me pose pas de problème d’utiliser ces librairies (cid, dag-cbor, etc) pour les nouveaux documents.
Je constatait juste qu’il fallait que j’importe ces lib. Mais elle sont légères, et surtout n’impacte pas les performances (contrairement à avoir un noeud IPFS local, sur un smartphone)

L’avantage ici est :

  • de pouvoir continuer de mettre à jour les profiles v1 dans IPFS (pour les utilisateurs qui feraient la bascule avec un délai, en continuant un temps d’utiliser G1v1 par exemple)
  • d’avoir des documents non modifiés, intègres et vérifiables sans tiers de confiance.
  • de suivre le proicessus de migration : en effet, les App V2 pourrait gérer la migration automatiquement vers le nouveau format. On saurait ainsi combien d’utilisateurs (avec profiles) ont basculés en G1v2

L’inconvénient est :

  • plus lourd en stoackage, notamment du fait de l’image (avatar) en base64. Mais bon, on parle d’image de quelques pixels…
1 Like

La encore, je ne crois pas avoir demandé cela.
Je n’ai pas besoin d’un cid maison. Le cid est la référence IPFS d’un fichier (profile, etc.). Ma demande est juste de laisser le fichier profile intact, plutot que de le reconstruire depuis un tiers de confiance qui va le resoumette à IPFS tout modifié, donc potentiellement tronqué et/ou falsifié.