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?
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
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:
MembershipsExpireOnqui ne sert que à déclencher les expirations automatiquement.
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 :
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.
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.
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
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.
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.
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 :
Concernant l'expiration de l'adhésion, c'est plus compliqué :
Et pour les mécanismes de vérification, je pense qu'on pourrait fonctionner comme tu le suggères :
Donc :
claim UD, on ne peut pas réclamer au delà du champ
expire_on
IdtyStatus::Disabledou
IdtyStatus::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.
De plus, je me demande comment cela interfère avec la sous-toile forgeron.