Migrate to Substrate

Duniter v2 Substrate support with substrate-interface:

• APIs: RPC, and GraphQL Hasura

---

Resources

• substrate-interface repository
• SubstrateInterface documentation
• Extrinsincs: Runtime calls
• Runtime events
• https://git.duniter.org/clients/cesium-grp/cesium2s/-/issues
• https://forum.duniter.org/t/vocabulaire-de-base-pour-comprendre-duniter-v2s-lecture-fortement-recommandee-pour-tous/9053
• https://forum.duniter.org/t/liste-des-parametres-protocolaires-de-duniter-v2s/9297/1

---

Transition plan

• Release and maintain v0.12.0 as BMA-only
• v0.20.0dev as Substrate-only

Allow non-related developments/experimentation to happen in parallel?: Which would not create much git conflicts:

• Set up new website structure with MkDocs (#433 - closed)
• Configuration support (#79): Seems the best candidate, the class development it-self, not the integration in the commands
• Use a Terminal based and/or Graphical user int... (#18), Set console interface with Textual console/TUI ... (#440): PyGObject3, Textual TUI console: Just experimentation of the possibilities, interface design, no integration

---

Consider Hexagonal architecture

• duniterpy#117
• https://blog.octo.com/architecture-hexagonale-trois-principes-et-un-exemple-dimplementation/ en

---

Set up Duniter v2s and indexer on ĞDev

• Set-up Duniter-v2s
  • Become smith
• Set-up Indexer: Subsquid, duniter-indexer

Plan

• Split changes in child items/sub-tickets. Put them in the Kanban board and/or milestone.
• Ideas from Tikka roadmap
• Matograine’s plan

• Delete code of commands which will be rewritten, keep structure, pick code in git history for the reimplementation
• Delete step-by-step commands, functions which have been rewritten

Delete features which don’t make sense anymore and which are not very coupled

• Delete blockchain diffi, since the PoW is no longer a thing with BABE/Grandpa consensus algorithm
• Delete blockchain verify cmd, doesn’t make sense anymore, algorithm can be retrieved in the git history for next blocks implementation (#283)
• Delete checksum command since the address integrity (checksum) and currency is integrated into the address.

Set up network layers

• Introduce substrate-interface dependency
• Set up RPC API network layer
• Set up GraphQL API network layer

Pre-requisites

• Account storage support: authentication, revoca... (#477)

Authentication

v1/v2 methods handling

• Function to use v1/ED25519 or v2/SR25519 authentication to all commands depending on what has been passed
• save v1 auth files into config/auth directory
• Priority: v2 auth file, v1 methods. default?
• Warn in the release note (and from TUI?) that v1 auth methods are deprecated and will be dropped in next release (after migration to Duniter v2s). Please convert your authfiles to v2 format.
• Allow commands authentication only from encrypted json v2 format
• Not very useful feature. Delete Command to convert v2 pubkey v1 → ss58 v2s address

v2 method

• Implement Substrate authentication method: create, read
• save-authfile command: Convert v1 authentication methods to encrypted v2 authentication json file format
  • Can’t save encrypted authfile from v1 authentication methods (ED25519)
• Encrypted json v2 format creation from mnemonic (Implement the identity and all the process arou... (#90))

Status

• Having both (v1) ed25519 and (v2) sr25519 authentication methods makes things more complex
• Substrate interface does not support to save this cryptography into the json encrypted file format

Options

• Will substrate-interface provide ed25519 to be save as json encrypted file format? Do we wait for it? Try to overwrite Keypair.export_to_encrypted_json() with ed25519 support if it works (super()).
• Get rid of ed25519 auth methods from silkaj:
  • transfer Ğ1 units from a ed25519 to an sr25519 (this transfer still requires v1 auth)
  • Can we convert at the conversion stage from Nd.js to Substrate with this migrator?

Others

• Get currency code/name from RPC
• Display fees per transaction and ask for confirmation (some are reimbursed, so mention the fees are reimbursed)
• Request uids from the indexer to set the link between the identity index and the identity nickname/alias

Migrate existing features

(I): requires the indexer

• Get information from displaying commands from RPC queries:
  • money balance
    • Take into account UD (not yet created)? Are they not yet part of the balance returned by Substrate?
  • (I?) info
  • (I?) wot status
• Adapt commands which send RPC calls extrinsics:
  • money transfer:
    • basic transfer
    • transfer reference 1
    • multi-recipients with batch
  • wot certify
  • wot membership
  • wot revocation
• Get information from displaying commands from the indexer:
  • (I) wot lookup
  • (I) money history
  • blockchain blocks

Important features to be migrated

Only implemented by Silkaj, so once we switch the Ğ1 to v2s ecosystem, following features will stop functioning:

• multi-recipients transfers to Ğ1 technical ecosystem remunerations
• DeathReaper: notifying the exclusions on the forums

Implement new features

• UD creation
• Display UDs in history command (even though they haven’t been created yet)
• identity: create, confirm, link-account, change-owner-key
• Blacksmith sub-WoT handling
  • Commands similar to normal wot?: smith-wot/smith: certify, lookup, membership, invite, accept status, update-key, set-session-key, go-offline, go-online, check
  • Integrate Smith license
  • Becoming Smith diagram
  • Check whether the RPC API connected to is in Unsafe, Safe mode
• Technical Committee: tech-committee: list-members, list-proposals, vote
• Mnemonic derivations (//0, //1,…)

Later

• Implement the identity and all the process arou... (#90)
• Change owner_key
• DeathReaper: Keep it similar listening to the blockchain events. Listen to exclusions from the indexer. Could be replaced with a feature onchain to report via email the exclusion. The datapod could store the email addresses. Having the emails accessible to everyone would be an issue for spam purposes. A private service/datapod should store the emails.
• Schedule transfer support