### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [24 April 2024 14:43 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/1 "2024-04-24T14:43:45Z")
Je crée ce fil pour ceusses qui développent avec l’image docker `duniter/duniter-v2s-gdev`.
J’utilise la commande suivante :
```
docker run -p 9944:9944 duniter/duniter-v2s-gdev
```
L’intitulé dans Polkadot.js est :
```auto
Ğdev Local Testnet
gdev/800
#425
```
_Contrairement au nœud duniter-v2s:latest qui est en 801. Est-il à jour ?_
### Format SS58 à Null !!
```json
system.properties: ChainProperties
{
isEthereum: false
ss58Format: null
tokenDecimals: [
2
]
tokenSymbol: [
ĞD
]
}
```
Le format `ss58` est à `null`, ce qui me donne des adresses pour Alice, Bob et les autres différentes que dans Tikka (ss58 format 42).
Avec le client RPC Python j’ai une erreur si je veux obtenir une adresse à partir d’un mnémonique avec le ss58Format à `None`.
Dans Polkadot.js, il détecte Alice, Bob et les autres avec des adresses au `ss58format` à Null que je ne peux pas reproduire en Python. Moi je dois donner un numéro de format ss58.
Soit je soumet le problème au mainteneur du client Python (accepter un ss58 format à `null`), soit on met un numéro ss58 dans la gdev (42?). Qu’en pensez vous ?
Peut-être l’option 1, sachant que `gcli` a l’air aussi de bien supporter le `ss58` à `null`.
[EDIT]
Je faisais une erreur sur la dérivation, il faut une majuscule à //Alice ! Du coup j’ai les bonnes adresses.
Reste à savoir pourquoi il y a `ss58format=null` dans la blockchain, mais cela ne devrait pas me bloquer…
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [30 April 2024 15:57 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/2 "2024-04-30T15:57:07Z")
1. Bob invite Dave à être forgeron. (Dave status = Invited, expiresOn: 48)
2. Dave accepte l’invitation. (Dave status = Pending, expiresOn: 48)
3. Bob certifySmith Dave (Dave status = Pending, expiresOn: 48)
4. Alice certifySmith Dave (Dave status = Smith, expiresOn: 48)
```auto
smithMembers.smiths: Option
{
status: Smith
expiresOn: 48
issuedCerts: []
receivedCerts: [
1
2
]
}
```
A quoi correspond la valeur en blocs `expiresOn` ?
J’ai laissé `Dave` longtemps à `Pending`, puis une fois le bloc largement dépassé, son status n’avait pas bougé et j’ai pu le certifier…
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [1 May 2024 10:46 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/3 "2024-05-01T10:46:12Z")
On dirait que tu utilises une version du runtime antérieure à la correction de [#194](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/194). C’est un nombre de sessions, et pas de blocs (donc 48h) mais c’est vrai que ce n’est pas documenté dans le code 😱 : [/pallets/smith-members/src/lib.rs#L125](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/04b6a1ce11df2e1df3715e4228f01d11a69f293a/pallets/smith-members/src/lib.rs#L125).
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [1 May 2024 12:41 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/4 "2024-05-01T12:41:21Z")
> [@HugoTrentesaux](#):
>
> On dirait que tu utilises une version du runtime antérieure à la correction de [#194](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/194).
Oui, c’est ce que je précise dans mon premier post : l’image docker `duniter/duniter-v2s-gdev:latest` de la gdev locale avec Alice n’est pas à jour (runtime 800 au lieu de 801).
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [1 May 2024 13:09 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/5 "2024-05-01T13:09:41Z")
Oups, désolé, je suis allé un peu vite, j’avais oublié ce post. En fait on a publié le runtime 801 sur le réseau ğdev mais sans publier de nouveau client qui intègre ce runtime dès le genesis. C’est lié à [#195](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/195).
Pour le format ss58, il faudrait l’ajouter dans les client specs : [node/specs/gdev\_client-specs.yaml · master · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/node/specs/gdev_client-specs.yaml?ref_type=heads).
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [4 May 2024 14:54 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/6 "2024-05-04T14:54:05Z")
Cela avait déjà été signalé, et @cgeek avait confirmé ce comportement de Duniter, que quand on fait go\_online, le statut Autorité devient Online, mais dans les faits l’identité n’est pas encore Online.
Je viens de voir de nouveau ce comportement avec Tikka.
- Alice invite Dave, qui accepte et est certifié par Alice.
- Bob veut certifier Dave aussi mais n’est pas online : message d’erreur “Only online Smiths can certify other Smiths”.
- Bob envoie go\_online. En quelques secondes il est statut autorité online.
- Bob certifie aussitôt, mais impossible, même message : “Only online Smiths can certify other Smiths”.
Il semble y avoir une différence entre l’_information_ du statut de l’autorité et son statut _réel_ online/offline .
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 May 2024 15:32 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/7 "2024-05-04T15:32:09Z")
C’est comme ça que cgeek a conçu le privilège de certification. Il faut être online, pas seulement annoncer qu’on va le devenir. Plus précisément, `expire_on` est mis à `None` quand `on_smith_goes_online` est appelé, ce qui est le résultat du hook `on_incoming_member` qui est appelé par `new_session` de la pallet `authority-members` quand il lit `IncomingAuthorities`. Le changement du set des validateurs se fait session par session car c’est lui qui sert de base au calcul de la VRF. Cf [Axiom\_conf\_tech-Elois-BABE-GRANDPA-nov\_22 - P2Tube](https://tube.p2p.legal/w/9CssP7pnMnP74z3JABi5of) pour plus de détails.
> [@vit](#):
>
> Bob envoie go\_online. En quelques secondes il est statut autorité online.
À quel niveau lis-tu ce statut ?
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [4 May 2024 15:43 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/8 "2024-05-04T15:43:31Z")
> [@HugoTrentesaux](#):
>
> À quel niveau lis-tu ce statut ?
Avec un “query” `authorityMembers.onlineAuthorities` sur les données de la chaine (le storage) :
Je viens de faire `go online` avec Bob (identité 2) :
authorityMembers.onlineAuthorities: Vec
[
1
2
]
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 May 2024 15:54 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/9 "2024-05-04T15:54:03Z")
Je n’ai pas le même comportement chez moi.
```sh
> duniter --dev
# authorityMembers.onlineAuthorities vaut [1]
> gcli --no-indexer -n local -S predefined -s Bob smith go-online
transaction submitted to the network, waiting 6 seconds...
smith went online MemberGoOnline { member: 2 }
# authorityMembers.onlineAuthorities vaut toujours [1]
```
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [5 May 2024 10:24 UTC](https://forum.duniter.org/t/developpements-avec-docker-duniter-duniter-v2s-gdev-alice-bob-etc/12200/10 "2024-05-05T10:24:51Z")
C’est une bonne nouvelle si ton environnement est plus à jour que le mien. 🙂
Quand l’image docker `duniter-v2s-gdev` sera à jour en 801, je ressaierai.