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?
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 ?
À 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.
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 ?
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 
1 Like
ah oui je comprend le truc.
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:
- Ç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
MembershipsExpireOnqui ne sert que à déclencher les expirations automatiquement. - Ç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
Du coup, si je comprends bien, si on perds son statut de membre par l’expiration d’une certification ou par la règle de distance, le compte sera révoqué sans possibilité de le réactiver?
Ce qui me gêne le plus c’est l’impossibilité de le réactiver, car il peut arriver pour des raisons légitimes qu’un compte soit inactif. Que ce soit un voyage à l’autre bout du monde, le passage par la case prison, un simple oubli car les années passent vite, …
Du coup, est-ce que :
- il sera toujours possible d’utiliser le compte comme simple portefeuille ?
- il sera possible de réutiliser son pseudo public sur la toile de confiance ? Car bien souvent c’est ce pseudo qui est utilisé par les autres membres pour authentifier certainement un utilisateur.
Oublier de se refaire certifier et utiliser son certificat de révocation sont deux actions avec une portée bien différente tout de même.
2 Likes
Du coup, en épluchant les autres threads il s’avère que le pseudo sera peut être supprimé, et même … si une fois l’identité révoquée, l’identité disparaît entièrement de la blockchain, alors le pseudo qui fut utilisé devient à nouveau disponible.
Donc si jamais, mon identité expire, je pourrai en recréer une avec le même pseudo (si ils restent) et me refaire certifier avec le même compte portefeuille. Du coup, plus de problème.
Par contre, dans ce cas, on perd une qualité importante du pseudo : c’est qu’il permet d’identifier de manière sûre une personne dans le temps. Je sais que 100 ans après, le pseudo correspond toujours à la même identité, même si la personne est morte.
1 Like
Oui
Tout dépend pendant combien de temps on garde de pseudo révoqué (où son hash) dans le storage on-chain.
J’ai l’impression que le problème de fonds c’est de considérer que le pseudo peut être un élément d’identification/authentification.
Je pense que l’identification/authentification d’un compte ne doit pas se baser sur le pseudo. Je propose à la place qu’elle se base sur un random id (enfin sur des identicones dérivées déterministes de ce random id).
J’aimerais également que l’on ne garantisse plus l’unicité du pseudo, car c’est la seule raison qui oblige à stocker son hash on-chain dans duniter-v2s.
Ça permettrait aux utilisateurs de prendre le pseudo qu’ils veulent dans tous les cas, et de prendre conscience que ce n’est qu’un pseudo, dont la valeur n’est pas “fiable”.
Dans tout le cas, avant de certifier quelqu’un il reste nécessaire de vérifier sa clé publique, que la personne doit vous avoir communiquée personnellement par un autre canal que Cesium
3 Likes
Pour le moment, en ayant conscience de la notion d’unicité du pseudo, je l’utilise pour authentifier le compte destinataire de mes virements par exemple, et j’ai l’impression que dans la vraie vie, en tout cas avec les autres Ğunistes que je fréquente, c’est également comme ça qu’ils l’utilisent. Il me semble que c’était une décision de design de Duniter-v1.
Sinon, quel intérêt au pseudo, parce qu’on a déjà le nom de la personne dans Cesium+, qui est souvent plus pertinent car il est souvent moins farfelu et correspond plus a l’identité physique de la personne.
Changer la sémantique du pseudo, si on le fait, devra s’accompagner d’un gros message en rouge (attention, information non sécurisée). et d’un point de vue UX, il ne faudrait plus l’inclure dans les applications de portefeuille, je pense, du moins dans la partie virement et recherche de membre en vue d’un virement ou d’une signature.
1 Like
Es-tu toujours de cet avis ?
Tant qu’on n’a pas de système de données à consensus global (donc branché sur la blockchain), je suis d’avis de conserver l’unicité du pseudo comme @mildred. C’est, je pense, un des choix de conception qui rendent Duniter v1 accessible au grand public.
J’en sais rien faites comme vous voulez. L’implémentation actuelle de duniter-v2s maintien l’unicité du nom d’utilisateur en blockchain pour le moment.
2 Likes
J’ai absolument besoin de mettre au clair ce point car comme tu le dis :
Actuellement, l’item MembershipsExpireOn est toujours présent, ainsi que PendingMembershipsExpireOn, StorageCertsRemovableOn…
Mon avis à ce sujet est le suivant :
- ça me paraît une bonne chose d’avoir le minimum de traitements automatiques en blockchain, mais juste de quoi vérifier si un traitement automatique soumis via un extrinsic est valide ou non du moment que ça n’entraîne pas d’effets de bord
- il faut cependant comprendre que si une donnée est disponible à un bloc, ça peut être tout simplement qu’elle n’a pas encore été supprimée
- il faut être certain de mettre en place et “financer” (au moins payer les frais) de ces traitements automatiques sous peine de voir le storage augmenter de manière indésirable
Concernant l’expiration de l’adhésion, c’est plus compliqué :
- l’inactivité d’un compte peut être interprétée de différentes manières :
- son propriétaire est mort → fin rapide de production du DU nécessaire
- son propriétaire est désintéressé de la Ğ1 → fin de production du DU sans trop tarder souhaitée
- son propriétaire pense avoir perdu ses identifiants et voudrait repartir de zéro → révocation définitive du compte pour le verrouiller au cas où il retrouverait ses identifiants nécessaire (un document de révocation peut aider)
- la perte du respect de règle de distance peut également avoir plusieurs causes :
- une incompréhension de la nécessité de renouveler les certifications, (règle compliquée à comprendre)
- un changement de topologie du reste de la toile, par exemple liée à des conflits géopolitiques
- → pour moi elle ne devrait pas aboutir à une révocation trop rapide
- l’expiration de certification aboutissant à passer sous le seuil
- la personne n’a plus d’activité, on est ramené au premier cas
- → je pense qu’il faut quand même lui laisser un délai avant de perdre son identité
Et pour les mécanismes de vérification, je pense qu’on pourrait fonctionner comme tu le suggères :
Donc :
- au moment de
claim UD, on ne peut pas réclamer au delà du champexpire_on - au moment de certifier, on ne peut pas le faire si la dernière évaluation de la règle de distance est ko.
- il n’y a pas de status
IdtyStatus::DisabledouIdtyStatus::Revokedni de programmation du changement de statut.
Je ne suis pas sûr d’avoir compris toutes les conséquences, rien de ce que je dis n’est définitif.
1 Like
De plus, je me demande comment cela interfère avec la sous-toile forgeron.
Je suis encore en train de potasser ce problème…
@tuxmain tu peux me rappeler quelle est la stratégie actuelle ([edit] v2) de réévaluation de la règle de distance ?
Si tu parles de V2, il n’y en a pas encore.
Sinon, je ne sais plus… ce doit être au renouvellement de l’adhésion ?
1 Like
J’ai (enfin) une proposition concrète :
- quand une adhésion expire, l’identité n’est pas supprimée, et une “pending membership” est ajoutée
- quand une “pending membership” expire, l’identité est alors supprimée
Cela a l’avantage d’être très simple à implémenter parce que les pending membership sont déjà là, et il me semble que ça répond aux discussions précédentes.
Donc pour résumer :
- validité d’une “pending membership” = 1 mois
- validité d’une adhésion = 1 an
- quand l’adhésion expire, il reste 1 mois avant que l’identité soit supprimée
- pendant cette période, si les conditions sont remplies pour pouvoir “claim membership” (nombre de certifs reçues, règle de distance), l’identité peut redevenir membre
Et ça marche pareil pour les adhésions forgeron, avec d’autres valeurs si on veut. (seul problème les metadata des pending membership, mais il faudrait les virer de toute façon).
7 Likes
Ca me parait à la fois simple et efficace ! Bravo !
1 Like
À la fois ? C’est implémenté dans la MR !166, à voir ce que ça donne. Vous pouvez par exemple lire ce scénario de test pour voir comment ça fonctionne pour le DU.