I’d say authorityMembers.incomingAuthorities().
1 Like
Looking at the code, claimMembership removes the identity from pendingMembership and inserts it into membership.
2 Likes
My current strategy was to move user documentation to the website: Duniter | Become smith.
- doc on website: tutorial-like, gives broad view about what’s happening and how to use Duniter
- doc on Duniter repo: specification-like, close to Duniter internal behavior
This way in the repo doc we can stick to Duniter implementation and explain what the calls are actually doing. An other kind of “documentation” is the one directly included in the tools for example with tooltips. Guenoel is currently working on a tool for smith which helps visualise and understand and operate all the state transitions.
1 Like
Thanks for the link !
Reading the page of the link, I see an error here too 
:
Request smith membership
Before getting smith certifications, you have to declare your wish to become smith by calling the
smithsMembership.claimMembership()extrinsic (see runtime calls reference). For this you have to provide:
Should be smithsMembership.requestMembership()
1 Like
I am trying to follow the fixed docs (commit aac91ac9036fd189f03f0ba640e7ec0e6e40e1ed) :
- In the UI: developer > RPC call > author > rotateKeys() and copy the result in clipboard
This is OK.
- In the UI: developer > extrinsics > YOUR_SMITH_ACCOUNT > authorityMembers > setSessionKeys(keys) then paste your session keys and run the query.
This is not OK.
I get the authorityMembers.NotMember error… In Tikka and also in Polkadot.js.
Python exception from API client substrate-interface :
ERROR:root:{'type': 'Module', 'name': 'NotMember', 'docs': ['Not member']}
I am using my V2 account (identity owner moved from V1 account 5EAL8tSa5TQsxuiveWCY6TbmmFQbxGYNHKb7QtPRwj34Mtzz)
address : 5FH48744BHgNoLBe8syGXbTEnSpGhp8ttdAKW4MWcR7TUKai
identity index : 7174
expire_on : 5,184,000
Any idea ?
1 Like
I did not understand what was happening with the session keys.
Actually set_session_keys updates the session keys submitted as metadata in claim_membership, which does not check the metadata are valid. So don’t call set_session_keys, put your session keys in claim_membership directly.
set_session_keys is only needed for rotating the keys when you are already smith.
I’ll fix the docs, thanks!
2 Likes
I have requested smith membership from Tikka and my membership status is pending as expected 
:
@smiths-GDev could you certify me please ? Thx in advance !
address : 5FH48744BHgNoLBe8syGXbTEnSpGhp8ttdAKW4MWcR7TUKai
identity index : 7174
3 Likes
fait !
1 Like
For the fun, I tried to certify you from my lost identity (2457) and it worked! (see block 1606658). I still have to investigate this big bug, add live tests, and fix it.
1 Like
fixed in commit 6980fe89. Thanks for reporting. That’s part of the reason I whish we have more smith: improving and proofreading documentation.
Done. You have 4 certs now. Should be enough to issue smithsMembership.claimMembership().
2 Likes
After pushing the button “Claim membership” in Tikka, my smith membership status is validated, and with an expiring block info !
GUI is a WIP and will be improved over time (“expire on” will display a proper date…).
3 Likes
Currently the expiration really happens at this block number. Future block times can be estimated quite precisely but it’s still an estimation, so I think the block number should be displayed along with the date, and something somewhere should say the date is estimated. (maybe a little icon after the value, that switches block number or date display, so it’s still selectable)
3 Likes
I sent the go_online command from Tikka and 2 hours later, I am writing blocks !
1,635,182 0x4f4b07e5d5b009c0ed324a950ab876148240c78f76c5a305b1f4da662f3d15dc
SMITH (EXTENSION)
4 Likes
My session keys string was stored in Tikka DB, then I destroyed it to modify tables… 
So, can I find session_keys string somewhere in storage ?
I found session.nextKeys() with some string, and under my address, the same in session.queuedKeys().
session.nextKeys: Option<GdevRuntimeOpaqueSessionKeys>
{
grandpa: 0x08843a9bb395a4565ab4d5453df6ac7491e529b43a8993d67e7727fb5d1a9d14
babe: 0x886fcbdd8751185322b663c702585fa09ea93fdedcebd1f51190d0b2eb44cd41
imOnline: 0x7eff459774a18625abff2be729838bc046c9aa365771fa1091861a133659307a
authorityDiscovery: 0x7edd040fd19ce89fbb0dd11f40c3b81369956c3c821909bfaa7a5dc24488d348
}
But this is not the long string I got with rotate_keys().
As a workaround, I can use rotate_keys(), then set_keys() to change them and store them again in Tikka DB…
Your private keys are in the keystore folder of your server. What you get with rotate_keys() is only the public keys. You can check that your node still has the private keys corresponding to your public keys by calling the rpc method author.hasSessionKeys(sessionKeys) on your smith node (here sessionKeys means “public keys”).
There is no need to store your public keys anywhere as they are declared publicly.
[edit]
you declared the session keys 0x08843a9bb395a456... in block 1606142.
I do not know if you called setSessionKeys() after that since this call does not emit an event and that we do not index called extrinsics yet.
1 Like
Thanks for retrieving it from your archive node ! 
I get my response indirectly, because I suspected session.nextKeys to be a split form of the session keys returned by rotate_keys(). And it is indeed !
If I concatenate the four keys, I get the right key found in the block :
08843a9bb395a4565ab4d5453df6ac7491e529b43a8993d67e7727fb5d1a9d14886fcbdd8751185322b663c702585fa09ea93fdedcebd1f51190d0b2eb44cd417eff459774a18625abff2be729838bc046c9aa365771fa1091861a133659307a7edd040fd19ce89fbb0dd11f40c3b81369956c3c821909bfaa7a5dc24488d348
I need to store the session keys in Tikka to transfer the “Rotate keys” button result to the “Request membership” button which requires it (and “Publish Keys” button requires it too, as it is set_keys(session_keys) command).
May be one day I will hide the session keys under the hood, but for now, it is helpful to show it for debug…
1 Like
Indeed the session keys are just the individual keys concatenated.
Each pallet can define session keys. If we add a pallet that needs another key, we will have longer session keys.
1 Like
My nodes were up but stuck, and no more on telemetry. Thanks to @Pini to report it to me.
I restarted both, and today there are both on telemetry, RPC node is fine, but Validator node is stuck.
So today I tried to send goOffline to the Validator node with Tikka. But as it is stuck, it does not process correctly the RPC request, and the python request code is stuck infinitely awaiting a response.
So I changed my connection to the RPC node and sent the goOffline command with Tikka.
This works fine !
goOffline is an extrinsic, an operation on blockchain, you submit it to the network, it does not matter which node you’re sending it to. Not to mix up with rpc calls which is a way to interact with a specific node.
2 Likes