Becoming smith (request_membership, claim_membership)

Support Duniter-v2
1

As detailed in the doc (docs/user/smith.md · master · nodes / rust / Duniter v2S · GitLab), the user should become smith as soon as he requested membership and got enough certs. But it seems an additional call to claim_membership is required which is the opposite of what is documented (marked as disabled in xtask/src/gen_calls_doc.rs · master · nodes / rust / Duniter v2S · GitLab).

I do not know if I should:

  • fix the documentation
  • fix the code to avoid claim_membership call for smith also (same as main wot)

What do you think about it? Do you remember something about this?

3 Likes
2

I think I should fix the documentation:

  • request_membership → becoming smith
  • claim_membership → become member of the authorities

Maybe the latter should be renamed claim_authority or so.

3

I guess we could disable smiths_membership::claim_membership and add a an alias in the common runtime. We can’t do this directly in the pallet since it’s another instance of the same pallet for simple membership.

1 Like
4

I went for a pure documentation approach :rofl: (MR !133).

That’s what really is DDD: documentation driven development ^^

1 Like
5

I am implementing the smith process in Tikka.

I agree that claim_membership should be renamed claim_authority.

  1. In the UI : developer > extrinsics > YOUR_SMITH_ACCOUNT > authorityMembers > setSessionKeys(keys) then paste your session keys and run the query.

How can I know this step is already done. Any status query of this state ?

  1. In the UI : developer > extrinsics > YOUR_SMITH_ACCOUNT > authorityMembers > claimMembership(keys)

How can I know this step is already done. Any status query of this state ?

2 Likes
6

Storage session.nextKeys(pubkey) should be Some.

(you mean smithsMembership, not authorityMembers?)

Storage smithsMembership.membership(identity_id) should be Some. There is also smithsMembership.pendingMembership.

2 Likes
7

Thanks !

No. I really mean authorityMembers :sweat_smile: . This step 2. is from the documentation. I really mean the authorityMembers.claimMembership() result in the states.

I already manage smithsMembership.membership and smithsMembership.pendingMembership in my code (correctly I guess).

8

There is no extrinsic authorityMembers.claimMembership, the doc is wrong. This pallet only manages authorities, but delegates the choice of “who is authority” to other pallets (for instance smithsMembership).

1 Like
9

You’re right ! Doc needs a fix.

claim that the previously requested membership fullfills the requirements

If claimMembership refers to a previous requestMembership. It should be sent by the same account I suppose. The (futur smith) account/identity.

I can not fix the doc myself as I do not fully understand the steps here…

So the question is, where is the smithsMembership.claimMembership() result in the states ? :blush:

10

I’d say authorityMembers.incomingAuthorities().

1 Like
11

Looking at the code, claimMembership removes the identity from pendingMembership and inserts it into membership.

2 Likes
12

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
13

Thanks for the link !

Reading the page of the link, I see an error here too :sweat_smile: :

Request smith membership:link:

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
14

I am trying to follow the fixed docs (commit aac91ac9036fd189f03f0ba640e7ec0e6e40e1ed) :

  1. In the UI: developer > RPC call > author > rotateKeys() and copy the result in clipboard

This is OK.

  1. 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
15

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
16

I have requested smith membership from Tikka and my membership status is pending as expected :partying_face: :

Capture du 2023-04-05 18-25-55

@smiths-GDev could you certify me please ? Thx in advance !

address : 5FH48744BHgNoLBe8syGXbTEnSpGhp8ttdAKW4MWcR7TUKai
identity index : 7174

3 Likes
17

fait !

1 Like
18

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
19

fixed in commit 6980fe89. Thanks for reporting. That’s part of the reason I whish we have more smith: improving and proofreading documentation.

20

Done. You have 4 certs now. Should be enough to issue smithsMembership.claimMembership().

2 Likes