Pour tester certains paramètres, pouvez-vous certifier l’identité de test toto (numéro 17743) sur la nouvelle g1 ?
N’hésitez pas à essayer de change owner key (si vous ne forgez pas) ou faire d’autres opérations sur des clients aussi, pour vérifier que tout marche.
Oui c’est l’idée, mais pour l’instant je n’ai pas publié de version qui gère ce comportement. J’espère le faire aujourd’hui.
Mais pour iOS en particulier, la parution d’une version sur l’AppStore pourrait prendre 1 semaine.
@aya est-ce que vous pensez encore modifier les paramètres “g1” avant la mise en prod ?
( pour être ± sur d’avoir le bon g1_metadata.scale pour g1cli 
)
A post was split to a new topic: Configuration de la Ğ1 : existentialDesposit
oui ça peut encore changer.
Non, au vu des délais de réponse annoncés, je pense qu’il est plus sage de garder Cesium2 sur les comptes stores Axiom actuellement en place, ça te fait moins de boulot.
L’intérêt de le mettre sur l’ancien compte est d’utiliser le même appId et donc de permettre aux gens de simplement mettre à jour l’app Cesium pour avoir Cesium2.
Mais l’inconvénient de cette approche, maintenant qu’on n’a pas mergé ni mis en prod cette MR sur Cesium 1, marquée comme étant prête le 2 novembre 2024, c’est qu’on ne pourra pas avoir les 2 apps installées côte à côte sur un même appareil, et donc qu’on ne pourra pas inviter les gens à installer Cesium2 avant le lancement, ou alors ils ne pourront plus utiliser Cesium1 pendant ce temps.
Et ça me semble un peu tard pour merger et déployer une version de Cesium 1, d’autant que la seule personne ayant accès aux stores Cesium 1 n’est pas disponible.
@cgeek, @HugoTrentesaux, @poka
Je remarque un soucis avec mon noeud Smith “G1” redéployé hier (suite à la demande de @aya ).
Pour une raison obscure, le gcli installé en local n’arrive plus à l’utiliser pour les requêtes RPC alors que cela à bien fonctionné hier pour faire les identity change-owner-key, smith update-keys, smith go-online etc…
Alors que si j’utilise l’Api RPC du noeud Archive déployé au même moment, cela fonctionne.
# Le Smith & Oracle
docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
duniter-g1-distance-oracle duniter/duniter-v2s-g1-1000:latest "docker-distance-ent…" distance-oracle 16 hours ago Up 16 hours 9615/tcp, 9944/tcp, 30333/tcp
duniter-g1-smith duniter/duniter-v2s-g1-1000:latest "docker-entrypoint" duniter-g1-smith 16 hours ago Up 16 hours 9615/tcp, 30333/tcp, 127.0.0.1:9965->9944/tcp
Le port (interne 9944) est bien exposé sur 127.0.0.1:9965
./gcli config show
Ğcli config
(fixed) Ğune network: gtest
duniter endpoint: ws://127.0.0.1:9965
indexer endpoint: http://127.0.0.1:5678/v1/graphql
address: g1LrrQcqobzaGX8QgB6T3aMEijVzQEubbpRLw6EesoYH8Nico
(Vault: Base[address:g1LrrQcqobzaGX8QgB6T3aMEijVzQEubbpRLw6EesoYH8Nico, g1v1_pub_key:6bkx86s9AyigmwePu9v9dNuS4oiQyWyEXu3p5uZo8tar, name:Some("Nicolas80-G1"), crypto_scheme:Some(Ed25519)])
./gcli identity show
Duniter("can not connect to duniter ws://127.0.0.1:9965")
./gcli -u wss://archive-rpc.g1.brussels.ovh identity show
Identity index: 12242
Username: Nicolas80
Address: g1LrrQcqobzaGX8QgB6T3aMEijVzQEubbpRLw6EesoYH8Nico
Status: Member
Certifications: received 13, issued 17
Smith status: Smith
Smith certs: received 14, issued 14
Linked accounts count: 2
./gcli -u wss://archive-rpc.g1.brussels.ovh smith show-online
Online:
poka, 1000i100, tuxmain, SyoulAnuanua, Nicolas80, JosselinFERREIRA
Incoming:
Outgoing:
netstat -lntp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
...
tcp 0 0 127.0.0.1:9965 0.0.0.0:* LISTEN -
...
EDIT
Je vois dans les logs de l’Oracle que cela à commencé à planter tôt ce matin (alors que rien n’a changé sur le serveur) 
2026-02-22T10:11:41Z Waiting 120 seconds before next execution...
2026-02-22T10:13:41Z DEBUG [jsonrpsee-client] Connecting to target: Target { host: "duniter-g1-smith", host_header: "duniter-g1-smith:9944", _mode: Plain, path_and_query: "/", basic_auth: None }
2026-02-22T10:13:41Z DEBUG [jsonrpsee-client] Connection established to target: Target { host: "duniter-g1-smith", host_header: "duniter-g1-smith:9944", _mode: Plain, path_and_query: "/", basic_auth: None }
2026-02-22T10:13:41Z DEBUG [distance_oracle::api] Looking at Pool0 for pool index 2
2026-02-22T10:13:41Z INFO [distance_oracle] Nothing to do: Pool does not exist
2026-02-22T10:13:41Z Waiting 120 seconds before next execution...
2026-02-22T10:15:41Z DEBUG [jsonrpsee-client] Connecting to target: Target { host: "duniter-g1-smith", host_header: "duniter-g1-smith:9944", _mode: Plain, path_and_query: "/", basic_auth: None }
2026-02-22T10:15:41Z DEBUG [jsonrpsee-client] Connection established to target: Target { host: "duniter-g1-smith", host_header: "duniter-g1-smith:9944", _mode: Plain, path_and_query: "/", basic_auth: None }
2026-02-22T10:15:41Z
2026-02-22T10:15:41Z thread 'main' panicked at /root/distance-oracle/src/api.rs:32:10:
2026-02-22T10:15:41Z Cannot create RPC client: Rpc(ClientError(User(UserError { code: 4003, message: "Client error: UnknownBlock: State already discarded for 0x52b6e6117eeef1176f808e1b2477b1fa91b2b4c2eb5a4ee19526de6b583fce5d", data: None })))
2026-02-22T10:15:41Z note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2026-02-22T10:15:41Z Waiting 120 seconds before next execution...
...
Depuis 10:15:41 GMT l’Api RPC de mon noeud Smith ne fonctionne plus et j’ai cette erreur en boucle 
Le message d’erreur tout seul:
Cannot create RPC client: Rpc(ClientError(User(UserError
{
code: 4003,
message: "Client error: UnknownBlock: State already discarded for 0x52b6e6117eeef1176f808e1b2477b1fa91b2b4c2eb5a4ee19526de6b583fce5d",
data: None
}
)))
Non j’ai coupé ce matin le bootstrap, il faut couper le 0.14.0.
C’est peut-être parce qu’il n’y a plus de noeud archive rpc online que tu constates des bugs avec gcli?
ok je coupe… et reste à dispo
Idem pour cesium.app : il faut cette fois un compte OVH et me le communiquer.
Je te l’envoie en MP.
C’est très simple de te donner les droits. On fonctionnait comme cela pour Cesium v1 : un autre dev faisait les mises à jour. Mieux vaut être sur un fonctionnement collectif, pour être plusieurs a pouvoir agir.
Ensuite je crois que nous avons déjà bien contribué a Cs2, pour en conserver (encore un peu) la paternité… non ? même si je sais que j’ai été absent ces derniers temps (comme bien d’autres avant moi, a d’autres moments, hein ? ). Cependant mes grosses échéances au boulot se terminent ce mois ci. Ouf ! (Migration d’un SI client).
J’ai hâte de voir tout ce que vous avez fait.
J’ai déjà noté quelques points que j’aimerais revoir, niveau ergonomie. Mais très simple et peu risquées a faire. Je vous ferai un autre post sur ce sujet.
Pour Apple Store : il faudrait déjà voir si l’on reprend le même appId ou pas, sachant que l’on a déjà communiqué qu’il existerait deux applications. Aussi je ne sais pas si l’application existante côté AxiomTeam peut être transférée ou pas, ou s’il faut en recréer une de ton côté.
En tout cas je suis en train de livrer une version RC de Cesium2, on a tout ce qu’il faut pour le démarrage de la Ğ1 dedans selon moi. Il ne va pas falloir qu’on tarde étant donné le délai de validation d’Apple.
Côté Android, je suis totalement néophyte. A vous de me dire quoi faire.
Je pensais conserver g1v2.duniter.org et indexer.duniter.org pour la Ğ1.
Peut-être que je renommerais ce premier vers rpc.duniter.org qui est plus précis.
Finalement Cesium2 sera simplement une mise à jour de Cesium, je l’ai annoncé à l’instant ici.
Une mécanique de récupération des comptes est en cours de finalisation et rend la chose plus acceptable, même si temporairement les utilisateurs perdront la messagerie Cesium.
Je viens de relancer un réseau runtime g1 pour tester le flow.
Tout semble en ordre, mais si vous voulez investiguer vous trouverez les images docker de toute la stack sur docker hub duniter, et voici mon endpoint rpc archive: wss://g1.p2p.legal/ws
squid: https://g1-squid.axiom-team.fr/graphiql
Je le laisse démarré un peu pour ceux qui aurait besoin, à tout hasard, côté client, de générer le code gen du runtime g1 pour préparer vos outils. Je sais que ça a été le cas pour durt2 par exemple
Comme d’hab une fois arrêté je supprimerais tags, branche, release et image, il n’y en aura plus aucune trace.
ping @elois si jamais tu veux check des choses avant que je le coupe.
Du coup, on est passé à duniter/duniter-v2s-g1-1200:latest ? (les images “1000” n’existent plus)
oui