Préparation programme Sprint 25sem41 - cournonsec (Hackaton Ğtest)

Yvv · 30 September 2025 18:17

Bonjour les devs, je me permets un petit post technique pour préparer le programme du hackathon de la semaine prochaine 41 à Cournonsec. Je me permets également de baptiser quelques fonctions, c’est pour mieux circonscrire et vérifier si je positionne bien les choses. Mon propos est de formuler (genre user story avec critères d’acceptation) un ou plusieurs livrables en 4 jours et effectuer une recette jour 5.

Relance de la Gtest avec les variables réelles de prod.
Fonction sso de notre identité duniter certifiée.

#1. Quels sont les pré-requis ou inversement les points bloquants ? Indexeur opérationnel, manipulation des variables, nettoyage des arborescences pour que tous les outils aient leur 3 branches dev - test - prod (redockerisation ?), … Quelle documentation à fournir pour le smith-group ?

#2. Mon questionnement de fond porte sur l’architecture logicielle, anticipant les usages de notre identité numérique certifiée au-delà des usages stricts de notre monnaie (gestion de portefeuilles, transactions, …). Pour résumer :

rôle sso ( “Trustin’ID” ) : accès à tout un écosystème cohérent (interopérabilité), intégré ou pas, avec notre identité certifiée duniter. Possibilité d’un usage local (hors connexion).
rôle permissions et partages (“Trustin’Wallet”) : gestion de ses ressources (données, ressources logicielles ou matérielles) et des permissions accordées à ses contacts et groupes. Introduction de N1-N2 dans le paramétrage.
les applis majeures que sont la gestion des portefeuilles (appelées les “clients”) et les applis “échanges”, mais aussi les applis “messagerie” intégrées ou autonomes (dans la lignée de nostr connect), les applis “vote” (garantie d’une intégrité - unicité et capacité d’anonymisation pour tous les systèmes de vote connus et à imaginer), les plugin de signatures et chiffrement (docs, media, md,..)
… qui utilisent l’agent du Trustin’Wallet.

→la user story du sprint sem41 cournonsec serait orientée sur la capacité de se loger sur les forums monnaie-libre et duniter avec notre clé duniter - sso - (peut-être une US dans un nextcloud, celui d’axiom par exemple).

→→Question d’un “Trustin’Core” : trustin-core-js
Dixit faire un module, genre sdk, sans interface ni accès réseau, qui puisse être intégré dans les lib à venir, à commencer par Ğ1-papi. Juste avec BIP39 (génération restauration) et SLIP0010 pour les dérivations déterministes à chaque rôle (sso, monnaie, signature-chiffrement, …), les primitives ED et X - 25519, did:duniter .
Positionner le moteur de consentement au-dessus, mais encore une fois comme un module au rôle d’agent, pour les applis qui se connectent n’aient aucun accès aux clés. Est-ce une couche genre daemon local, avec PAPI qui intégrerait dans la lib la discussion avec le daemon ? Positionner ucan, oidc & Cie… quand ce sera l’heure, mon propos est de démarrer sur de bonnes bases pérennes.

Donc pour commencer est-ce pertinent, et le cas échéant est-ce le bon moment (opportun), pour isoler la fonction base crypto-core de tout le reste ?

Car si c’est le cas, alors Manu pourra au premier abord être contrarié de ne pas tout mettre directement dans PAPI pour intégrer la fonction sso dans son interface Ğ1 companion. Probablement une complication superflue de l’architecture et une charge de dev supplémentaire initiale, donc objection majeure, sauf s’il y a consensus sur la pertinence à plus long terme sur une telle structure.

J’aimerais simplement anticiper sur les dettes techniques et les fâcheries sur la conduite à tenir vis-à-vis des users au moment des évolutions d’usage ultérieures.

Et ce dernier point me permet de conclure sur l’UX en posant une question simple, du point de vue user, “Ğ1Companion se connecte-t-il à Trustin’Wallet ayant une existence propre, ou Trustin’Wallet est-il intégré de façon transparente dans Ğ1Companion, ou bien Ğ1Companion est-il Trustin’Wallet” ?

