Suite aux discussions essentiellement sur À quoi servent les pending membership?, mais aussi sur Résistance au changement, la nuit porte conseil et ailleurs, tout montre que séparer le concept d’adhésion et d’identité apporte peu d’intérêt par rapport à la complexité d’une pallet supplémentaire. L’idée a mis du temps à mûrir dans ma tête, et voici ce que j’ai actuellement :
voilà ldtyValue actuellement
/// identity value (as in key/value)
#[derive(Serialize, Deserialize, Debug, Encode, Decode, Clone, PartialEq, Eq, TypeInfo)]
pub struct IdtyValue<BlockNumber, AccountId, IdtyData> {
/// data shared between pallets defined by runtime
/// only contains first_eligible_ud in our case
pub data: IdtyData,
/// block before which creating a new identity is not allowed
pub next_creatable_identity_on: BlockNumber,
/// previous owner key of this identity (optional)
pub old_owner_key: Option<(AccountId, BlockNumber)>,
/// current owner key of this identity
pub owner_key: AccountId,
/// next action scheduled on identity
// 0 if no action scheduled
pub next_scheduled: BlockNumber,
/// current status of the identity (until validation)
pub status: IdtyStatus,
}
et l’enum status qui est dedans
pub enum IdtyStatus {
/// created through a first certification but unconfirmed
#[default]
Unconfirmed,
/// confirmed by key owner with a name published but unvalidated
Unvalidated,
/// member of the main web of trust
// (there must be a membership in membership pallet storage)
Member,
/// not member of the main web of trust, auto-revocation planned
NotMember,
/// revoked manually or automatically, deletion possible
Revoked,
}
Cette situation actuelle représente mal la donnée :
- lorsque le status est
Member,next_scheduledvaut0et la pallet membership contient un équivalent “MembershipsExpireOn” - lorsque le status est
Revoked, next_scheduled vaut0 IdtyDatacontient toujours une donnéefirst_eligible_udde la pallet universal_dividend qui n’a de sens que quand status vautMemberold_owner_keyn’a de raison d’être que pour statusMemberouNotMembernext_creatable_identity_onn’a de sens que si l’on souhaite avoir un délai de création d’identité strictement supérieur au délai de certification et lorsque status estMember- …
bref, vous voyez sûrement où je veux en venir : IdtyValue ne devrait pas être un struct qui contient status, mais plutôt directement cette enum, ce qui donnerait quelque chose comme:
pub enum Identity {
/// created through a first certification but unconfirmed
Unconfirmed {
owner_key: AccountId,
expire_on: BlockNumber,
},
/// confirmed by key owner with a name published but unvalidated
Unvalidated {
owner_key: AccountId,
expire_on: BlockNumber,
}
/// member of the main web of trust
Member {
owner_key: AccountId,
old_old_owner_key: AccountId,
expire_on: BlockNumber,
},
/// not member of the main web of trust, auto-revocation planned
WasMember {
owner_key: AccountId,
old_old_owner_key: AccountId,
revokes_on: BlockNumber,
},
/// revoked manually or automatically, deletion possible
Revoked {
deletes_on: BlockNumber,
},
}
On pourrait également mettre first_eligible_ud dans la variante Member, mais ça me semble moins bien que de déplacer cette information dans une map idty_index → first_eligible_ud dans la pallet universal dividend, et de gérer les auto-claim et init avec un handler de MembershipRemoved et MembershipAdded.
Cela mènerait à fusionner IdentityChangeSchedule et MembershipsExpireOn qui sont à peu près la même chose, c’est-à-dire un scheduler qui force à avancer d’un état dans la machine à état :
