Format du UserID

Suit au sujet Supression du UserID?, je souhaite relancer la discussion sur le format du UserID.

Actuellement dans Duniter v1 : app/lib/common-libs/constants.ts · e6505694b88207523745f3dec764faa7296d307a · nodes / typescript / duniter · GitLab

const USER_ID = "[A-Za-z0-9_-]{2,100}";

Actuellement dans Duniter v2 : primitives/duniter/src/lib.rs · 5c458eed2e83bcc3e8347b1bde0291ecd20deb61 · nodes / rust / Duniter v2S · GitLab (sur une branche dans laquelle j’ai ajouté des commentaires)

/// Rules for valid identity names are defined below
/// - Bound length to 64
/// - forbid trailing or double spaces
/// - accept only ascii alphanumeric or punctuation or space
pub fn validate_idty_name(idty_name: &[u8]) -> bool {
    idty_name.len() >= 3
        && idty_name.len() <= 64 // length smaller than 64
        && idty_name[0] != 32 // does not start with space
        && idty_name[idty_name.len() - 1] != 32 // does not end with space
        // all characters are alphanumeric or punctuation or space
        && idty_name
            .iter()
            .all(|c| c.is_ascii_alphanumeric() || c.is_ascii_punctuation() || *c == 32)
        // disallow two consecutive spaces
        && idty_name
            .iter()
            .zip(idty_name.iter().skip(1))
            .all(|(c1, c2)| *c1 != 32 || *c2 != 32)
}

Je donne mon avis ici, c’est bien sûr pour en discuter.

Longueur du pseudo :

Voici la répartition de la longueur du pseudo dans la Ğ1 actuellement :

image

La grande majorité est en dessous de 20 caractères. Le plus long étant de taille 41 : BenoitDoutreleau-avec-un-chapeau-sur-le-i

Donc je propose de limiter à 42 (pourquoi pas).

Caractères autorisés

Voici le nombre d’occurrence des 64 caractères (tous utilisés) :

On peut éventuellement ajouter le point ou l’espace, mais je suis contre l’ajout d’autres ponctuations, et pour encadrer strictement leur usage. Il n’y a aucune occurrence de -- ou __ dans les pseudos actuels, les seuls pseudos qui commencent ou finissent par _ ou - sont :

  • _Wapetoooooooo_
  • _tbrt_
  • _vg_
  • nicod_
  • Marine_
  • Sandrine-
  • Charly-

Donc je suis pour :

  • interdire deux caractères non alphanumériques successifs
  • interdire des espaces au début ou à la fin

Normalisation

On commence à voir apparaître des problèmes avec des pseudos similaires, par ex le cas zazou / Zazou : RENOUYVELLER mon ADESIO - #32 par kalimheros - Outils - Support utilisateur - Forum Monnaie Libre

Je suis pour au minimum décourager ça dans les clients, et peut-être même l’interdire en dur pour éviter les attaques par typosquatting.

Pour implémenter ça, on pourrait avoir une version normalisée :

  • lowercase
  • sans ponctuation

et que cette version serve de base pour interdire la création d’un nouveau pseudo trop proche. Voici les exemples des 18 collisions triples actuellement (il y a 202 collisions doubles que je vous épargne) :

  • neo
  • Neo
  • NEO
  • Fred
  • fred
  • FRED
  • lili
  • LILI
  • Lili
  • Michael
  • Micha_El
  • michael
  • sabine
  • Sabine
  • SABine
  • Marie-b
  • marieb
  • MarieB

Ça fait 18 pseudos pour seulement 6 versions normalisées

  • neo
  • fred
  • lili
  • michael
  • sabine
  • marieb

À débattre et méditer…

5 Likes

Ça me paraît bien.

Pourquoi ? Ça répond à quelle problématique ?

Je ne comprends pas que les espaces seraient autorisés en v2 (il en existe plusieurs caractères). Ça n’est pas autorisé dans Duniter v1. Pourquoi cette relaxation pour la v2 ?

Concernant le typosquatting et la normalisation, ça me semble être une bonne chose de le mettre en place. C’est une des rares cryptomonnaies qui a un annuaire de correspondance UserID <−> Pubkey intégré. Ça devrait être comme les caractères des Pubkey évitant les caractères similaires (1, l, I) un, i et L. Sinon à supprimer le UserID du cœur de Duniter comme suggéré dans l’autre discussion. Ça pourrait devenir un outil externe, ou simplement que les clients aient la fonctionnalité de liste de contacts, car c’est un vecteur d’attaque important. On parle de monnaie ici, pas de cacahuètes.

Effectivement, je détaille :

  • les -, _, . et autres sont des séparateurs, ils ne devraient pas être vecteurs de sens
  • comment faire la différence entre ____ et _____ sans compter ? actuellement ces pseudos sont autorisés, je souhaite l’interdire
1 Like

Seul l’espace ASCII \x20 est autorisé. Il est plus naturel pour les non-informaticiens d’écrire “prénom nom” avec un espace, qu’avec un underscore.

Les underscores pouvant être affichés “collés” donc impossibles à compter sans passer le curseur dessus, je suis pour interdire leur duplication. Par contre on a le même problème avec “iiiiiiiiii” et “iiiiiiiii” par exemple. Où est la limite, et si quelqu’un a un nom exotique contenant plein de fois la même lettre avec des accents différents (qui donnerait donc plein de fois le même caractère sans accent)…
Tous les autres caractères (dont le tiret -) sont comptables visuellement donc pour éviter la prolifération de règles trop arbitraires je serais plutôt contre restreindre leur répétition.