RQ : La perspective plus long terme de cette réflexion est aussi - dans un registre plus stratégique de positionnement - de considérer l’enjeu d’une identité numérique fiable sans autorité centrale ni biométrie, tout autant que l’enjeu d’une création monétaire sur son propre réseau monétique. D’imaginer ainsi toute une population d’utilisateurs qui viendra avant tout pour ça, pour qui le fait de disposer d’un réseau monétique avec sa devise inédite serait un cadeau bonus, une feature parmi d’autres dans un ecosystème qui cherchera à être complet sans ignorer Gödel ,-).

[ question opérationnelle pragmatique : tester les gitlabs issues - au lieu de OpenProject ou Jira - pour directement renseigner les tickets au bon endroit (ça commence à être un peu short de préparer les EPICs pour la semaine 41), pose la question de l’arbo.
Trustin’Wallet n’est pas vraiment une appli, ce serait plutôt un “group”, du genre “trustin-itiative”, … dans lequel il y aurait le projet Trustin’ID trustin-core-js, le projet Trustin’Agent trustin-agent-daemon, le projet Trustin’Wallet trustin-wallet-user (extension web puis desktop), trustin-vote, trustin-sign (plugin pour libreoffice openoffice ..), etc…
A quel endroit je pourrais poser un premier backlog d’us pour le premier sprint sso … de la semaine prochaine ? ]

1000i100 · 1 October 2025 14:30

si g1-papi est comme je le comprend un reboot de g1lib par quelqu’un (@ManUtopiK ) qui consacre plus e temps que moi à son développement, alors selon moi, oui autant y intégrer les fonctions de dérivation, et module d’interopérabilité pour du sso, surtout si conçu de manière suffisament modulaire pour que les buildeur/packager d’app soit capable d’élaguer le code inutilisé de g1-papi pour n’intégrer que celui utilisé pour un cas d’usage ou un autre.

Intégré en priorité du sso gitlab, notamment pour les gitlab issue, même avant l’intégration sso sur forum discours me semble une bonne idée :

c’est moins pertinent pour le grand public, donc peut-être moins motivant pour avoir du wahou de la communauté, mais ça génère aussi moins de support utilisateur à l’issue d’une première phase expérimentale de sso à l’issue d’un hackaton
ça permet d’avoir en priorité des dev ou des utilisateur avancé qui testent les fonctions de sso (pour ajouter des issue), donc des personnes davantage capables de comprendre et de décrire ce qui se passe et ce qui dysfonctionne, donc très adapté à avoir du feedback de qualité sur une phase alpha/béta.
ça touche un public plus limité, donc si on fait des erreur de conception/ergonomie, on peut plus facilement changer d’approche en expliquant aux early adopter ce qui change, plutôt que de se trainer du legacy pour un empiècement à donner à la commu de quoi jouer avec nos nouveaux joujou brillants

Je ne suis pas opposé pour autant à ce qu’on mette en place du SSO à plein d’autres endroits destiné à la commu dans son ensemble (forum, nextcloud, nostr…). Je recommande en revanche de ne pas communiquer dessus publiquement (forum utilisateur, site de onboarding pour les nouveaux…) avant qu’on l’ai suffisamment nous même testé et utilisé ces nouvelles fonctions, et qu’on l’ai fait testé par nos proches non tech pour avoir leur feedback sans être inondé.

Ma plus grande inquiétude, à la hauteur du potentiel que je vois aux usages SSO, est l’adoption prématurée de fonctionnement SSO mal pensé générant du legacy mal conçu à supporter parce que c’est déjà devenu un usage que certains réclament de conserver, bref, c’est en prod.

En gros je suggère une phase de “closed beta” ou “private beta” avant de passer à une phase “open beta” avant de suggérer et d’intégrer le sso pour un usage massif par la communauté.

Je m’attend à ce qu’on cherche à faire d’abord au plus simple, et ça me semble bien normal pour tester.

plus simple coté dev, pour se simplifier la vie
plus simple coté utilisateur pour ne pas les perdre (et parce que nous sommes aussi des utilisateurs qui aimons la facilité)

