Some concepts of Duniter v2 are counter intuitive. We might want to list them somewhere.
In Duniter v2, the public key / address is an AccountId for an account, but not for an identity which can change its “owner key”.
The identities are uniquely identified by an IdtyIndex (a number), but along the time, this index can then be associated to different AccountId.
An AccountId can not be used for multiple identities at the same time (we can not create an identity for and account which already has one).
The counterintuitive thing is that nothing prevents an AccountId to be used successively for different identities. The case where it could happen is when an identity is lost and erased from storage and an other identity is created for the same AccountId later on.
2 Likes
You mean like OldChristCosmic (5CJKhFCpdSpumgWjSZ3TQmejJuHV6iELJrtdrfs38SXuiQeB) identity ?
1 Like
If multiple certifications to a member expire at the same block, the receiver_received_count has decrementing values in each consecutive events. So the order of the events matter.
What do you feel counter-intuitive in this observation?
It means that we can not trust a single event to know the number of remaining certifications. We can see an event saying that there are 5 remaining certifications while there are actually less because an other certification expired in the same block.
So receiver_received_count is “after this expiration”, not “after this block”.
Oh: you mean the order matters for indexers for example?
1 Like
Yes. The order of the events should not matter but for this specific one, it does. That’s what’s counter-intuitive.
When creating an identity, a pending membership is not added immediately. It is only added when the target confirms his identity.
2 Likes