Voyant sur le forum monnaie-libre que @elois aussi souhaiterait simplifier la machine à état des identités, je me permet de lancer les réflexions.
Pour rappel, historiquement, on a voulu représenter dans cette machine à état toute la complexité d’une adhésion “humaine” à une communauté. C’est à dire :
La personne se fait connaitre (publication de l’identité)
La personne déclare demander à adhérer (publication d’adhésion)
La personne se fait certifier
La personne souhaite quitter la communauté (publication d’une sortie de l’adhésion)
La personne souhaite révoquer son identité (révocation de l’identité)
La personne renouvelle son adhésion (renouvellement)
La personne abandonne son identité (non renouvellement)
La personne a disparue et on considère son identité exclue (non renouvellement au bout de 2 ans)
Aujourd’hui, a priori la machine à état est la suivante :
@startuml
[*] --> UIDPublished
UIDPublished --> [*]
UIDPublished --> UIDIsRevoked : UID is revoked
UIDPublished -> NotAMember
NotAMember : Awaits5Certs
NotAMember : SendsMembership
NotAMember --> UIDIsRevoked : UID is revoked
NotAMember -> MembershipSent
MembershipSent : Awaits5Certs
MembershipSent --> [*]
MembershipSent --> UIDIsRevoked : UID is revoked
MembershipSent -> IsMember : Got 5 certs
IsMember : Has To renew before 1 year
IsMember : UIDIsWritten
IsMember -> NoMoreMember : Does not renew
IsMember -> NoMoreMember : Leaving
IsMember -> NoMoreMember : Missing 5 certs
IsMember --> UIDIsRevoked : UID is revoked
NoMoreMember : Has to renew before 2 year
NoMoreMember --> UIDIsRevoked : UID is revoked
NoMoreMember --> UIDIsRevoked : Does not renew before 2 years
@enduml
Avec le recul, on voit que cette machine à état est trop complexe et aboutit à :
Des interfaces logicielles compliquées
Une compréhension du fonctionnement de l’adhésion laborieux à expliquer et à comprendre
Je pense qu’on pourrait aboutir aux mêmes fonctionnalités utilisateurs, en simplifiant a minima l’adhésion. L’utilisateur ne verrait quasiment pas la différence, tandis que cette simplification stabiliserait les logiciels et rendrait les interfaces plus claires :
@startuml
[*] --> UIDPublished
UIDPublished --> [*]
UIDPublished --> UIDIsRevoked : UID is revoked
UIDPublished : Awaits5Certs
UIDPublished -> IsMember : Got 5 certs
IsMember : Has To renew before 1 year
IsMember : UIDIsWritten
IsMember -> NoMoreMember : Does not renew
IsMember -> NoMoreMember : Missing 5 certs
IsMember --> UIDIsRevoked : UID is revoked
NoMoreMember : Has to renew before 2 year
NoMoreMember --> UIDIsRevoked : UID is revoked
NoMoreMember --> UIDIsRevoked : Does not renew before 2 years
@enduml
Le membership leave ne sert effectivement à rien dans les faits, la révocation ayant un effet immédiat.
Pour l’adhésion initiale, c’était plutôt une protection supplémentaire pour l’utilisateur : en cas d’erreur, malgré les certifications reçues, le propritétaire de l’identité aurait encore une chance d’empêcher son identité d’être inscrite en blockchain sans son consentement. C’est une sorte de double validation.
Il est possible de retirer cette partie si dans les faits les utilisateurs considèrent qu’à partir du moment où leur identité est créée c’est que déjà qu’ils veulent entrer, et qu’au pire des cas cela ne les gêne pas d’effectuer une révocation après coup.
Ben je pense que moins on fait de changement de protocole plus ce sera simple a implémenter, donc je préconise dans un 1er temps de supprimer l’état “exclu” pour le remplacer par révoqué, point. C’est facile a coder et ça simplifiera déjà énormément de choses
Non je veut garder le Membership, et tout les documents actuels en fait. Juste supprimer le statut “exclu”. Ce qui veut dire qu’il n’y aura plus que 3 statuts :
Ok. Je ne sais pas encore quoi en penser, mais je suis d’accord avec le principe énoncé plus haut “moins on fait de changements et plus ce sera simple à implémenter”. Surtout concernant Duniter TypeScript
C’est pas forcément la partie la plus complexe du protocole à vrai dire. C’est d’ailleurs la seule partie qui me semblait avoir un sens (la seule où on perdait vraiment quelque chose avec le modèle que je proposais).
En effet, cette partie permet à ceux qui oublient de renouveler de juste avoir à renouveler, et non à recréer une identité à zéro.
Du coup je suis un peu perplexe, parce que ça ne simplifie presque rien par rapport aux problèmes que j’évoquais (la complexité des interfaces et la complexité des explications aux utilisateurs)
J’ai modifié le post pour parler d’identité plutôt que de compte, puisque le compte associé à l’identité est toujours accessible si on a les identifiants.
Le statut “exclu” n’apparaît pas dans le schéma UML. Il faudrait l’ajouter s’il est l’enjeu d’un débat et peut être amené à disparaître.
Pour le coup NoMoreMember me semble beaucoup plus parlant (ou NotMemberAnymore) si il s’agit d’un statut perdu, c’est pour que je demandais comment peut on obtenir le statut NotMember.
