Adhésion automatique après évaluation de la distance

Protocols Ğ1v2 protocol
1

[petit résumé pour le contexte, la plupart se trouve dans le sujet Distance]

Après avoir mis en place l’oracle de distance sur le réseau ĞDev, on s’est rendu compte que le calcul de la distance s’intégrait mal dans le processus actuel. En effet, il n’était plus possible de valider directement l’identité cible à la 5ème certification (validate_identity), il fallait que la nouvelle identité demande l’évaluation de sa distance, qu’elle attende deux sessions, et qu’elle appelle claim_membership dans la période de validité de l’évaluation : un vrai parcours du combattant !
Comme quoi, il ne suffit pas que ça marche sans bug, il faut en plus que ce soit simple pour l’utilisateur :smiley:

Mais depuis (cf suivi du projet n°3 pour plus de détails) :

  • la pallet membership a été revue (!215) faisant disparaître le call validate_identity
  • la pallet smith-members va faire son apparition (!217) simplifiant beaucoup le concept d’adhésion car il n’aura plus à satisfaire à la fois aux adhésions normales et aux adhésions forgeron
  • les adhésion vont être automatiquement déclenchées après une évaluation positive de la distance (!219)

Je vais décrire ici le nouveau fonctionnement et les questions que ça pose.

Scénarios

1. pour une nouvelle identité

  1. créer l’identité pour une clé publique, ce qui lui donne un idty_index IdtyStatus::Unconfirmed
  2. confirmer l’identité pour lui donner un nom IdtyStatus::Unvalidated
  3. donner les certification manquantes
  4. demande l’évaluation de la règle de distance : cela peut être fait depuis n’importe quelle identité membre uniquement vers une identité non validée ou depuis l’identité elle même, à condition d’avoir assez de fonds à réserver pour la demande
    • request_distance_evaluation → pour soi-même
    • request_distance_evaluation_for pour quelqu’un d’autre (uniquement si la caller est IdtyStatus::Member et le destinataire est IdtyStatus::Unvalidated)
  5. après deux sessions, si l’évaluation est positive, try_add_membership est appelé automatiquement, ce qui valide l’identité (IdtyStatus::Member), sinon, le demandeur est slashé du montant réservé

2. pour un renouvellement d’identité

  1. demander l’évaluation de la distance pour soi-même request_distance_evaluation
  2. après deux sessions, si l’identité est IdtyStatus::Member, l’adhésion est renouvelée (try_renew_membership)

3. pour redevenir membre après une adhésion perdue

  1. demander l’évaluation de la distance pour soi-même request_distance_evaluation
  2. après deux sessions, si l’identité est IdtyStatus::NotMember, l’adhésion est réajoutée (try_add_membership)

try_{add,renew}_membership peut échouer par exemple si une certification a été perdue entre temps

Conséquences / questions

  • il n’y a plus besoin de call claim_membership, la bonne manière de faire est de demander l’évaluation de la règle de distance, ensuite tout est automatique
  • il faut réfléchir à un mécanisme antispam pour la demande de calcul (#113) car on pose une limite sur le nombre d’évaluations par session MAX_EVALUATIONS_PER_SESSION → De quel mécanisme antispam a-t-on besoin pour l'évaluation de la règle de distance?
  • souhaite-t-on distinguer les événements add / renew comme pour cert (CertAdded / CertRenewed) ? pour l’instant il n’y a que MembershipAdded, cf API des événements
  • il n’y a plus besoin de conserver le résultat du calcul de distance en mémoire car le seul moment où il est utilisé est à sa publication
2 Likes
2

Ah bah je trouve ça vachement plus simple :slight_smile: cool que le processus se simplifie autant, je trouve que c’est très lisible pour tout le monde, il faut :

  1. être parrainé par un membre
  2. indiquer son pseudo
  3. recevoir les certifications
  4. passer la règle de distance

Et renouveler les étapes 3 et 4 autant de fois que nécessaire pour devenir et rester membre.

Pourquoi cette contrainte sur le fait d’être membre ?

J’imagine que les deux call request_distance_evaluation requièrent que l’identité à reçu assez de certification, n’est-ce pas ?

Super :slight_smile: encore une belle simplification.

2 Likes
3

Ne serait-ce pas plutôt IdtyStatus::Unvalidated quand l’utilisateur a confirmé son identité en lui donnant un nom.

1 Like
4

Cette contrainte n’est pas strictement nécessaire, en effet. Mais il y a un scénario d’attaque un peu fourbe :

  • une identité a 5 certifications mais ne respecte pas la règle de distance
  • une personne malveillante pourrait déclencher l’évaluation de la règle de distance “trop tôt”, ce qui empêcherait de la réévaluer avant le délai de 2 sessions, ce qui empêcherait un sixième certificateur d’appeler dans un batch la certification et la demande d’évaluation

Ça ne retarde l’entrée “que” de 2 sessions, mais donner ce pouvoir à un anonyme ne me paraît pas souhaitable.

Oui, dans les deux cas on appelle check_request_distance_evaluation_common qui vérifie :

  • qu’il n’y a pas d’évaluation en cours
  • qu’il n’y a pas de statut valide en cours (ce point va dégager)
  • le délai de renouvellement
  • le nombre de certifications

Mais il y aurait peut-être moyen de refactorer avec check_idty_allowed_to_claim_membership pour éviter d’avoir deux fois le même code.

C’est fou ce que c’est long d’arriver à une solution simple !

Bien vu, c’est corrigé ! :star_struck:

5

Ah bah ça va simplifier le workflow côté client c’est clair :slight_smile:

puis:

Donc du coup est-ce que quelqu’un d’autre peu relancer mon renouvellement d’identité après ma mort avec request_distance_evaluation_for ?

1 Like
6

Le seul cas où on peut lancer pour qqun d’autre c’est s’il est Unvalidated, alors que après ta mort tu est juste NotMember puis Revoked. Donc non, pas de zombies :zombie:

1 Like
7

Parfait. Ce serait utile de décrire de manière exhaustive les différents nouveau status du coup, soit dans ton post ici dans scénarios, soit ailleurs sur site web je ne sais pas.
Genre dans quels cas peut ont peut être NotMember, quand est-ce qu’on passe Revoked. Par defaut un simple wallet à un status IdtyStatus::None ou juste rien ? Ce genre de choses :slight_smile:

Aussi je me demande si ce ne serait pas utile d’avoir un extrinsic qui ne fasse que évaluer la règle de distance et retourner le résultat, sans tenter de valider l’identité, ou bien si l’oracle de distance aura une API public pour ça, ou bien qu’on se dise non il faut un autre outil externe genre wotwizard pour faire ça.

8

Oui, il faudra documenter, en attendant il y a les commentaires du code

/// status of the identity
// this is a kind of index to tell the state of the identity
#[cfg_attr(feature = "std", derive(Deserialize, Serialize))]
#[derive(Encode, Decode, Default, Clone, Copy, PartialEq, Eq, RuntimeDebug, TypeInfo)]
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,
}

Il faudra qu’on fasse un outil externe pour ça, qui peut utiliser le code de distance-oracle. Un cron qui évalue pour toute la toile tous les jours et sert le résultat hyper simplement avec une API json par exemple. Mais pour l’instant on peut juste faire un batch à la cinquième certification et on ajoutera le check informé ensuite.

2 Likes
9

Pour moi c’est nécessaire à l’antispam, puisque les frais ne peuvent remplir ce rôle ici. Sinon on peut relancer l’évaluation à chaque cycle sans qu’il soit possible de l’empêcher. Si on peut identifier le demandeur, il est possible de lui appliquer un délai.

1 Like