Proposition de supprimer la notion d'identité désactivée mais non révoquée et la notion d'adhésion

Ces derniers temps j’ai travaillé à refactorer, simplifier et tester mon implémentation des règles de la toile de confiance Ğ1 dans substrate, et je me suis rendu compte qu’il me reste certaines couches de complexité qui me semble coûter trop cher vis-à-vis de ce que ça apporte à l’utilisateur.

Je pense que l’on peut apporter à l’utilisateur des bénéfices équivalent d’une autre façon de manière à ce que l’implémentation technique dans substrate soit bien plus simple.

De plus, la fonctionnalité en question, dans sa forme actuelle, n’apporte pas que des bénéfices à l’utilisateur, mais lui est parfois néfaste.

Je parle du fait que lorsqu’une identitée est «désactivée» (par expiration du membership ou expirations de certifications sous 5 certifications), elle n’est pas révoquée, et peut être « réactivée » par l’utilisateur via le renouvellement de son adhésion.

Cette « fonctionnalité » est horrible à gérer, elle complexifie grandement le nombre de scénarios possibles pour une identité (sortir et rerentrer dans la toile via plusieurs aller-retour), et est déroutante voir parfois néfaste pour l’utilisateur.

En effet, si un membre perd ses identifiants et n’a pas son document de révocation, il doit attendre la révocation implicite de son identité 1 an après l’expiration de son adhésion, ce qui est long et souvent mal compris.
Par incompréhension, certains utilisateurs re-certifie la personne sur une nouvelle identité dès que son adhésion a expirée, ce qui permettrait à une personne mal intentionnée de faire croire qu’elle à perdu ses identifiants puis de « réactiver » son ancienne identité.

Le seul « gain » de cette fonctionnalité complexe et mal comprise, c’est de pouvoir re-rentrer dans la toile après expiration sans avoir a re-obtenir toutes ces certifications, et que les certificateurs n’aient pas 2 certifications consommées dans leur stock pour un même être humain certifié.

Je propose de supprimer cet état « désactivé », ce qui signifie que l’identité sera automatiquement révoquée lors de son expiration.

La majeure partie des expirations sont dues à un simple oubli, on pourrait bien sur mettre en place les outils qu’il faut pour prévenir les utilisateurs en amont, mais j’ai une idée plus simple:

Supprimer purement et simplement le renouvellement de l’adhésion, ainsi l’utilisateur n’aura plus besoin d’y penser.

Je propose à la place de définir une durée maximale d’inactivité (par exemple 1an), qui est reconduite à chaque action en blockchain de la clé publique liée à l’identité concernée.

Chaque fois que vous ferez une action avec votre compte membre, même un simple transfert de monnaie, même une simple création du DU (puisque la création du DU va devenir manuelle) votre adhésion sera reconduite automatiquement pour 1 an.

Ainsi, l’expiration d’identité ne concernera que les humains n’ayant réellement et effectivement effectués aucune action avec leur compte membre depuis 1 an.

Si vous n’avez effectué aucune action sur votre compte membre depuis un an, pas même créer vos DU, c’est que vous avez quitté la monnaie, la révocation automatique me semble dont tout à fait acceptable dans ce contexte.

Et techniquement ce serait infiniment plus simple à gérer, en tout cas dans duniter-v2s.
Concrètement j’ai un champ last_action par identité. Et je rajoute dans un pre_dispatch (fonction customisable qui est appelée avant chaque extrinsic), 2 lignes de code :

Une qui récupère l’identité associée à la clé publique signataire de l’extrinsic
Une deuxième qui set le champ last_action de cette identité (si elle existe) à current_block_number.

Ça augmenterait légèrement le « poid » de chaque extrinsic (1 lecture + 1 écriture éventuelle), mais comme montré dans ce sujet, en dessous de 10 millions d’utilisateurs on est très large, et si on arrive jusque-là on aura développé des layer 2 entre-temps.

:arrow_lower_right:
En résumé:

  • L’identité est révoquée automatiquement dès que le compte membre est totalement inactif en blockchain depuis plus d’1 an.
  • L’utilisateur n’a plus à renouveler d’adhésion, en fait la notion d’adhésion n’existe même plus pour lui.