Pour l’instant la communauté Ǧ1 est relativement jeune (non pas en age biologique, mais en maturité sociologique) l’immense majorité y vient parce que le projet l’intéresse (pour des raisons diverses, mais orienté collective plutôt qu’individualiste).
Inévitablement, si nous grandissons, nous finirons un jour ou l’autre, par avoir des filous qui s’intéressent au projet pour en tirer un avantage personnel aux dépens des autres.

Avoir “confiance en la vie” et ne pas anticiper les usages hostiles/frauduleux en supposant qu’il sera toujours temps de s’en occuper le moment venu me semble dommage (au même titre qu’un perfectionnisme paranoïaque retardant à l’infini toute innovation sous couvert de principe de précaution).
Pourquoi ça me semble dommage ?
Techniquement, je suis quasiment sûr qu’on pourra corriger le tir, ce n’est pas là le problème.
Humainement, je vois plusieurs écueils :

S’il est nécessaire de changer des habitudes, les technophiles les changeront en premiers, et les plus paumés en derniers. Le coût de la sur-confiance en amont se retrouve à être payé par les plus vulnérables, renforçant donc leur vulnérabilité. S’ils avaient la croyance que la technologie est contre eux ou nuisible, ça risque de renforcer ce sentiment ou de le faire naître (donc renforcer le clivage technophile / technophobe) ce qui m’amène au point suivant.
La confiance placée dans l’écosystème, ses concepts sous-jacents, la communauté, les outils techniques et leurs devs risque d’en souffrir à différents degrés. C’est la vie et on ne peut s’en prémunir, je suis d’accord, mais la place de la confiance dans notre communauté à une place à part, c’est dans l’ADN culturelle du projet : ce qui fait la valeur d’une monnaie, c’est la confiance qu’on lui porte, ce qui rend robuste notre toile de confiance, c’est la confiance que l’on place dans les concepts théoriques associés ainsi que dans le respect des règles de certifications part la grande majorité des membres. C’est potentiellement aussi la confiance que s’il y a abus, on s’en rendra compte et qu’on pourra rétablir. Bref, la confiance me semble plus qu’ailleurs à protéger dans notre communauté. Donc anticipons pour réduire les risques de la malmener de trop.

Les risques majeurs que j’imagine en lien avec une adoption maladroite de SSO couplé à nos identités membres Ǧ1 : Imaginez que pour le moindre forum, jeu en ligne, kebab, app de messagerie, compte bancaire, soin médical, controle d’identité, coupon de réduction, vote, certificat de propriété immobilière ou d’aptitude à conduire, aussi bien que pour envoyer un like, vous utilisiez le même compte et le même procédé pour attester de votre identité.

voyez-vous d’un bon oeil que ce soit le même compte et donc que toutes ces actions puissent être associée à votre personne…
- contextuellement, par votre interlocuteur spécifique ?
- publiquement parceque l’information est librement accessible ?
- suite à une fuite de données qui permet la corrélation du fait du compte unique ?
Quel procédé coté interface/ergonomie vous conviendrait pour authentifier aussi bien un vote démocratique, un like, qu’un acte de propropriété ou ou votre testament ?
- voulez-vous qu’il soit trivial, voir automatique, pour ne pas vous freiner à chaque like ?
- voulez-vous qu’il soit méticuleux et sécurisé, pour ne pas le faire à la légère ?
En cas de piratage de l’appareil d’un utilisateur, quel conséquences et moyen de rétablir la situation ?
- Comment faire opposition/révoquer pour éviter les dégats futur ?
- Comment limiter l’étendu des informations révélé ? (accès aux correspondances chiffrées, à la liste des services utilisés avec ces accès…)
- Comment limiter l’ampleur et le périmètre des dégats ? (peut-on vider tout les comptes de l’utilisateur d’un coup)
- Comment contester les actes frauduleux fait au nom de l’utilisateur ?

Ce que je suggère :

