Données hors chaîne et leur indexation

R&D
,
1

Effectivement, la gestion des données hors chaîne ressort comme une priorité. Voici rapidement mes conclusions sur le sujet :

  • pour des raisons de droit à l’oubli, les données en tant que telles doivent plutôt être stockées hors chaîne (ça vaut aussi pour les commentaires de transaction pour qu’on puisse permettre leur suppression / désindexation en cas de propos diffamatoires par exemple)
  • par contre, l’annonce de leur hash peut être fait onchain car on a souvent besoin de consensus pour cet aspect
  • pour l’instant nous ne sommes pas prêts à gérer l’annonce en blockchain des données hors chaîne, ça mérite qu’on établisse un protocole commun bien pensé
  • mais on a besoin au plus vite possible de savoir quelle donnée est légitime pour indexation, pour permettre de trouve un portefeuille par son nom via une recherche par exemple, et sans tomber sur une avalanche de résultats frauduleux (cf la recherche “numéro 2” qui donnait des dizaines de croix gammées)

Donc pour l’instant je propose d’utiliser la toile de confiance et un mécanisme de Duniter : le lien d’un compte avec une identité. Un compte portefeuille peut être lié à une identité via identity.link_account. Si un compte est lié, on indexe ses données, on ne les affiche pas en réponse à une recherche.

Pour les comptes collectifs ou d’associations, ça implique de lier un compte à une identité du groupe, ce qui n’est pas souhaitable à long terme, on préférerait un concept de groupe, mais qui peut répondre dans un premier temps au problème de l’indexation des pages de groupe (par ex la caisse des devs).

À terme il faudrait peut-être plutôt envisager l’utilisation de multisig ou introduire un nouveau concept.

Par contre, cela ne couvre pas le cas d’un compte d’individu non membre ou souhaitant être anonyme. Pour cela, il faut introduire un autre mécanisme de confiance. On peut très rapidement se mettre d’accord avec un format de remark dédié à ça contenant

  • un “magic bits” défini hors chaîne pour éviter de traiter des commentaires de transaction
  • l’adresse de destination
  • optionnellement le hash d’une donnée hors chaîne au format CID, pour associer une information à cet acte à des fins de traçabilité et d’audit

par exemple

# pour déclarer une confiance positive
/TRUST <ss58> <CID>
# pour déclarer une problème
/REPORT <ss58> <CID>

et indexer ces remark spécifiquement dans Squid, ce qui permet d’avoir :

  • les identités ou compte ayant attribué une confiance/défiance
  • la date
  • d’éventuelles informations additionnelles (plus probablement pour le report)

Squid maintiendrait quatre compteurs :

  • A le compteur d’identités ayant fait confiance
  • B le compteur d’identités ayant fait défiance
  • C le compteur de comptes ayant fait confiance
  • D le compteur de comptes ayant fait défiance

Un information n’est indexée que si A - B >= 0 et C - D > 0.

L’avantage de cette solution est que ça répond à la demande urgente d’avoir un mécanisme de modération au consensus. Et ça nous laisse du temps pour répondre aux point suivants :

  • comment déposer une donnée (pour l’instant via Cesium+)
  • gérer l’indexation sélective côté serveur (pour l’instant il va falloir filtrer côté client)
  • mettre au propre le fonctionnement de système de stockage offchain
  • mettre en place un système de modération sans consensus à l’échelle du contenu et non à l’échelle du compte

Discutons.

5 Likes
Ğecko talks / user support
2

Le truc c’est que cette solution est un quick win côté back, rien à faire côté Duniter, très rapide côté Squid.
Par contre côté apps c’est une autre histoire. Ça demande d’affiner une UX avec de nouveaux écrans, de bien l’intégrer, bien l’expliquer, aussi bien en termes de déclaration de nom de wallet lié à une identité, ses effets de bord, que d’UX de recherche, afficher ou non l’identité liée au wallet, vue mobile, etc.
Mais c’est bien spécifié, ça peut se faire assez vite, mais ça reste quand même du travail non négligeable.
Cette solution me convient, mais à savoir que certains utilisateurs ne seront pas satisfaits d’être dans l’obligation d’avoir une identité pour déclarer un nom de portefeuille.

Une solution pour les comptes collectifs et pour les personnes anonymes, c’est d’également permettre de déclarer un nom d’identité via une remark mais avec un dépôt de garantie relativement élevé, qui ne soit pas 1 Ğ1 quoi, comme 50 Ğ1.
Ainsi c’est un genre de location de nom de wallet, tu peux retirer ton dépôt quand tu veux et ton nom est désindexé de suite.
Tu peux ensuite plus tard décider de redéclarer ce nom au travers d’un linkedAccount pour te soustraire de l’obligation du dépôt de garantie.
Mais j’ai un doute avec ça, car ça n’empêchera pas n’importe qui de squatter un nom proche d’un nom d’identité qui a le payer, et s’il mixe il peut éventuellement être intraçable théoriquement.