Avantages:

  • Si un utilisateur perd ses identifiants et n’a pas son document de révocation, il doit attendre maximum 1 an pour être recertifé sur un nouveau compte au lieu de 2 actuellement.
  • Plus besoin de rappeler aux gens qu’ils doivent renouveler leur adhésion.
  • Plus de notion d’adhésion, c’est plus simple à expliquer pour nous et plus simple à comprendre pour les utilisateurs.
  • Bien plus simple à implémenter techniquement, donc un code plus lisible, plus maintenable, et avec moins de bug.

Inconvénients:

  • Si un utilisateur n’effectue aucune action en blockchain avec son compte membre pendant 1 an, son identité est révoquée.
  • Si ces certificateurs veulent le recertifier et sur sa nouvelle identité et que les certifactions en question n’ont pas expiré au bout d’un an, pendant une certaine durée les certificateurs auront 2 certifications en moins dans leur stock de 100 certifications pour le même être humain.

Notez que : Les certifications émises et reçues par l’identité révoquée continuerait d’exister et d’être prises en compte dans la règle de distance (comme c’est déjà le cas actuellement).

10 « J'aime »

Je trouve même qu’un délai de 1 an après la dernière action est trop long. 6 mois sans rien faire avec son compte, c’est déjà long.

Par contre j’avais cru comprendre que la règle de distance était revérifié uniquement lors du renouvellement d’adhésion. Que c’était même une des fonctions du renouvellement d’adhésion. Du coup cette vérification, qui était gourmande en calcul d’après ce que j’avais compris, se ferait à quel moment ? À date anniversaire ?

2 « J'aime »

Bien vu, en effet s’il n’y a plus de renouvellement d’adhésion il nous faut décider autrement quand est-ce que la distance est réévaluée, ça peut effectivement être 1 fois par an à date d’anniversaire :slight_smile:

Je compte implémenter cette proposition dans dunites-v2s dès maintenant, car c’est structurant, plus tard je le fais plus ce sera difficile.
J’aimerais donc avoir le plus d’avis possibles, cc @Galuel @kimamila @poka @matograine @1000i100 et tous ceux qui souhaitent donner leur avis.

J’aimerais qu’on puisse prendre une décision lors de la visio de ce Dimanche 30 Janvier :slight_smile:

Ça me paraît très bien !

Il faut en effet dans ce cas décider le remplacement du recalcul des conditions de distance, et tous les ans à la date anniversaire me paraît bien aussi.

Je ne vois aucun blocage sur ce changement qui semble en effet n’apporter que des bénéfices.

3 « J'aime »

Pour ma part c’est le contraire : je fais un grand usage de comptes portefeuilles, et il m’arrive souvent de passer 3 à 6 mois sans faire d’actions depuis le compte lié à mon identité. Un an me semble court, j’aurais proposé 6 mois de plus. Mais ça c’est une constante, ça se change facilement, je suppose.


Sinon, je suis tout à fait favorable à cette proposition qui simplifie l’UX.

2 « J'aime »

Je suis aussi d’accord avec ce changement.
1 an roulant sans activité me paraît bien.

C’est plus simple à expliquer et ça responsabilise.

2 « J'aime »

Oui, on peut même passer à 2 ans roulant sans activité au lieu de 1 ça me va, ça se change en effet facilement.

Le seul « problème » avec une durée trop longue, c’est que ça fait plus de DU créé pour rien, mais comme il faut réclamer ses DU, et que c’est une action qui vaut renouvellement, on est certain que si une identité expire cela signifie qu’elle n’a réclamée aucun DU depuis 2 ans, il est donc tout à fait possible au niveau du protocole de « confisquer » 1 an de DU et de le reverser à une trésorerie commune par exemple :slight_smile:

Substrate fournie une pallet treasury qui permet de gérer une trésorerie commune en blockchain, c’est un compte avec une adresse comme les autres mais sans clé privée, il ne peut faire d’action que via une Origin configurable, ça me fait penser qu’il faut vraiment que je vous explique le mécanisme d’Origin, ça permet de mieux comprendre ce qu’on peut faire facilement ou non avec substrate.

1 « J'aime »

