Files
decision/docs/recherche/vote-g1-chaine.md
T

3.6 KiB

Voter avec sa clé Ğ1 — lier, signer, inscrire sur la chaîne

Note d'orch, 2026-10-30, pour la « grande question du vote » de la revue d'Yvv : liaison avec une transaction de 1 Ğ1 pour une inscription sur la chaîne ? autre moyen ? plugin obligatoire ? complicité de Ğecko pour l'affichage ?

Le constat

Dans Monnaie libre, seuls les membres de la toile votent : une personne, une voix (CHANTIER.md). Le serveur ne reconnaît un membre que par la connexion Ğ1, qui passe par connect.monnaie-libre.fr. Cette connexion attend l'inscription de libreDecision auprès de poka (DEMANDE-CONNECT.md). D'ici là, toute identité vient d'une invitation, et personne ne peut voter dans Monnaie libre. C'est ce qu'Yvv a vu : « je ne peux pas voter dans l'ux ».

Vérifié le 2026-10-30 sur l'indexeur (indexer.duniter.org)

  • Les commentaires de transaction sont indexés (TxComment : remark, authorId, blockNumber, et les transferts qui le portent). Exemple réel : « Bienvenue dans la June ! », bloc 3396077.
  • Un compte mène à son identité (Account.identity, linkedIdentity), donc au statut de membre.
  • Le serveur lit déjà la chaîne et l'indexeur pour la taille de la toile (wot.rs).

Donc, sans plugin : une transaction commentée, faite depuis Ğecko ou Cesium², se lit côté serveur. On y retrouve le compte qui l'a signée, l'identité de ce compte et son statut de membre.

Non vérifié

  • Qu'un portefeuille puisse envoyer un commentaire seul, sans transfert (une « remarque »). Tous les commentaires observés accompagnent un transfert.
  • Qu'un portefeuille accepte un virement vers soi-même.
  • Ce que Ğecko affiche d'une remarque sans transfert.

Les voies

Voie Ce que fait la personne Coût Ce qu'on prouve Dépend de
1. Connexion Ğ1 (connect) signe la connexion dans Ğecko rien la clé à chaque session ; les votes restent sur le serveur poka
2. Liaison par transaction une fois : un petit virement commenté d'un code à usage unique, vers un compte désigné un virement, une fois la clé, une fois pour toutes ; ensuite on vote ici un compte destinataire
3. Une transaction par vote un virement commenté par vote un virement par vote ; un vote groupé = autant de virements chaque vote, sur la chaîne, visible dans Ğecko rien de plus, mais lourd
4. Bulletins signés, ancrés signe ses bulletins (portefeuille ou extension) ; le serveur inscrit l'empreinte des bulletins par une remarque presque rien chaque vote, vérifiable par tous la signature de messages par les portefeuilles (travaux de 1000i100 sur sso-connect, extension)

Recommandation

  • Maintenant : la voie 2. Elle débloque le vote sans attendre personne, garde une personne, une voix (une identité Ğ1 ne se lie qu'à une identité ici) et marche avec les portefeuilles d'aujourd'hui. Le virement apparaît dans l'historique Ğecko de la personne.
  • Quand connect répond : la voie 1 s'ajoute. Une identité déjà liée retrouve ses votes.
  • Plus tard : la voie 4, pour qu'on puisse vérifier chaque vote hors de notre serveur. Les votes sont déjà publiés avec le texte sur le dépôt git.
  • La voie 3 est écartée : un vote groupé (tout un document) coûterait des dizaines de virements.

À trancher pour la voie 2

  • Le compte destinataire et le montant (1 Ğ1 ?) : un compte libreDecision qu'Yvv crée dans Ğecko. Seule son adresse publique va dans la configuration du serveur.
  • La durée de vie du code (proposé : 24 h) et le délai de lecture (l'indexeur suit la chaîne à quelques blocs près).