On a introduit un identifiant unique aléatoire permettant de générer un identicon exactement pour régler ce problème.

Est-ce qu’on interdit les pseudos qui ne ressemblent pas à des noms légaux, contenant des smileys, genre “Tux<Main> -#- _\o/_” ?

Perso je préfère faire comme avec l’architecture d’Internet, “placer l’intelligence aux bords et non au centre”, donc ne pas supposer des usages des gens de cet outil et se contenter de garantir sa performance et sa sécurité, en laissant les mesures de sécurité “trop intelligentes” (genre distance Levenshtein et typo squatting i,I,l,1) aux clients. Les clients ou les indexeurs pourraient chercher les collisions possibles et en avertir les utilisateurs.

2 Likes

Oui on peut se renvoyer la balle comme ça longtemps lol.

Je suis OK pour implémenter les checks qu’ils faut a ce sujet côté Gecko, mais franchement, je ne vois pas l’intérêt de le faire QUE côté client (sur 1 client ?)

Regarde la messagerie Cs+, le check du nombre de caractère max par message se fait côté client Cesium aussi.
… Un régale pour Jaklis.

J’ai proposé MR !119 en draft, on peut rendre plus restrictif si on veut.

Pour ceux qui veulent lancer les tests chez eux, ça se fait avec

cargo test -p duniter-primitives

pour lancer tous les tests de la pallet.

Mais pourquoi interdire les espaces ? (et les ponctuations)

À moins que les clients affichent les _ comme des espaces (ce qui poserait d’autres problèmes), les gens vont pas arrêter de dire “tiret du 6 ou du 8” parce qu’ils seront obligés d’écrire “jean-sebastien_du_93”.

J’aurais dû choisir comme pseudo

tuxmain                                                   . # en fait non puisqu'on n'autorise pas les espaces consécutifs
t uxmain
tu xmain
tux main
tuxm ain
tuxma in
tuxmai n
t u x m a i n

Je pense qu’on garde les règles telles qu’elles sont en raccourcissant la longueur maximale au vu des observations, on peut argumenter pour ajouter des fonctionnalités, mais il faut que ce soit mesuré.

On devrait plutôt se poser la question : “pourquoi les autoriser dans la migration” ? Je propose de faire la migration en changeant le moins de choses possibles. L’assouplissement des contraintes sur le pseudo sera un bon cas d’usage de la démocratie on chain.

3 Likes

Ça me revient : avant c’était 255 caractères UTF-8, et quelqu’un avait mis un espace dans son pseudo sur la toute première gdev, donc en ajoutant les restrictions j’avais gardé les espaces autorisés parce que c’était plus simple.

J’attendrai pour relancer le débat sur l’autorisation des espaces alors.

Par contre il faut espérer que personne ne s’amuse à créer un pseudo de >42 caractère d’ici la migration.

2 Likes

Une idée (pas pour tout de suite) si on veut permettre l’usage de caractères Unicode, ce qui serait important quand il y aura plein de junistes avec un alphabet non-latin (cyrillique, chinois, hébreu, etc.) : les représenter aussi en punycode ou équivalent. Par exemple le nom de domaine ğ.ml est codé xn--tea.ml.

Après avoir laissé passer un peu de temps sur cette questions, je suis pour valider la MR !119 dans l’état actuel qui conserve le fonctionnement de Duniter v1. On aura amplement le temps de changer ces règles après la migration, ce sera un bon exercice de décisions sur blockchain sans trop d’impact. Des avis ?

  • conserver strictement les règles actuelles de Duniter
  • conserver les règles de Duniter en limitant à 42 caractères
  • restreindre davantage en cherchant à éviter les “collisions”
  • assouplir les règles en ajoutant des espaces ou autres

0 voters

1 Like

MR !119 merged

1 Like

Pour pouvoir utiliser @pseudo c’est quand même plus pratique de ne pas avoir d’espace.

1 Like

@HugoTrentesaux c’est avec raison que ta as bien fait de noter l’importance de cet algo.
Le typo hacking qui en résulte et la quantification opérée par cet “index” auront des “effets de bord”

De mon point de vue, c’est une “question incessante”!!
Parce que l’espace des “pseudo” est trop limité pour ça. Un point c’est tout.

Il faut partir de l’Humain, ses Yeux, ses Oreilles, ses Mains (canaux de communication fondamentaux) et le truc qui relie tout ça à l’intérieur. Ainsi pour moi l’idéal est un “UserID” multimédia.

Une projection des données “cartes postales” juste signées et estampé par la clef publique améliore grandement le résultat obtenu à ce questionnement du lien de reconnaissance entre l’identité biologique et l’avatar numérique.

Ca peut être QmREp6vXhw54rQekha57iLGrcCVSopfUKgrJXSwDaNEp1k le marqueur IPFS “Dessin de support@qo-op.com” extrait de son TW

En attendant de proposer cela, utiliser une adresse formaté de type “email” (qq’un@qqpart) est l’idéal pour commencer. Chacun est libre de mettre @yopmail.com s’il veut rester anonyme :wink:

NB: Dans un espace numérique cohérent et continu, mon @pseudo devrait être “FRD” celui que je mettais sur les bornes d’arcade dans les années 80.

Un “marché” du UserID https://fragment.com/

Oui, j’avais vu cette folie de Telegram ><
C’est le délire, mais c’est comme les squatteurs de nom de domaine.
Heureusement la toile de confiance empêche ça dans une certaine mesure.