Je trouve l’idée intéressante que l’envoie d’un document quelconque d’une clé membre repousse l’exclusion automatique pour une durée d’un an. Ça suit moins le principe separation of concern, mais bon.

3 « J'aime »

Les inconvénients me semble négligeable, les avantages significatifs, je suis fortement pour !

2 réflexions cependant :

  • l’utilisateur n’a plus à se soucier d’identité parce que qu’il n’a plus à renouveler manuellement. Quid de la certification initiale par 5 certificateurs. On en avait discuté, mais j’en étais resté à une absence de décision. Qu’est-ce qui a été choisi de ce côté ?
  • Je viens de lire et réagir au topic Production du DU Si c’est la dernière activité du compte qui détermine si le compte conserve de droit de production de DU ou non, alors il me semble pertinent (notamment pour les usages tels que celui de @matograine ) que les clients implémentent :
    • un rappel de connexion au compte membre après 11 mois d’inactivité si ces clients ont moyen d’émettre un rappel (ça peut être d’indiquer dans un wallet d’usage courant le compte membre associé, pour que le client puisse alerter même sans email, lors d’une connexion au wallet)
    • l’émission d’un claim_uds même si ce n’est pas nécessaire à une transaction lors de la connexion à un compte producteur de DU qui n’en a pas réclamé depuis au moins 6 mois.

Je ne comprends pas à quoi tu fais allusion, peut tu préciser ?

Oui voir après 9 mois, ou même que se soit un paramètre réglable par l’utilisateur, et désactivable, perso j’aime bien pouvoir configurer mes notifications. Je n’aime pas quand un logiciel m’impose des notifications que je ne peux pas paramétrer.

Si un compte membre fait un transfert de Ğ1, cela vaudra déjà renouvellement, même si ce n’est pas une opération de type « wot », donc pas besoin de claim des DU inutilement (et accessoirement de payer des frais ou des quotas pour rien).

Même pas une petite certification, voir un renouvellement de certification ?
Je me dis que réduire ce délai, permet d’avoir moins de comptes fantômes, des comptes membres qui ne sont plus utilisés.
Mais est-ce vraiment grave ? Peut-être pour celui qui a mal noté ses identifiants et mot de passe. Mais j’ai cru comprendre que ce système d’authentification allait changer.
Alors je ne sais pas trop en fait.

Peut-être que je me mélange les pinceaux entre document de demande à devenir membre permettant de recevoir des certifications actuellement, et document d’identité, et champ UserID.

11 mois, 9 mois, pas du tout… au choix de l’utilisateur, ça me parle, tant que le réglage par défaut facilite la vie à l’usager :wink:

J’ai bien compris. Le scénario que je décris, c’est celui d’un compte producteur de DU qui n’a aucune activité, ni besoin de transfert, mais auquel l’utilisateur se connecte suite par exemple à une notification l’invitant à ne pas laisser son compte être révoqué. Du coup, lors de sa connexion, il pourrait effectivement faire un transfert manuel pour avoir une activité on-chain, ou avoir un bouton pour déclencher manuellement claim_uds mais ça peut aussi être son client qui observe l’absence d’activité depuis longtemps et le fait d’être authentifié avec la clef privée permettant de faire le claim, et qui donc le déclenche, non pas quotidiennement, mais quand la prochaine connexion risquerais d’être après révocation du compte. Mais bref, c’est une question d’UX et pas de protocole, on pourra affiner ailleurs au besoin :wink:

C’est un autre sujet, et de toute façon ce n’est pas géré par duniter-v2s mais exclusivement par les wallet (ce qu’on appelait client avant).
Je préconise que les wallet fassent comme toutes les autres crypto et comme Ğecko: une phrase de restauration que l’on ne saisit que lors d’un changement d’appareil, stockée en local chiffré par un mot de passe où un « code pin », si tu veux plus de détails cherche sur ce forum les termes « mnemonic » / « phrase de restauration » / « phrase de récupération ».

Il me semble que le UserID n’est pas impacté par l’application ou la non-application de cette proposition. Quant à la demande d’adhésion, elle n’existera plus également, il faut en effet que je fasse un sujet dédié à la création de l’identité.

