Mise à jour forcée de Cesium (en douceur)

Clients Cesium
10

Ce fichier serait de toute façon utile. Dans Cesium v1.99, Cesium v2.0, Duniter Panel, ou même Ğecko. Il devrait intégrer des informations supplémentaires :

// avant migration
{
   "migration": false
}
// après migration
{
   "migration": true,
   "genesis_hash": "0xc184c4ccde8e771483bba7a01533d007a3e19a66d3537c7fd59c5d9e3550b6c3",
   "genesis_timestamp": 1741392000,
   "last_g1_v1_block_number": 811481,
   "rpc_bootstrap": ["wss://g1.p2p.legal/", "wss://g1.coinduf.eu"...]
}

On peut même avoir un fichier par réseau gdev.json, gtest.json, g1.json avec un champ active: true (plus parlant que “migration”). Ou même un fichier networks.json avec trois champs gdev, gtest, g1 qui contiennent ce qu’il y a ci-dessus.

L’utilité serait :

  • Le hash du genesis permet de vérifier si un endpoint RPC est sur le bon réseau.
  • Le timestamp du genesis permet de vérifier la cohérence des infos.
  • Le numéro du dernier bloc v1 peut être affiché à l’utilisateur dans Cesium v1.99 pour s’assurer de ce qui est antérieur ou postérieur.
  • La liste de bootstrap RPC est censée permettre de trouver d’autres endpoints RPC, endpoints squid, et autre (cf Liste des endpoints). Si ce n’est pas rendu accessible via RPC, il faudra mettre l’url des services qui remplacent, ou mettre à jour ce json régulièrement.

Et l’avantage d’avoir plusieurs réseaux est qu’un client v2 peut se connecter par défaut à g1 si actif, ou s’il est inactif proposer à l’utilisateur de se connecter à un réseau de dev à la place.

[edit] c’est fait : nodes / networks · GitLab
[edit 2] est-ce que ça te va @poka si on renomme ce sujet “Mise à jour en douceur de Cesium” dans la même idée que la “migration douce” ? (V2S: smooth gradual migration (clients and indexers side))

2 Likes