Réflexion sur les datapods décentralisés

HugoTrentesaux · 29 February 2024 15:07

J’ai passé un peu de temps à relire la doc de IPFS, Filecoin, et à réfléchir à la question. Je ne veux pas me lancer dans la conception et encore moins l’implémentation d’un système de stockage de données hors chaîne pour l’instant, mais je ne veux pas non plus me lancer dans une solution centralisée (V2s-datapod: Hasura with Deno middleware to store profiles) sans avoir pris le temps de prendre un peu de recul sur le sujet.

Il est évident que le DU et la toile de confiance nécessitent un consensus et méritent une blockchain, et Duniter v2 répond très bien à ce problème. Par contre, pour ce qui est des commentaires de transactions, des informations de profil, des annonces de vente, des messageries… Tout ça ne peut pas faire consensus pour différentes raisons :

on peut ne pas tolérer sur sa machine d’héberger du contenu indésirable (malwares, trafic d’armes, trafic d’humains…) ni l’imposer à des gens qui ne souhaiteraient pas être dans l’illégalité
on ne souhaite pas conditionner le stockage de données aux seules comptes connus et validés par des membres de la toile de confiance, c’est trop restrictif
il est sain de permettre les désaccords sur les données, même si elles viennent de membres de la toile

On doit donc avoir un système sans consensus et qui permette le fork, tout en garantissant quand même un bon niveau d’utilisabilité. L’approche des datapods Cesium+ est intéressante, mais comme on le voit sur https://ginspecte.mithril.re/, il existe une différence importante entre le nombre de documents présents sur chacune des instances, sans qu’on ait de bonne explication de pourquoi :

Il peut s’agir de problématiques de synchronisation réseau ou de modération par les responsables de l’instance non reconnues par les autres responsables d’instance.

Je distingue plusieurs étapes :

l’acceptation (ou non) de la soumission d’une nouvelle donnée
l’acceptation (ou non) de l’indexation d’une nouvelle donnée
l’acceptation (ou non) du stockage d’une nouvelle donnée
le référencement (ou non) d’une donnée
le re/dé-référencement d’une donnée
le re/dé-stockage d’une donnée
la re/désindexation d’une donnée

Pour moi un protocole complet devrait répondre clairement à toutes ces étapes (et en plus à d’autres critères réseau) sans laisser de zones d’ombre, et fournir des mécanismes d’accord/accord partiel/désaccord entre des participants du réseau à toutes ces étapes.

Par la suite, je vais donner des exemples possibles de règles qui devraient être composables à l’envie par les participants du réseau.

acceptation d’une soumission (essentiellement un rôle d’antispam)
- signature par une clé répondant à un critère interne
  - clé présente dans une whitelist faisant partie des données
  - contre-signature par un membre du réseau de confiance (par pour déléguer une des règles ci-dessous à un autre nœud du réseau)
- signature par une clé répondant à un critère externe
  - clé associée à un compte Ğ1 ayant au moins x unités au moment de la soumission
  - clé associée à un compte membre Ǧ1
  - clé signée par un autre réseau de confiance (toile PGP, BrightId, UCAN)
  - clé signée par un tiers de confiance (numéro de téléphone, service d’identité national…)
acceptation de l’indexation (reconnaître l’existence de la donnée, éventuel rôle politique, ou simplement limitation communautaire ou technique)
- clé absente d’une blacklist (par exemple un numéro de téléphone validé, mais connu pour du spam)
- clé présente dans une whitelist communautaire (par exemple si on souhaite isoler une communauté)
- clé présente dans une whitelist nécessaire pour répondre à des limitations techniques (par exemple pour produire un micro-index sur une machine avec peu de stockage)
acceptation du stockage (rôle à la fois politique et technique pour garantir l’accès à la donnée)
- clé absente d’une blacklist (par exemple pour du contenu indésirable qu’on ne souhaite pas stocker)
- volume de la donnée trop élevé (quand la ressource en stockage est trop limitée)
- clé présente dans une whitelist d’intérêt (on peut tout à fait reconnaître l’existence de la donnée dans un index mais ne pas être intéressé par en stocker une copie)
- clé répondant à un critère externe (par exemple avoir payé pour le stockage de la donnée)
référencement (rôle de rendre accessible la donnée sur une interface donnée)
- whitelist/blacklist (on peut souhaiter stocker une donnée mais ne pas la rendre disponible sur un interface pour tout un tas de raisons)
re/déréférencement
- on doit pouvoir changer l’état de référencement sur des critères arbitraires
re/dé-stockage
- on doit pouvoir changer l’état de stockage d’une donnée sur un critère arbitraire
re/désindexation
- l’indexation ou la non-indexation ne doit pas être définitive, on doit pouvoir revenir dessus a posteriori par exemple suite à la modification d’une whitelist / blacklist / critère externe

Voilà donc la direction dans laquelle je voudrais aller mais qui me paraît totalement inatteignable aujourd’hui. Pour moi IPFS répond trop partiellement à la question du pinning et pas assez à la question des pointeurs avec IPLD. Filecoin répond à la question de la méfiance avec le preuves, mais n’est pas très intéressant dans un contexte de confiance.

