Duniter validator is listening on default port 30333 actually. And the docker-compose file maps it to the host’s port 30334. How is it that no public addr is needed while one is provided for the RPC service which is mapped to the default 30333 port on the host?
1 Like
I think public address is never needed, it is only here to make things easier for bootnodes. Maybe @poka has a better understanding of this than me.
When trying to start a simple RPC node for testing I get this error:
2023-01-03 19:36:31 Duniter
2023-01-03 19:36:31 ✌️ version 0.3.0-f442e6eb161
2023-01-03 19:36:31 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023
2023-01-03 19:36:31 📋 Chain specification: Ğdev
2023-01-03 19:36:31 🏷 Node name: pini-gdev-rpc
2023-01-03 19:36:31 👤 Role: FULL
2023-01-03 19:36:31 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full
2023-01-03 19:36:31 ⛓ Native runtime: gdev-400 (duniter-gdev-1.tx1.au1)
2023-01-03 19:36:33 Cannot create a runtime error=Other("cannot create module: compilation settings are not compatible with the native host")
Error: Service(Client(VersionInvalid("cannot create module: compilation settings are not compatible with the native host")))
My server has an Intel Atom N28000 CPU. Should I build my own image for this to work?
1 Like
Interesting, I know nothing about Docker. Is it supposed to deal with processor architecture issues ? Try building Duniter on your machine, it should work.
1 Like
Thanks @vit.
Do I understand correctly that this problem should be solved by upgrading the Duniter Substrate fork so that it uses wasmtime >= 0.40.0?
In the mean time I’ll use the provided workaround: --wasm-execution interpreted-i-know-what-i-do.
1 Like
Now my instance starts but spits this error every 2 ou 3 seconds:
2023-01-03 20:39:33 💔 The bootnode you want to connect provided a different peer ID than the one you expect: `12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r` with `12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB`:`Dialer { address: "/dns/gdev.p2p.legal/tcp/30334/p2p/12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r", role_override: Dialer }`.
2 Likes
12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB
is the current @poka smith bootnode
12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r
comes from an other genesis (the one in master branch)
If you are building Duniter yourself, you have to use release/poka-chainspec-gdev5 branch.
2 Likes
Yes, just realized that. I’m still using the image I built. Reverting to the official one… It works!
2 Likes
Nice! I added you to the list, now we have to introduce you to the smith WoT ^^
1 Like
I’ll experiment a bit with the configuration. Then there are chances I’ll propose some configuration changes to the docker image.
2 Likes
I started a validator node.
But I was not able to send my session keys because my identity is on a v1 account…
So I need to move my identity on a v2 account before becoming a smith.
I will continue to work on the v1 to v2 account move in Tikka, as it is a perfect use case for it.
3 Likes
You can set your session keys and go online using Gcli, there is a branch with an option to use legacy credentials. ChangeOwnerKey is not yet implemented.
But you have to build it, or I can provide an x86_64 build this afternoon.
Actually polkadot guesses the public addr at startup:
2023-01-05 19:17:16 🔍 Discovered new external address for our node: /ip4/5.135.160.24/tcp/30333/ws/p2p/12D3KooWHswPUroThetPjvAHL9T64XkT4YxZjgYie49FHL1G55AH
But this cannot work when behind a proxy if you don’t map the P2P port to the very same one on the host. Then you need to configure the public address. Here is what I came up with for my server:
- DUNITER_PUBLIC_ADDR=/dns/gdev.pini.fr/tcp/443/wss
then polkadot automagically completes it with the endpoint path:
2023-01-05 19:17:13 🔍 Discovered new external address for our node: /dns/gdev.pini.fr/tcp/443/wss/p2p/12D3KooWHswPUroThetPjvAHL9T64XkT4YxZjgYie49FHL1G55AH
4 Likes
I’ve opened a MR to improve the docker image configuration and documentation.
And now I have two running nodes:
- pini-gdev-rpc
- rpc-http
- rpc-ws
- p2p via ws
- pini-gdev-smith
- p2p via ws
Both are behind my reverse-proxy and none of their ports is directly exposed to the outside.
Any way to check their connectivity status w/r to their respective endpoints?
OK, I think I’m ready to go this way now. First I need to become a member. Here is my new key:
5GBVhdJUdsGhxozu6R8X6x2pTZvuuW46s7JSU4tiW7Zd3WmY
Please certify it 
1 Like
Identity created, you need to call identity.confirmIdentity with a name.
1 Like
Thanks @tuxmain. But I’m lost 
The key I gave in my previous post is a derivation //0 from my root key. I created my account in PolkadotJs using the mnemonics, which relates to my root key. How to I tell PolkadotJs to use the derivation?
EDIT: Found the advanced settings option in PolkadotJs account creation UI. I’ve created an account for derivation //0 and triggered the identity.confirmIdentity(“Pini”) action. I’ve had no error message. But neither Tikka nor Gecko tell me that the identity was created.
EDIT2 : Connected Tikka to my own RPC node and now I see my identity was confirmed \o/
1 Like
You did confirm your identity and so I was able to certify you. Now, @poka @1000i100 @vit or any Ğ1 member can certify you using Ğecko. In parallel, we can submit smith certs like this:
The identity index correspond to my and your identity. They can be found via RPC call
We should build tool to monitor the smith WoT and emit smith certs.
1 Like