Je pense que pour ça il faut que l’on crée un nouvel extrinsic nommé identity.touch() et qui ne fait rien, ça permettrait de consommer moins de poids.
C’est le même principe que de « toucher » un fichier juste pour mettre à jour sa date de dernière modification.

2 « J'aime »

C’est plutôt ici que j’aurais du posé la question.
Que se passe-t-il quand l’utilisateur ne respecte plus la règle de distance ou n’a plus ses 5 certifications ?
La perte de certifications est facile à prévoir, mais la perte de la distance me semble plus difficile à prévoir.

2 « J'aime »

Son identité est révoquée.

On sait quand la distance est calculée onchain, elle peut être précalculée avant pour savoir su on est toujours bon, ça peut mettre être une méthode RPC de Duniter-v2s qui propose de faire le calcul en dry run, mais cette méthode demandant beaucoup de calcul elle serait privée.

Il suffirait alors de développer un service qui requête un nœud duniter-v2s avec API RPC privée à fréquence régulière (par exemple toutes les 24h), pour évaluer la distance de toutes les identités qui vont être évalués dans les X jours, et de publier les résultats sur urne page web et via une API, afin que les wallet qui le souhaite puisse s’en servir pour notifier leurs utilisateurs qu’ils ont besoin de plus de certifications.

Concernant la « perte » du respect de la règle de distance.
Rien ne nous oblige à retirer l’identité dès qu’elle ne respecte plus la règle de distance.

On peut réévaluer l’identité 1 mois après l’échec, et ne retirer l’identité que si la réévaluation échoue 3 fois de suite. Ce qui laisserait à l’utilisateur concerné un délai de 2 mois pour obtenir de nouvelles certifications lui permettant de respecter à nouveau la règle de distance.

Ce que je veux dire c’est que des aménagements sont possibles pour limiter les inconvénients de ma proposition, sans sacrifier son avantage central, sa raison d’être même, le fait qu’une identité expulsée ne puisse pas rerentrer, ce qui équivaut à dire que le retrait du droit au DU et la révocation doivent aller de pair.

3 « J'aime »

Je découvre cette proposition que tu fais @elois.

J’ai plusieurs remarques qui me viennent :

  • si le renouvellement devient automatique, et coûte (même un peu) à chaque action (DU, certification, ou transfert) lancée par un client : n’est-il pas équivalent pour l’utilisateur (et moins coûteux pour le noeud) que le client envoi automatiquement l’extrinsic d’adhésion ?
  • quelle différence pour l’utilisateur, donc, si c’est le client qui décide d’envoyer un renouvellement de manière automatique ? Par exemple des qu’on lui demande une action.
    En réalité, on peut très bien faire cela des aujourd’hui, avec Duniter v1. Il suffira d’ajouter une option « renouvellement automatique » (a oui par défaut) dans les clients…

L’avantage d’avoir un extrinsic d’adhésion est :

  • de ne pas avoir à gérer de champ last_action sur le noeud
  • de lancer la règle de distance quand on reçoit l’adhésion
  • l’utilisateur peut avoir la perception d’un renouvellement automatique, même si en réalité le client l’envoi dès sa première action
  • si l’utilisateur se connecte sans faire d’action, alors le renouvellement peut quand même être réalisé (en lui demandant ou pas).

Ce dernier point me semble important.

Bref, le fait d’être automatique ou non est un faux problème, à mon humble avis…

2 « J'aime »

Il ne peut pas être réalisé sans accéder aux clés privées, ce qui ne devrait jamais pouvoir être fait sans autorisation explicite de l’utilisateur.

À vrai dire ça m’est égal, car ce n’estp as ma proposition, mais une mesure de compensation pour rendre plus confortable pour l’utilisateur les conséquences de ma proposition.

Ma proposition consiste à supprimer l’état intermédiaire désactivé des identités, plus précisément à supprimer le hait qu’une identité puisse re-rentrer dans la wot après en être sortie, c’est de ça dont j’ai besoin pour pouvoir simplifier considérablement l’implémentation, et qui a été acté en réunion mensuelle.

Dans un premier temps je vais garder le renouvellement explicite puis nous en rediscuteront, en revanche je vais implémenter sans attendre le cœur de ma proposition (supprimer l’état intermédiaire).