Comme on veut sortir la v2 dans un temps raisonnable et avec commentaires de transaction et informations de profil, je suis prêt à assumer une infrastructure centralisée. Mais par exemple cela voudra dire que les admins de l’instance auront le dernier mot sur la gestion des données. Par exemple on pourra décider de supprimer des commentaires de transaction s’ils sont utilisés pour faire du harcèlement. Je pense qu’on retombera plus vite que certains ne le pensent dans des problématiques similaires à celles du forum monnaie libre dont sont exclus matiou et mlet. Mais tant qu’on n’a pas de bonne réponse à cette question ça me paraît le moindre mal et mieux que rien (ce qui n’est pas évident, certains préféreraient qu’il n’y ait rien).

Quelques liens pour la route :

ness · 29 February 2024 15:34

avec le droit de rectification autant miser sur un accès direct voire chiffré tel les messageries vis à vis des serveurs, la clef privée modifie son contenu de façon intègre et transparente. la modération se fait si besoin par rapport au nombre de signalement avec un certain ratio envers les auteurs membres et non membre de façon plus stricte. les hébergeurs son neutre ici

ps/ par contre ipfs n’ est pas chiffré en natif

tuxmain · 29 February 2024 21:21

Peut-être que les protocoles les plus courants sont conçus pour être très résistants aux problèmes de Byzantins. Cependant on n’a pas besoin d’une telle sécurité : on a un ensemble connu d’identités vérifiées et à enjeu (sanctions sociales possibles en cas de triche démontrable publiquement voire localement dans la WoT).

Plutôt que du côté des IPFS et compagnie, on pourrait chercher parmi les protocoles supposant beaucoup de confiance entre les nœuds, par exemple pour la réplication des données entre serveurs d’une même entreprise.

Ou implémenter l’idée d’Élois qui ressemblait à du BitTorrent profitant des spécificités de la blockchain.

Oui pour partir sur du centralisé ou du Cesium+ pendant qu’une meilleure solution est développée.

De toute façon il faudra décider d’un format pour les données, IPFS n’étant qu’un support. Ce format pourra intégrer le chiffrement quel que soit le support. On avait déjà imaginé un protocole pour chiffrer les commentaires.

Rien n’y oblige. En tant qu’hébergeur j’ai un droit de regard voire un devoir moral qui dans certains cas est même une ligne éditoriale. La modération ne peut prétendre être neutre, elle est forcément influencée par l’idéologie du modérateur. (l’absence de modération ou la modération algorithmique aussi)

ness · 29 February 2024 22:00

hébergeurs ici dans mon propos seulement * ce sont les utilisateurs qui modèrent par signalement

ex: au bout de dix signalements par des membres certifiés, le contenu est radié sans que l’ hébergeur ne voit rien dans le chiffrement, tel des transactions bc

Tchois · 8 March 2024 17:58

Sur les pod Césium+, les profils sont uniquement modifiable et effaçable par le détenteur du compte et simplement effaçable par les instances (si je ne me trompe pas).

J’ai eu plusieurs fois le cas de gens ayant créé un compte avec un profil, ont perdu leurs identifiants, puis créé un second compte très ressemblant (niveau profil).
Du coup des erreurs de virements arrive sur le premier compte, quand la clé n’est pas vérifié.

Est-il possible d’envisager une suppression de profil si un compte portefeuille n’a eu aucune activité (virement émis, connexion, notification vu…) pendant x temps (par ex. 1an), ou pour un compte membre lors de sa révocation automatique ou manuel.
Dans tous les cas si ce compte est conservé, que cette absence est dû à un voyage sur Mars par exemple , il est toujours possible de remettre le profil.

On a eu aussi le cas de comptes comportant des images porno, si c’est un “pouvoir” décentralisé, comment effacer ces profils, puisque là ce sera au jugé de chacun.

Non mais par exemple un compte membre pourrait se voir distingué par une sorte de badge rassurant visible sur gchange ou autre.
Pour quelqu’un n’étant pas encore membre, un membre pourrait lui apporter une étoile de confiance (j’écris étoile pour différencier de badge) signifiant qui il connait dans la toile de confiance en attendant d’y rentrer lui-même.
Par exemple sur un gmarché j’aide à créer une dizaine de compte, je valide (sorte de certif informel via Césium+) depuis mon compte membre que j’ai rencontré ces personnes, ça pourrait même être une reconnaissance temporaire (style 6 mois)

Là je pense que je vous rajoute du boulot, désolé…

tuxmain · 8 March 2024 19:13

Pour le problème du spam on pourrait déjà demander de réserver un montant proportionnel au stockage utilisé, à moins d’être membre ou d’avoir un tel badge/étoile.

Il faut que chaque instance ait plusieurs admins (soit des admins dédiés à l’instance, soit une répercussion automatique des décisions des admins d’autres instances). Les clients pourraient n’accepter les données que d’instances ayant assez d’admins respectant certaines règles (membre de la TdC par exemple).

Il faut aussi des signalements par les internautes comme sur Cesium. Si les signalements sont comptabilisés publiquement, les clients pourraient choisir de cacher (ou mettre sous un avertissement) les contenus signalés par trop de membres, même en l’absence d’action par un admin.