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

Protocols Ğ1v2 protocol
8

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.

2 Likes
9

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 Likes
10

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.
11

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).

12

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.

13

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:

14

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”.

15

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.

3 Likes
16

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.

3 Likes
17

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.

18

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 Likes
19

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…

4 Likes
20

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).

21

If the idea of membership (and losing it) is to discourage bot use. Then tying it to a blockchain action removes this barrier as they could just automate an on-chain action.

What do you think of this?

22

Effectivement. Dans ce cas il faut demander une authentification, pour pouvoir faire le renouvellement.
En revanche, dans le cas d’une autre action qui nécessite déjà une authentification, nous pourrions le faire automatiquement. Ce qui serait exactement équivalent à ce que tu proposes.

Mais ôtes moi d’un doute : pour demander ses DU, l’utilisateur devra t il signer l’extrinsic avec sa clef publique ?

23

À condition de créer un extrinsic qui call utility.batch pour fusionner les 2 call dans un seul extrinsic oui, sinon ça ferait payer de fois les frais de base d’un extrinsic.

Tout extrinsic doit être signé avec la clé privée de l’emetteur.

24

oui ou alors on peut simplement ajouté une option dans l’extrinsic de récupération des DU ?
Ca me parait propre et assez logique non ?

25

Non avec substrate c’est un mauvais design que d’avoir une option pour faire un autre call que l’utilisateur peut déjà faire directement, car ça complexifie fortement l’étalonnage des poids du call, et augmente le poid du “pire scénario”, or c’est ce dernier qui est utilisé pour savoir si on a de la place dans le bloc et si l’utilisateur à de quoi payer les frais ou/et suffisamment de quota.
Il y a un ajustement après l’exécution du call, mais si l’utilisateur n’a pas de quoi payer les frais (ou pas suffisamment de quotas) pour le pire scénario, l’extrinsic sera rejeté, même si l’utilisateur à suffisamment pour ce qu’aurait coûté réellement l’exécution.

Il est donc important que le “pire scénario” d’un call ne soit pas trop éloigné du scénario moyen, pour cela il faut que le call fasse à peu près les mêmes traitements quels que soient les paramètres d’entrée.
Bref, c’est plus propre de soumettre un batch de plusieurs call, le call utility.batch est fait pour ça :slight_smile:

1 Like
26

ah oui je comprend le truc.

27

En vrai j’ai déjà un champ expire_on par utilisateur pour gérer l’expiration du membership, donc avec ou sans renouvellement automatique c’est pareil niveau champs à stocker onchain.

En plus, je viens de trouver un moyen de gérer ce “renouvellement automatique” sans surcoût: customiser les AccountData.

Plus je travaille sur substrate, plus je me rends compte qu’il est encore plus customisable que je ne le pensais jusqu’alors, on peut aller jusqu’à customiser la définition d’un compte, et le stockage des données d’un compte dans la pallet system.

La pallet system à une notion de compte, qui stocke notamment le nonce du compte (indispensable pour empêche les attaques par rejeu), le solde du compte, et quelques autres informations que je ne vais pas expliquer là pour rester simple.

Au début de chaque exécution d’un extrinsic, l’item AccountData est lu (pour vérifier le nonce), puis écris (pour incrémenter le nonce).

Il est possible d’ajouter d’autres données à côté de ce nonce, qui peuvent être écrites en même temps que ce dernier, ainsi pas d’écriture supplémentaire, donc le même poids (même temps d’exécution).

Il est donc possible de gérer le “renouvellement automatique” sans aucun sur-coût pour le poids de base d’un extrinsic.
Je vais donc le faire, enfin plus précisément ce n’est pas que le renouvellement sera “automatique”, c’est qu’il n’y aura plus de renouvellement.

Si une identité est inactive depuis plus de X blocs, n’importe qui pourra soumettre un extrinsic permettant de supprimer cette identité.

Dans la pratique, un seul extrinsic permettra de supprimer un groupe d’identités, et c’est un bot qui l’appellera.

Il y a déjà d’autres extrinsic de nettoyage manuel, c’est une bonne pratique de faire ainsi pour 2 raisons:

  1. Ça évite de stocker onchain les données nécessaires pour “détecter” quand est-ce qu’il faut nettoyer des données. Actuellement j’ai un item MembershipsExpireOn qui ne sert que à déclencher les expirations automatiquement.
  2. Ça rend manuel les traitements qui vérifient si une donnée peut être supprimée et qui la supprime, or il est préférable de maximiser les traitements manuels et de minimiser les traitements automatiques, car personne ne paye pour les traitements automatiques, et ils ne s’étalent pas sur plusieurs blocs (sauf à coder explicitement un tel comportement, ce qui est complexe à implémenter).
1 Like