We had a nice meeting yesterday with 8 people during 2 hours. Here is a short recap of what was discussed:
Info
- there is design work on a gchange with moderation done here:
- some NGI funding applications were submitted through Axiom Team
- Pour une place de marché / Gchange
- Pour du vote en ligne s’appuyant sur la TdC
- Pour du SSO via g1compagnon et autres aspects de g1compagnon
- the Axiom Team secret category was moved from Duniter forum to Monnaie Libre forum
Agenda
- Accounts created before genesis and post genesis can be told apart using their creation block stored in squid (see Duniter-squid version 0.2.8 and Ğ1nkgo v2 support progress, plan and pubkeys/address proposal for history)
- Urls of mirror endpoints used in clients should be known before g1 launch to allow easy transition. Up-to-date nodes and outdated ones can be told apart thanks to the genesis hash
- We talked about a uniform centralized notification system to allow transmitting important messages through all apps
- We designed the structure of a guidelines document that will be discussed in another forum topic. Here is what we came to:
guideline document structure
- gestion des endpoints et des réseaux
- gestion duniter rpc
- gestion graphql squid
- gestion hash genesis gdev, gtest, g1
- gestion des secrets et dérivations
- ed25519 par défaut
- scan des dérivations
- présentation du mnemonic
- code pin / mot de passe / [code de déverrouillage]
- utiliser un algo comme Argon2
- ne pas suggérer de code de <4 caractères
- gestion du compte membre vs portefeuille
- forcer une meilleure sécurité sur le compte membre
- suggérer une meilleure sécurité en cas de gros montants
- interdire de stocker le mnemonic (uniquement stocker seed ou clé privée ?)
- ne pas donner lieu à un déverrouillage du compte membre pour les transactions simples depuis compte courant
- gestion des notification de diffusion
- The storage use of smith nodes is a real problem that should be addressed or mitigated before g1 launch. Some options were discussed like modifying substrate to allow block header pruning or pre-allocating space on the system and preventing other apps to use it.
- We discussed then the minimum quantity of available services. Here are our conclusions:
minimum number of services to start the g1 v2
- forgeron
- minimum technique à 3
- question : combien de défaillance accepte-t-on ?
- critères plus fins : au moins 3-4 sur France 3-4 sur Espagne, 3-4 hors UE
- critères résilience : pas exclusivement OVH
- question DNS
- question : DNS google en dur : duniter container image uses google DNS resolvers to make queries (#296) · Issues · nodes / rust / Duniter v2S · GitLab
- critères plutôt que des nombres
- miroir
- minimum technique à 1
- même critères que forgeron, mais avec des exigencs en nombre plus faible (1 FR, 1 ES, 1 non-UE, 1 auto-hébergé, 1 en data-center, 1 DNS bind local, 1 DNS externe hors GAFAM)
- les critères du minimum doivent être couverts par des nœuds “attestés” par un membre
- squid
- même chose que les miroirs
- contrainte additionnelle dDOS
- DoS protection | SQD
- r&d ? authentification sur couche HTTP
- datapods
- strict minimum 3 par expérience C+
- minimum 5 pour être “confort”
- règle de distance et précalcul
- mini 3
- Finally install methods were discussed with the idea of making
curl […] | sh
the default install method to reach ultimate simplicity. A way to make it decentralized using blockchain was also discussed.
For more details you can see on Dev talks 2025-04-04 - CodiMD