Éviter de rendre banal et insignifiant le déverrouillage d’accès à son compte membre pour la moindre action en lien avec la Ǧ1 et les SSO associés.
Lors de l’ouverture d’accès à un service en SSO, générer une clef dérivée dédiée, signée par le compte membre. D’un point de vue UX, l’utilisateur devrait avoir un délai pour lire et comprendre ce qu’il est entrain de faire avant de saisir le moindre PIN, code de déverrouillage ou autre secret. (pour répondre au point 1)
Une fois l’association avec la clef dérivée faite, à chaque accès au service, selon la nature du service, demander une simple confirmation, un PIN dédié (différent de celui pour le compte membre), ou juste connecter automatiquement.
Pour éviter la confusion liée à une démultiplication de clef publique pour une même identité, les logiciels devrait (sauf cas d’unicité anonymisé type vote) visibiliser l’adresse/pubKey membre, mais ne pas l’utiliser pour la crypto. Exemple, si je veux envoyer un message à @Yvv via, disons nostr, même en admettant que j’indique sa pubKey membre, l’app ira voir quel clef dérivée est associé à nostr, pour l’utiliser pour chiffrer mon message. De cette manière, @Yvv n’aura pas besoin de déverrouiller son compte membre pour déchiffrer mon message, mais ni lui ni moi n’auront à nous dépatouiller avec une multiplicité de pubKey.
A suivre… Si vous connaissez des standard ou simplement des articles qui se sont déjà penché sur ces problématiques et proposent des bonnes pratiques, ça m’intéresse.

poka · 1 October 2025 15:11

