Development talks

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
  • 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

3 Likes