Dans ce sujet, on discute de la stratégie à adopter concernant quand chiffrer les commentaires de transaction.
@kimamila propose une case à cocher pour laisser l’utilisateur choisir s’il veut chiffrer ou non son commentaire, j’y vois 3 inconvénients :
Cela complexifie l’UX, ça demande à l’utilisateur de faire un choix de plus, et plus il a de choix à faire, plus l’application va être difficile à utiliser. Si on veut des paiements Ğ1 simples et fluides, il faut simplifier au maximum l’UX, et donc ne solliciter l’utilisateur que pour des choix que l’on ne peut pas faire à sa place.
Cela permet aux utilisateurs d’inscrire facilement en blockchain n’importe-quel texte libre, or c’est pour empêcher cela que le chiffrement des commentaires a été remis sur le tapis lors de la réunion mensuelle de mai 2021.
L’argument principal de cette case à cocher est pour les services qui ont besoin de stocker des informations en clair dans le champ commentaire (exemple gannonce pour les crowfunding). Sauf que l’utilisateur lambda ne saura pas forcément que le commentaire doit être en clair dans ces cas particuliers, et risque par exemple de chiffrer les commentaires dont à besoin gannonce, produisant un dysfonctionnement du service.
La proposition de @vit , que je rejoins, c’est de déterminer automatiquement via des regex si le commentaire correspond à un format d’un service connu. J’y vois 4 avantages:
Une case à cocher en moins, l’utilisateur n’a pas besoin de réfléchir à la question, cela permet des paiements plus fluides (moins d’actions à faire par paiement).
Ça permet de standardiser le format des commentaires dédiés aux machines, c’est plus propre
Ça permet aux clients de savoir s’il est pertinent ou non d’afficher le commentaire dans l’historique (en n’affichant pas les commentaires dédiés aux machines).
Tout commentaire qui ne sert pas à un service (qui ne match aucune des regex), sera systématiquement chiffré, augmentant la confidentialité générale des données des utilisateurs (s’il y avait une case à cocher, plein d’utilisateurs ne la cocherait jamais, et le chiffrement aurait peu d’intérêt).
Reste à définir un format standard pour les services qui utilisent le champ commentaire.
Après réflexion, je me suis dit que pour afficher les références des transactions d’une clé publique, il faut s’authentifier. On était dans l’idée d’utiliser au minimum l’authentification surtout pour les clés créatrices. Sans authentification, les références ne seraient pas affichées. En cas de besoin d’afficher les commentaires, l’authentification deviendrait nécessaire.
Qu’entend tu pars « références des transactions d’une clé publique » ? Je ne comprends pas.
Oui évidemment, sans authentification les commentaires ne seraient pas affichés.
En termes d’UX, lorsque l’utilisateur clique (ou maintien le doigt) sur une transaction, on pourrait alors afficher en gris sous la ligne de transaction le label « commentaire chiffré » dans le cas où un commentaire est présent. Avec un petit i dans un rond (tooltip), qui indique qu’il faut s’authentifier pour déchiffrer le commentaire.
Est-il intéressant d’imposer l’hexadécimal, pourquoi ne pas faire plutôt [^:]+:[^:]+:.* ? Cela sert uniquement à harmoniser les moyens employés par les logiciels pour savoir si ils doivent s’intéresser ou non à une transaction, afin de faciliter leur mise en place et d’éviter les collisions. Je pense qu’il suffit d’imposer un format au préfixe.
Même quelque chose comme ça pourrait aller : ([^ :]+)[ :](.*)
je préfère une regex la plus restrictive possible pour éviter les faux positifs.
Le but est surtout de ne pas casser ğannonce, mais les nouveaux services en cours de développement devraient s’habituer à ne pas avoir besoin des commentaires, et plutôt à stocker hors-blockchain des annexes à une transaction.
Non, car il deviendrait trop facile de poster un texte libre dans la blockchain. Imposer l’hexadécimal à 3 avantages :
Ça permet de ne pas casser gannonce
Ça permet de ne pas confondre avec les commentaires chiffrés, qui eux sont en base64
Ça permet d’interdire l’écriture de textes littéraires, car on a que 6 lettres.
Avec l’hexadécimal tu peux déjà stocker plus de 100 octets dans la transaction, ça devrait être largement suffisant pour les usages d’une machine.
@tuxmain il est possible de stocker beaucoup d’octets libres dans une transaction sans passer par le champ commentaire, il suffit d’utiliser la fonction XHX.
Si au lieu d’envoyer des ğ1 à SIG(A), j’envoie des ğ1 à SIG(A) || XHX(32_BYTES_IN_HEX) || XHX(OTHER_32_BYTES_IN_HEX) etc. Je peux stocker jusqu’à 416 octets libres par output !!
Avec un max de 45 outputs, tu peux déjà stocker plusieurs Ko dans une transaction sans jamais passer par le champ commentaire.
Dans cette optique, je préfère que la regex utilisée serve que à ne pas casser les services existant en prod (Ganonnce, gchange, y en a-t-il d’autres ?).
Pour les services en développement actif (ğmixer, autres ?), passez plutôt par le champ XHX
Chaque fonction XHX permet de stocker 32 octets libres, comme SHA256 résiste à l’attaque de préimage, seule une signature de la clé publique A permet de dépenser les Ğ1
On parle ici uniquement des services dont le bon fonctionnement dépend de leur capacité à lire les commentaires des transactions. La barre de financements développée par @Paidge n’utilise pas les commentaires de transaction.
Pour ne pas casser gannonce et gchange je propose la regex suivante :
En fait c’était surtout une de mes propositions. J’avais pensé à cela en même temps que la case à cocher.
Donc aucun soucis pour le réaliser.
Par ailleurs gchange utilise aussi ce type commentaire structuré avec un code.
La forme est “GCHANGE:[a-zA-Z0-9-_]” (il me semble - je suis sur mon téléphone)
Donc ta regexp ne va pas.
Par ailleurs G1SMS utilise aussi des commentaires pour lier des comptes entre eux, en déclarant un gestionnaire : PROVIDER:pubkey (a vérifier @Frederic_Renault )
Je penses a utiliser cette dernière fonction pour lier un compte gchange a un compte de la WoT. Ainsi, on pourrait profiter de la WoT pour gagner en confiance dans gchange.
Alors vérifie ce qu’il en est dans le code de ğchange et indique nous la regex minimale dont à besoin ğchange pour fonctionner.
Pourquoi aurait tu besoin de passer par un commentaire de transaction pour cela ? Il suffit qu’une clé membre signe une clé gchange, la signature pouvant être stockée dans le profil ğchange.
Ce n’est pas une bonne habitude que d’utiliser les commentaires de transactions pour y stocker des données autres. Tu dis ne pas vouloir alourdir là blockchain mais c’est exactement ce que tu ferais si tu décidais d’utiliser les commentaires de transaction pour signer un compte ğchange.
Je te rappelle qu’on prévoit toujours la suppression du champ commentaire à moyen terme. Tous les services encore en cours de développement doivent prendre en compte cela en donc ne pas se baser sur les commentaires de transaction.
Le but de la regex à définir ici est uniquement de ne pas casser les services déjà en production et significativement utilisés qui dépendent des commentaires de transaction: donc gannonce et gchange.
Précise nous donc la regex minimale donc à besoin gchanqe pour fonctionner !