En termes de signature, il est question d’utiliser une clé dérivée en suivant une convention à déterminer (dérivation //1000 par exemple, peu importe). Il suffit de déclarer cette adresse comme link account à l’identité dans Duniter.

Concernant le lien avec l’identité, l’idéal serait de pouvoir prouver qu’on est membre sans révéler son identité. Auquel cas, le linkage d’account que je viens d’évoquer tombe à l’eau, il faut trouver autre chose, comme une simple signature depuis la clé membre comme tu le proposes.

Je crois que @tuxmain a des idées de R&D à ce sujet ? Les rings signature c’est ça ?
Est-ce que l’usage d’un service tiers serait absolument nécessaire pour ça ? N’y aurait-il pas un trick cryptographique pour faire ça ?

Car sinon, on peut imaginer un service entièrement automatisé, auquel on délègue notre confiance pour vérifier qu’un compte est bien propriété d’une identité membre, et émettre un certificat d’authenticité derrière.
Mais se pose alors la problématique de s’assurer qu’il n’y ait qu’un seul compte dérivé lié par identité membre. Rendant difficile la décentralisation de ce service tiers.

Et au final, si on passe par un intermédiaire d’authenticité, c’est un peu moins utile d’utiliser une clé dérivée au lieu d’utiliser une signature de son compte membre directement.

1000i100 · 1 October 2025 17:05

Pour moi, il y a des cas d’usage où le lien nominal avec l’identité membre est souhaitable (pour des enjeux de réputation par exemple), et d’autres ou on veut assurer l’appartenance et l’unicité, mais en préservant l’anonymat (vote notamment).

Dans les deux cas, se rajoute selon moi la complexité de pouvoir révoquer la clef dérivée sans révoquer le compte membre associé, ou transférer d’une clef dérivée à une autre pour garder l’historique sans laisser de pouvoir d’action à l’ancienne clef dérivée, donc si convention de dérivation, elle a besoin d’inclure plusieurs dimensions (par service, par révocation/transfert à minima)

aya · 1 October 2025 22:14

Bonne idée effectivement

C’est tout l’intérêt du framework UCAN (User Controlled Authorization Network), il permet la délégation d’autorité de manière décentralisée entre des clés au format DID.

ManUtopiK · 2 October 2025 01:43

Oui g1-papi est “tree-shakable” :

import 'g1-papi' donne la base pour duniter.
import 'g1-papi/node' pour le client websocket nodejs.
import 'g1-papi/web' pour le client websocket browser.
import 'g1-papi/vault' pour déchiffrer gcli.sqlite.

C’est la différence entre identity et linkedIdentity sur postgraphile ? Ça me renvois toujours la même chose.

account {
    identity {
      accountId
    }
    linkedIdentity {
      accountId
    }
  }

Pour l’instant avec g1companion, ce qui marche :

injecte du js dans les sites visités, qui peuvent demander à s’authentifier ou faire un transaction,
signer un message et vérifier un message chiffré,
convertir une adresse g1 en nostr,
créer un DID

Du coup normalement avec le DID et un challenge signé, on peut générer une preuve pour UCAN. Il faut maintenant stocker cette preuve quelque part. Dans duniter ? Datapod ?

Ok pour signer avec une dérivation.

Ça le cms WordUp le fait déjà !

poka · 5 October 2025 18:24

@cgeek @HugoTrentesaux Je pense que je vais me charger du prochain reboot de la GTest, étant le plus qualifié sur site pour le faire, sauf si @1000i100 veut s’en charger, on fera ça ensemble de toute façon.
On vérifiera que les prérequis en termes de changements sont bien appliqués.

Cependant, la dernière fois que j’ai lancé un nouveau réseau, c’était pour GDev #2, et à l’époque le processus était plus simple : il n’y avait pas tout ce flow CI obligatoire, et j’étais encore en pleine possession du fonctionnement de py-g1-migrator.

Entre-temps, vous avez pas mal changé le flow, et je ne trouve pas de documentation centralisant le reboot du réseau GTest sur le wiki.

Est-ce que vous pourriez référencer les étapes à effectuer, principalement sur la partie CI / py-g1-migrator / artefacts ? Ou me pointer une doc ou ébauche ?

Vous êtes selon moi les deux seules à maitriser ce processus (et @elois bien sûr mais il n’est pas trop présent en ce moment), mais je tague aussi @Moul et @vit qui peut être connaissent la partie CI / py-g1-migrator.

Sinon je me débrouillerait.
Par avance, merci

Pour info voici la “doc” que nous avions fait avec @1000i100 à l’époque du reboot gdev #2: ĞDev reboot tutorial - CodiMD (visiblement il n’y avait même pas encore py-g1-migrator à l’époque).

C’est extrêmement pauvre et je suis sûr que le processus à beaucoup évolué depuis. Je n’ai actuellement aucune autre ressource sous la main à ce sujet.

cgeek · 5 October 2025 19:11

C’est pour quand ? Je pense refondre le processus de CI pour le mettre directement dans le binaire Rust comme l’avait évoqué @elois. C’est beaucoup plus reproductible.

Selon le délai, je pourrais m’en occuper et te transmettre les billes.

poka · 5 October 2025 19:13

Dans l’idéal on aurait aimé le faire cette semaine, en début de semaine, mais si c’est nécessaire on peut évidemment repousser un peu.

cgeek · 5 October 2025 19:39

Début de semaine ça va être vraiment très court pour moi. Je me souviens encore du processus mais j’ai vraiment très peu de temps par jour.

Je peux éventuellement essayer et te redire chaque jour les étapes que j’ai pu valider, je pense qu’en 2-3j c’est fait.

poka · 5 October 2025 20:33

Si ce que tu compte faire vise à simplifier le flow de bootstrap, alors je pense qu’on va attendre que tu le fasses, on est pas à quelques jours prêt

Là en regardant les jobs de CI j’avoue que ce n’est pas très clair sur dans quel ordre lancer quel job, et quels étapes intermédiaires.

cgeek · 5 October 2025 20:37

Je vais faire en sorte que 100% du processus puisse être fait en CLI, moyennant peut-être une milestone créée à la main au préalable, je vais voir.

tuxmain · 5 October 2025 20:47

Si vous avez un subxt à jour, vous pouvez intégrer ma MR (sur la période d’éval de distance) si je ne l’ai pas corrigée avant. Il faut mettre à jour le metadata.scale mais chez moi subxt ne compile pas, il y a une étape de trop dans le build.rs, je réessaierai plus tard.

poka · 5 October 2025 20:50

Oui attention @bgallois vient de mettre à jour Substrate pendant que tu bossais sur cette branche c’est peut être pour ça, je te laisse fix pour qu’on puisse l’intégrer au prochain reboot.

tuxmain · 5 October 2025 20:54

Ce qui est bizarre c’est que la compilation de subxt essaie de compiler les tests, qui nécessitent un “substrate binary” (lequel, est-ce que duniter conviendrait, quel doit être son chemin, c’est pas dit). Mais cargo build ne devrait pas compiler les tests normalement.

poka · 5 October 2025 20:56

Basé sur ma compréhension + la codebase duniter et py-g1-migrator, j’ai utilisé un LLM pour générer cette doc destiné à détailler étape par étape comment bootstraper un network. Ca m’a l’air pas trop mal mais pas certain que tout soit correct: Bootstrap Nouveau Réseau ĞTest - CodiMD

Si vous voulez relire, mais de toute façon si cgeek repasse derrière ça devrait encore pas mal changer, on va attendre ces changements.

Pour rappel voici l’issue listant les choses à faire pour le reboot, il reste des choses à faire: Prepare ĞTest iteration 2 (#311) · Issues · nodes / rust / Duniter v2S · GitLab

@Moul cette issue est résolu non ? Use UD value from Ğ1 (#318) · Issues · nodes / rust / Duniter v2S · GitLab
Ca a été set manuellement, mais est-ce qu’on veut que ce soit set automatiquement à partir des données de py-g1-migrator?

Pour

UD first reevaluation date should be set

Rien n’est prévue dans le code/config pour ça côté Duniter, il faut tout passer ?

Dans le gtest.yml je vois

# FIXME: explain `null` meaning
first_ud_reeval: null

Laissant penser qu’il y a une raison pour le laisser null. Peut être que set le timestamp à 1766232000 suffirait ici?

J’ai poussé une branche avec cette modif ainsi que la mise à jour de smiths.

1000i100 · 6 October 2025 08:03

Ça continue à me tenter de faire le reboot moi-même avec ta supervision / ton soutien @poka (éventuellement complété de celle de @cgeek à distance si on coince tout les deux). Mais sous réserve que ça ne retarde pas le reboot (ou pas de plus de 24h).

A tout à l’heure

1000i100 · 6 October 2025 10:13

J’ai galéré un peu à retrouver le sujet préexistant concernant ce hackathon, je le remets ici pour faire le lien : Hackathon Axiom #2 - Authentification
Il y mentionne notamment ce pad : hackathon axiom 2 - CodiMD que je vous encourage à compléter notamment pour fournir les infos logistiques, covoiturage et jour d’arrivée/départ pour fluidifier la coordination.

PS : Forum monnaie libre, section Axiom-team, Financement :

Si besoin de remboursement de frais, merci de les y visibiliser

cgeek · 6 October 2025 17:35

Une 1ère avancée : duniter xtask g1-data.

Vous pouvez la tester depuis la branche network_reset_tools :

cargo xtask g1-data --dump-url "https://dl.cgeek.fr/public/auto-backup-g1-duniter-1.8.7_2025-10-06_18-00.tgz"

Cette commande prend un peu moins de 10 minutes pour transposer les données de la Ğ1 en un fichier genesis.json pour Substrate et des données d’index pour Squid.

Il ne me reste normalement que 3 étapes assez triviales à réaliser, avec un peu de chance ce sera fait ce soir sinon demain.

N.B. : le fichier https://dl.cgeek.fr/public/auto-backup-g1-duniter-1.8.7_2025-10-06_18-00.tgz a été généré automatiquement et un nouveau fichier est généré tous les jours à 00h00. Donc d’ici minuit nous aurons un nouveau fichier auto-backup-g1-duniter-1.8.7_2025-10-07_00-00.tgz à disposition, et ainsi de suite chaque jour.

J’ai configuré mon serveur pour garder les 5 derniers jours à partir d’aujourd’hui.

Merge de la branche network/gtest-1000 sur master

En toute rigueur on ne devrait pas avoir à le faire (il me semble), mais en l’occurrence il y a quelques modifications d’Eloïs à répercuter sur master avant de bootstraper un nouveau réseau. Je pense aux modifications sur le fichier gen_genesis_data ou sur l’oracle de distance par exemple.

C’est à faire en plus de Préparation programme Sprint 25sem41 - cournonsec (Hackaton SSO) - #13 by tuxmain

Edit 2 : j’ai oublié :

C’est plutôt une bonne doc pour le workflow actuel avec la CI, mais cela va changer avec mes modifications. Je pense même supprimer le workflow “reboot réseau” de la CI car au final ça arrive trop rarement pour avoir un intérêt.

poka · 7 October 2025 10:34

Juste pas clarifier ce que tu as fait dans ta commande hier, tu utilises du Rust intégré à Duniter qui lance un container Docker qui lance du python. On est d’accord ?