Proposition d'un système de stockage libre intégré à la blockchain pour toutes les données des utilisateurs

[tuxmain]

Un système où le seul consensus existant est global peut restreindre les groupes minoritaires ignorés ou rejetés par la majorité, par exemple les communautés queer (voir les instances Mastodon se définissant comme des « safe places »).

Donc il faudrait que le consensus global n’empêche pas ces groupes de se former (ce qui augmenterait aussi l’inertie du consensus global, car il pourrait changer du fait de la croissance d’une minorité devenant majoritaire.

Comme de toute façon on ne pourra pas empêcher les vendeurs d’armes et autres fripons de créer leurs vitrines, il me semble que le problème est « comment ne pas subir ni promouvoir leurs activités avec l’infrastructure commune ». Le modèle fédératif répond directement à ce problème.

Pour résoudre ce problème avec un consensus global, la DHT pourrait rester neutre mais les hébergeurs pourraient refuser d’héberger tel contenu. (mais ce n’est pas forcément possible, surtout si l’idée était de répartir les données selon un critère déterministe)

Après on aura toujours besoin d’indexeurs (recherche full-text de profils, d’annonces…), et la modération pourra se faire à ce niveau-là, de la même manière qu’avec Cesium+.

[HugoTrentesaux]

Par rapport à la modération, elle pourrait elle-même passer par ce système de stockage : en publiant une blacklist de données à censurer, une blacklist d’auteurs… Les wallets/clients pourraient intégrer certaines blacklist par défaut, et les admins de pods de données pourraient décider de supprimer certaines données quand les blacklist ne répondent pas au problème.

[kimamila]

@elois

Je ne suis pas d’accord avec le terme « centralisé » ici, ça reviendrait à dire que l’ensemble des règles du protocole sont centralisés, elles sont communes, pas centralisées…

Il me faut éclaircir ce point, avant de répondre sur la suite.

Dans le système que tu proposes, y a t’il des règles non automatisables ? Une charte, etc.
Si oui, c’est bien qu’elles sont (ces règles) arbitrées par des humains, où une groupe d’humains (les modos) ? Ce groupe d’humains, représente t’il ou non une autorité, ayant privilège, ou pas ?

@elois

On peut écrire de là même façon « Un groupe d’individus motivés pour fonctionner avec d’autres règles que celle de la Ğ1 ne pourra pas utiliser la Ğ1. ».

Si on pose mes questions précédentes à la G1, on s’apercoit que ce n’est pas comparable, car il n’y pas de règles à arbitrage humains, pour faire fonctionner la G1. Tout y est automatisé. Car le contenu n’impose pas de modération fine (ou subtile).
Les règles s’appliquent à tout le contenu de la G1, sans distinction de privilège supplémentaire accordé à une groupe d’humains.

@elois

La modération devrait se limiter aux contenus illégaux et consensuellement graves (menaces de morts, discours haineux, etc).

dans un système décentralisé, qu’est ce qui est “légal” ou pas ?
Les règles d’un pays s’appliquent elle dans un autre ?

[vincentux]

@elois

Les utilisateurs ont des données: nom, commentaire de transactions, profil, messages privées, annonces, commentaires d’annonces, etc

L’architecture actuelle stocke une partie en blockhain, une partie sur des pod Cs+, une autre encore sur des pod gchange, etc

En fait depuis le début je pensais que nous allions stocké uniquement les profils et éventuellement les messages privés.

Pour moi les infos de la, ou des boutiques non pas à être stockées en blockchain…
Les boutiques ne devraient-elles pas être indépendantes de la monnaie ?

[elois]

@kimamila

y a t’il des règles non automatisables ? Une charte, etc.
Si oui, c’est bien qu’elles sont (ces règles) arbitrées par des humains, où une groupe d’humains (les modos) ? Ce groupe d’humains, représente t’il ou non une autorité, ayant privilège, ou pas ?

Quel part on veut automatiser et jusqu’où c’est à définir ensemble, ce n’est pas à moi d’en décider.

Il y a forcément des parties gérées par des humains, mais ce “groupe d’humains” comme tu dis ça peut être l’ensemble des membres de la toile de confiance Ğ1.

Alors que dans un modèle fédératif le groupe d’humains est plus restreins, donc le pouvoir davantage centralisé.
Et la possibilité de pouvoir créer sa propre instance est une vaste blague, si 90% des gens sont sur quelques instances, dans la pratique on à besoin d’être là ou sont les gens.

@kimamila

on s’aperçoit que ce n’est pas comparable, car il n’y pas de règles à arbitrage humains, pour faire fonctionner la G1. Tout y est automatisé.

C’est au contraire parfaitement comparable. Ce qui est automatisé a été décidé et convenu par des humains.

@kimamila

Les règles s’appliquent à tout le contenu de la G1, sans distinction de privilège supplémentaire accordé à une groupe d’humains.

C’est faux, les règles définissent certains privilèges, comme le fait d’être membre de la toile de confiance et d’avoir donc le privilège de créer sun DU, u membre de la sous-toile forgeron et d’avoir donc le privilège de pouvoir créer des blocs, et voter pour ou contre les changements de protocoles.

Le fait que nous avons déjà un système composé d’humains et de règles, donc une gouvernance, elle est juste implicite jusque la, et je pense qu’on a justement tout à gagner à l’expliciter cette gouvernance

@kimamila

qu’est ce qui est « légal » ou pas ?
Les règles d’un pays s’appliquent elle dans un autre ?

Bonne réponse, de toute façon les arguments de @tuxmain m’ont convaincu, je vais partir sur un système à plusieurs groupes, ou chaque groupe pourra définir ses propres règles de modération

@vincentux

je pensais que nous allions stocker uniquement les profils et éventuellement les messages privés.

Le but est de concevoir un système pouvant stocker tout type de donnée, après chaque service restera libre d’utiliser ou ne pas utiliser ce système pour stocker tout ou partie des données de ses utilisateurs.

@vincentux

Les boutiques ne devraient-elles pas être indépendantes de la monnaie ?

Elles le seront. certaines boutiques trouveront un intérêt à stocker tout ou partie des données de leurs utilisateurs dans ce système, notamment si elle garantit à leurs utilisateurs la souveraineté sur leurs données (la capacité a les modifiées/supprimées sans avoir besoin de l’accord du prestataire de service).

Après je ne comprends par ce que tu entends par “dépendant ou indépendant de la monnaie”.
Toute boutique dépend des monnaies qu’elle accepte, si tu ne veux pas dépendre d’une monnaie il vaut mieux ne pas posséder cette monnaie, donc ne pas l’accepter dans ta boutique

[elois]

@tuxmain

Pour résoudre ce problème avec un consensus global, la DHT pourrait rester neutre mais les hébergeurs pourraient refuser d’héberger tel contenu. (mais ce n’est pas forcément possible, surtout si l’idée était de répartir les données selon un critère déterministe)

Après on aura toujours besoin d’indexeurs (recherche full-text de profils, d’annonces…), et la modération pourra se faire à ce niveau-là

En effet, une possibilité est de ne pas avoir de modération en blockchain, et d’avoir juste un système de frais/quotas pour se protéger du spam.

Déplacer la modération au niveau des indexeurs me semble être une très bonne idée, car dans la pratique ce qui nous dérange avec les annonces néfastes c’est le fait qu’elles apparaissent dans nos résultats de recherche.
Si la donnée existe mais qu’elle n’est pas trouvable sans avoir le lien direct, bah on s’en fout car personne ne va tomber dessus par recherche.

Ça permet de garder une seule grande DHT et donc de garder une mutualisation des efforts pour le stockage des données et des preuves de merkle.

Donc, si le système que je propose n’inclus aucune modération en blockchain, et laisse ça au indexeurs. Alors une minorité qui souhaite des règles de modération différentes peut avoir ses propres indexeurs, qui n’appliqueront pas les mêmes filtres

À noter qu’il faut quand même se mettre d’accord collectivement sur certaines choses: notamment les frais/quota et la rémunération des participants à la DHT, ainsi que les règles d’élagages des anciennes données.

S’il n’y a pas de modération globale, il faut trouver un autre moyen de ce prémunir contre l’accumulation de vielles données qui ne servent plus (puisque aucun modérateur ne peut les supprimer). Il y a plusieurs possibilités pour ça, notamment via les modalités des frais, un exemple de ce qu’on peut faire facilement:

Définir un loyer à payer régulièrement en fonction de la quantité de données qui nous appartiennent, ça donne un incentive à faire le manage dans ces données, en supprimant celles qui ne servent plus pour réduire le montant de son loyer.
Ça permet aussi de supprimer “automatiquement” les données d’un utilisateur qui a quitté la Ğ1 (ne serait ce que par décès), lorsque son solde restant ne permet plus de payer le loyer, ces données sont supprimées.

[HugoTrentesaux]

J’aime bien l’idée du loyer pour le stockage de données. Et par rapport à la modération, il faut un préavis du genre « je vais supprimer cette donnée » pour éviter de déclencher le mécanisme de « ce nœud a dit qu’il stockerait cette donnée mais il ne la fournit pas donc sa réputation baisse ». C’est différent de ne pas avoir une donnée parce qu’on a voulu nuire et ne ne pas avoir une donnée parce qu’on a voulu protéger…

Et en tant qu’admin d’un nœud de données, j’aimerais pouvoir dire :

• whitelist : je stocke les données de ces clés gratuitement (sans loyer)
• blocklist : je refuse de stocker les données émanent de ces clés
• blacklist : je refuse de stocker les données correspondant à ces hash

Mais bon, c’est un sujet très compliqué de gouvernance humaine des données, ça mérite qu’on en parle en personne parce qu’à l’écrit ça me semble laborieux.

[elois]

@HugoTrentesaux

Et par rapport à la modération, il faut un préavis du genre « je vais supprimer cette donnée » pour éviter de déclencher le mécanisme de « ce nœud a dit qu’il stockerait cette donnée mais il ne la fournit pas donc sa réputation baisse »

Attention il faut distinguer les data-pod des indexeurs.

Les data-pod ne décideront pas quoi que ce soit, ils seront agnostiques de la nature des données, les data-pad sont les hébergeurs de la DHT, donc ils stockeront tout ce qu’ils doivent stocker sans avoir à choisir quoi que ce soit, et seront rémunérés pour ça.

Mais un data-pod ne fournira pas de résultat de recherche, il te donnera juste une valeur associée à une clé, et sa preuve de merkle.

Les indexeurs ne vont pas stocker les données, mais seulement des métadonnées. Par exemple quand je cherche une annonce, un indexeur va me fournir les résultats, incluant pour chaque annonce, titre, catégorie, auteur, et autres métadonnées + la clé de l’annonce. Et si l’utilisateur clique sur une annonce, alors là on demande son contenu à un data-pod, ce qu’on peut faire, car on a maintenant la clé.

Dans la pratique les 2 requêtes pourront être via la même API avec serveur Hasura graphQL en proxy qui fusionne deux schémas GraphQL.

Mais du coup il n’y a rien à annoncer avant de supprimer une donnée, puisse la donnée ne sera pas supprimée mais juste déréférencée par les indexeurs qui auront choisi de la déréférencer.

Or je ne propose pas de système de réputation pour les indexeurs, seulement pour les data-pod, du moins au niveau de la blockchain.

Les data-pod auront tous le même logiciel, et feront tous la même chose, donc on peut attendre les mêmes exigences de chacun d’eux, et les rémunérés pareil. La réputation d’un data-pod n’est nécessaire que parce qu’ils sont rémunérés.

En revanche les indexeurs seront beaucoup plus diversifiés selon les besoins et les différents cas métiers, et n’indexeront que certains types de données selon le service qu’ils souhaitent rendre, donc ça me semble trop complexe voir impossible de gérer leur rémunération/réputation en blockchain.

@HugoTrentesaux

j’aimerais pouvoir dire :

• whitelist : je stocke les données de ces clés gratuitement (sans loyer)

Ça ce ne sera pas possible, car ça impliquerait d’avoir plusieurs DHT différentes. En tant que membre de la DHT, tu dois stocker toutes les valeurs de ta plage de clés, car ta plage de clés est calculée en fonction d’un taux de réplication minimal pour éviter les pertes de données.

Les exonérations de loyer devront être définies collectivement, par exemple un quota gratuit pour les membres certifiées.

[HugoTrentesaux]

J’aime bien cette réponse même si j’ai encore un peu de mal avec le concept de « je prête mon disque dur à tout le monde, peu importe ce qu’ils écrivent dessus ». Ça me gaverait que 50% des données stockées soit pour des trucs que je désapprouve (armes, porn, harcèlement, discrimination…) et que je fasse confiance à des indexeurs pour cacher ça aux utilisateurs sachant qu’il peut très bien y avoir d’autres indexeurs qui sont justement spécialisés dans ce genre de données.

(ceci dit je pourrais toujours blacklister les indexeurs qui ne respectent pas mes règles et interdire les connexions entrantes de leur part)

[kimamila]

Ta dernière proposition Éloïse me paraît mieux : décaler la modération a un niveau au dessus de la BC.

En revanche je penses qu’il faut se concentrer sur le minimum vitale : profils et éventuellement contenu chiffré (type message) mais pas plus. L’avantage de ces deux types de donnes étant qu’il n’exige pas de modération importante.
Delors que du contenu explicite pourra être stocké, la modération sera automatiquement compliquée.

Sur le reste de tes réponses à mes posts, je ne réagit pas. Pas le temps ce soir car décidément on ne se comprend pas bien, même dans des exemples simples…

[elois]

@kimamila

décidément on ne se comprend pas bien, même dans des exemples simples

Oui c’est très frustrant pour moi (et pour toi aussi j’imagine).

J’ai vraiment l’impression que tu me réponds sans me lire, ou vraiment trop en diagonale, vu à quel point tu réponds souvent à côté et me fait dire des choses que je n’ai jamais dites

J’essaye pourtant de m’exprimer le plus clairement et simplement possible, mais il semble que nous ayons des manières de structurer notre pensée trop différente pour pouvoir se comprendre à l’écrit

Je t’assure que je fais de mon mieux pour essayer de rester polie, mais des fois c’est trop difficile, car pour moi c’est un profond manque de respect que de critiquer une proposition technique sans prendre le temps de bien la lire entièrement et attentivement, alors que l’autre à passé du temps à rédiger un post d’explications détaillé.

[poka]

@elois

car pour moi c’est un profond manque de respect que de critiquer une proposition technique sans prendre le temps de bien la lire entièrement et attentivement, alors que l’autre à passé du temps à rédiger un post d’explications détaillé.

Il y avait surtout un désaccord sur le modération, généré de manière global ou non. Ce que vous proposiez était différent là dessus, et je suis d’accords avec Benoît sur certains points.

Votre dernière proposition avec tuxmain me semble un excellent compromis.
Un stockage unique sur des data-pod (Intégré en module de duniter ou indépendant) avec éventuellement une modération global restreinte aux mainteneurs de noeuds, pour intervenir uniquement en cas de problème, et des indexer variés avec leurs propres règles de modération.

Ca me semble être une bonne architecture.

[vincentux]

@elois

Le but est de concevoir un système pouvant stocker tout type de donnée, après chaque service restera libre d’utiliser ou ne pas utiliser ce système pour stocker tout ou partie des données de ses utilisateurs.

@elois

certaines boutiques trouveront un intérêt à stocker tout ou partie des données de leurs utilisateurs dans ce système

Gérer et stocker des profils utilisateurs (une sorte d’annuaire amélioré), oui, mais je ne voie toujours pas pourquoi Duniter (via ses data-pod) s’occuperait des annonces (et donc de la modération) des biens et services.

@kimamila

En revanche je penses qu’il faut se concentrer sur le minimum vitale : profils et éventuellement contenu chiffré (type message) mais pas plus. L’avantage de ces deux types de donnes étant qu’il n’exige pas de modération importante.

Voilà, je suis aussi de cet avis…

[elois]

@poka

Il y avait surtout un désaccord sur le modération, généré de manière global ou non.

Sur la fin oui, mais après plusieurs longs allés-retour ou j’ai du reformulé/répété ce que j’avais déjà expliqué dans mon 1er post pour que Benoît comprenne enfin de quoi il était question… Et ça c’est fatiguant.

@poka

Un stockage unique sur des data-pod (Intégré en module de duniter ou indépendant) avec éventuellement une modération global restreinte aux mainteneurs de nœuds, pour intervenir uniquement en cas de problème, et des indexer variés avec leurs propres règles de modération.

Oui je pense partir la dessus, mais en micro-service, donc le data-pod sera un programme binaire indépendant, il aura tout de même besoin d’un nœud duniter-v2 sur le même réseau local pour taper des méthodes RPC privées, donc dans la pratique ce sera “comme si” c’était un module.

@vincentux

mais je ne voie toujours pas pourquoi Duniter (via ses data-pod) s’occuperait des annonces (et donc de la modération) des biens et services.

Ils ne s’occuperaient pas de la modération, ce serait les indexeurs.
Et “duniter” en lui-même ne s’occupera pas des données, les data-pod seront un programme tier, duniter s’occupera uniquement du maintien du merkle root er blockchain, et de la vérification des delta (qui ne sont que des hashs).

Et je trouverai dommage de se limiter à peu de types de données, et de ne pas faire profiter aux annonces les apports de ce système , notamment le côté trustless, la résilience d’une DHT globale, et la gestion automatique des frais (qui me semble indispensable pour scaler).

Je pense aussi qu’on devrait profiter davantage de notre toile de confiance et avoir une intégration forte de celle-ci dans une place de marché Ğ1, les annonces émises par des comptes-membres pouvant être signalés dans l’UX et réputées plus fiables. Ce qui nécessite bien une “interaction” avec la blockchain du toute façon.

Je comprends ce minimalisme de la blockchain, hérité des affres de duniter-v1, mais maintenant qu’on a enfin une blockchain avec une bien meilleure architecture, on peut gérer bien plus de choses dessus, et notamment gérer un consensus sur l’état des données, c’est quand même l’objectif premier d’une blockchain.

Mon but est de créer un système générique qui permettre d’apporter un consensus global et une prouvabililté totale sur tout type de données, je ne souhaite pas restreindre ce système à certains types de données.

Et l’effort de modération reste le même que vous utilisiez ce système ou pas, dans les 2 cas il faut développer un système de modération efficace, autant le développer générique pour qu’il puisse modérer tout type de données.
Appliquer les choix d’une modération reviens à appliquer un basique filtre, il suffit de stoker les préfixes des clés filtrées, et comme toute clé commence par son propriétaire, ça permet également de ban des utilisateurs.

[cgeek]

Super solution, j’ai lu ton 1er post (v7), ça me semble déjà bien propre.

Du coup ce système utiliserait un child trie ? Et stockerait des hash de façon à optimiser le stockage je suppose.

Le seul point qui reste à creuser c’est la rémunération des indexeurs, car s’il y a un travail humain ou même semi-automatisé de modération de contenu (par désindexation) c’est là que se situe le plus gros du « boulot » (par opposition au travail des data-pods) il me semble.

Concernant les commentaires de transactions (le sujet a été évoqué dans la réunion mensuelle du 15/05 notamment pour permettre d’insérer des références externes) : effectivement ce système de stockage pourra être utilisé à cette fin (une clé qui indique la référence externe + le hash de la transaction, en stockant une valeur vide d’ailleurs car rien besoin de plus).

[elois]

@cgeek

Du coup ce système utiliserait un child trie ? Et stockerait des hash de façon à optimiser le stockage je suppose.

Presque, j’utilise effectivement les lib de substrate pour toute la partie mertkle tree, mais ce n’est pas un arbre enfant, c’est un autre arbre en dehors du storage, seul le root est inscrit dans le storage.

L’arbre complet sera stocké offchain. Et quand le root doit être mis à jour, les delta sont publiés dans un bloc, accompagnés de la storage proof permettant de calculer le nouveau root, c’est donc dans l’exécution du bloc qu’on calcule le nouveau root, ce qui garanti la validité de toute transition d’état de l’arbre de merkle

[HugoTrentesaux]

Ça me fait penser à ce que disent les médias de Odysee : https://www.francetvinfo.fr/internet/reseaux-sociaux/odysee-la-plateforme-des-complotistes-francais_4681703.html

À l’origine d’Odysee, le libertarien américain Jeremy Kauffman. Partisan d’une liberté d’expression totale, il crée en 2016 un réseau de partage de fichiers décentralisés, qui sera la base du fonctionnement d’Odysee. Les vidéos postées sont dupliquées sur des serveurs, mais aussi sur les ordinateurs des utilisateurs, rendant l’impossibilité de supprimer les vidéos.

Autre caractéristique d’Odysee : pas de publicité ni d’annonceurs à satisfaire. Les vidéastes sont directement payés en cryptomonnaies par les utilisateurs. Résultat : aucun risque d’être démonétisé. La plateforme n’interdit pour l’heure que les vidéos pornographiques ou appelant à la violence, des vidéos qu’elle pourra seulement déréférencer, à défaut de pouvoir les supprimer.

Et je rejoins @kimamila sur ce point :

@kimamila

Concrètement, la débat sur les annonces type « armes à feu », peut se porter sur des sujets plus sensible à arbitrer : charlatanisme, new age, etc. Et on ne sera clairement jamais d’accord ensemble sur ces sujets. Ça me parait assez évident.

Vu l’explosion des discours complotistes il va falloir faire un gros effort pour ne pas se faire envahir par des charlatans et des sectes. La question de la modération me paraît cruciale de ce point de vue. Il faudra des systèmes de tags / upvote / downvote pour que chacun puisse trouver le contenu qu’il cherche sans se faire envahir par une avalanche de contenu indésirable selon ses critères.

[poka]

@HugoTrentesaux

Vu l’explosion des discours complotistes il va falloir faire un gros effort pour ne pas se faire envahir par des charlatans et des sectes. La question de la modération me paraît cruciale de ce point de vue. Il faudra des systèmes de tags / upvote / downvote pour que chacun puisse trouver le contenu qu’il cherche sans se faire envahir par une avalanche de contenu indésirable selon ses critères.

Oui, et vue que ça se joue uniquement sur les fitres/données des indexer, plutôt pratique.

[tuxmain]

Nouvelle piste offchain : Veilid, présenté comme un mélange de Tor et IPFS. J’espère qu’il n’a pas les inconvénients d’IPFS.

C’est du Rust, totalement décentralisé (pas comme Tor), la présentation du protocole inspire plutôt confiance. Mais je ne sais pas quelles sont les promesses de la DHT, si c’est adapté à la G1.

[Frederic_Renault]

@tuxmain

Nouvelle piste offchain : Veilid, présenté comme un mélange de Tor et IPFS. J’espère qu’il n’a pas les inconvénients d’IPFS.

C’est un système de stockage de données p2p adressé par le contenu?
Quels sont les inconvénients de IPFS et quels seraient les avantages de veilid ?