Il faut aussi penser au cycle de vie de cette donnée, par exemple interdire d’enregistrer un nom de wallet correspondant à un nom d’identité existant, et aussi, si une identité veut se créer sur un nom de wallet déjà déclaré en linkedAccount, que fait-on, on l’empêche, ou bien on désindexe auto le linkedAccount avec notification à l’identité liée (chose plus difficile à notifier avec un simple dépôt de garantie).

4 Likes
3

J’ai pas mal réfléchi à la question et revu ma copie. Voici ce que je propose :

Annulation de vote

Il faudrait ajouter /UNTRUST et /UNREPORT pour changer son vote au cas où on se trompe.

Statuts d’ancrage de compte

Pour distinguer les votes d’identité et votes de compte et se protéger contre une attaque Sybil, il existerait quatre statuts d’“ancrage” de compte suivant les votes d’identité :

B=0 B>0
A=0 non statué condamné
A>0 approuvé contesté

Il est possible de passer de “non statué” à un statut supplémentaire “neutre” avec un dépôt de 50 Ğ1 (par exemple).

Il est possible de passer de “contesté” à “approuvé” si les votes “pour” sont cinq fois plus nombreux que les votes “contre” ( A ≥ 5 × B ).

Indexation et PageRank

Seuls les comptes approuvés, neutres, contestés ou non statués sont indexés. Seuls les votes des comptes approuvés ou neutres sont pris en compte. Un algorithme type PageRank s’exécute à partir de ces derniers de manière asynchrone (car coûteux) pour déterminer un score de confiance pour les comptes connexes. Voilà les combinaisons possibles :

ancrage PageRank interprétation
approuvé élevé compte bien établi, fiable
approuvé faible compte approuvé mais peu central
neutre élevé compte central, légitimité en attente d’être statuée par une identité
neutre faible compte périphérique
non statué élevé compte central mais risque de Sybil, à surveiller
non statué faible compte périphérique, bas dans les résultats
contesté/condamné ignoré ignoré quoi qu’il arrive, votes ignorés également

UX

Vue recherche

En terme d’UX, par défaut on ne voit rien, c’est juste comme un moteur de recherche qui affiche des résultats dans un ordre dépendant d’un score pagerank. Si tout va bien, les résultats des noms de compte seront affichés plutôt haut dans les résultats de recherche.

Par contre, quand une recherche retourne des résultats qui nous semble louches, on peut aller sur la fiche concernée rentrer en mode modération en cliquant sur le score de confiance en étoiles (:star:).

Vue modération

Sur la vue modération, on peut voir le statut d’indexation, l’historique des votes avec leur commentaires, le score pagerank, et des boutons de vote :+1: / :-1:. Si on n’a pas d’identité et qu’on est en “non statué”, on voit un bouton “gagner en SEO” pour le dépôt de Ğ1 (seule manière de “voter pour soi”.

Conséquences

Si une zone Sybil commence à trop monter dans le pagerank, il suffit à une identité d’aller tuer les comptes en “neutre” avec des votes négatifs. Cela a comme effet de réduire à zéro le pagerank de toute la zone Sybil. Une zone Sybil en “non statué” ne peut pas avoir un pagerank élevé car seul les votes des comptes en “neutre” sont pris en compte.

Limites

On pourrait faire un dépôt et voter massivement pour légitimer une zone, puis retirer son dépôt et réitérer depuis un autre compte, et ainsi abuser du délai du pagerank. Le pagerank devrait donc ne prendre en compte que les dépôts déjà existants lors du dernier calcul de pagerank.

C’est pas facile de faire un moteur de recherche résistant au spam et au Sybil !!

4

Oui, on ne peut pas empêcher ça, mais on peut voter contre avec une identité, et ça désindexe l’attaquant immédiatement.

Là tu parles de l’unicité, ce n’était pas de mon plan initial, je pense que c’est résolu par le pagerank. Par exemple si je crée quinze comptes “poka”, que je paie un dépôt en Ğ1 pour que mes votes soient pris en compte, que je upvote tous les comptes “poka”, ça apparaîtra toujours en dessous de l’identité dans les résultats de recherche, ça me paraît suffisant. Et je peux faire disparaître toute cette merde simplement avec un downvote d’une identité.

Je ne vois pas l’intérêt de faire un système d’unicité hors identité. On pourrait passer par le DNS pour ça. Par exemple le compte Axiom est upvoté par ses membres et donc passe en ancrage “approuvé”, il apparaît haut dans le pagerank même s’il n’est pas lié à une identité. On pourrait ajouter un challenge DNS du genre TXT _g1link.axiom-team.fr ss58 ou même un link rel="me" sur la page du site web.

Je veux bien être convaincu qu’il faut l’unicité pour des nom de groupes, mais pour l’instant je préfère penser sans.