Risque de concurrence via la messagerie des wallet (cesium etc...)?

Applications Cesium
1

Salut à tous,
J’espère que vous allez bien.

Je me pose une petite question sur la messagerie intégrée dans Cesium / Gemko et autres. Si je comprends bien, elle permet de contacter assez facilement des gens qui ont fait des échanges avec un autre compte ou un autre commerce. Du coup je me demande : est-ce qu’un concurrent (ou n’importe qui) pourrait assez facilement repérer et contacter mes clients qui ont déjà échangé avec moi ?Je trouve ça un peu risqué niveau confidentialité et concurrence…

Cette fonctionnalité semble permettre à n’importe qui de contacter facilement les clients d’un autre commerçant. Cela risque de créer une concurrence déloyale assez directe : un concurrent peut littéralement « chasser » les clients d’un autre en quelques clics. Il y a t-il des garde-fous concrets pour éviter cela ?
Ou existe-t-il au moins une option pour limiter la messagerie uniquement aux personnes avec qui on a déjà réalisé un échange ? C’est un point qui me semble très important pour les commerçants qui utiliseraient Ğ1 au quotidien. Merci d’avance pour votre retour.

Bonne journée à vous !

2

concurrence ? on parle bien de junes là ?

comment tu faisais avec Cesium v1? toutes les transactions ont toujours été visibles et la messagerie accessible !

3

Il y aura juste des garde-fous à ajouter à la messagerie pour éviter les spams et contacts indésirables.
Comme on n’a pas accès au backend, soit on attend une vraie solution pour mettre ça en place, soit on fait des patchs côté client.

4

Salut,
Merci pour ton retour.
Je comprends que vous allez ajouter des garde-fous anti-spam, c’est déjà ça.
Cependant, le problème va au-delà du simple spam. Pour un commerçant, le vrai risque est qu’un concurrent puisse facilement identifier et contacter directement ses clients qui ont fait des transactions avec lui.
Imagine que tu sois commerçant : ton concurrent a accès à tous tes clients qui ont déjà échangé avec toi via Ğ1, et il peut les contacter directement en un clic. Il peut leur proposer des prix plus bas, des promos, etc. C’est comme s’il avait une copie de ton fichier client et pouvait les démarcher librement. Tu trouverais ça normal sur une monnaie ? Pour eux, c’est un vrai risque de concurrence déloyale.
Peut on prévoir une option pour limiter la messagerie uniquement aux personnes avec qui on a déjà fait une transaction ? Ou un système de liste blanche ? Sans protection sérieuse, beaucoup de commerçants vont refuser d’utiliser la Ğ1 pour leurs transaction, trop risquée.
Qu’en penses-tu ?

5

Ben ça, c’est ce que tu peux trouver depuis le début de l’existence de la Ğ1 en regardant l’activité des comptes !

Ben l’intérêt est justement de pouvoir contacter quelqu’un qu’on ne connait pas, parce que si on a déjà fait une transaction, on a pu aussi lui demander son mail ou téléphone ou autre !

6

Salut à tous,

Je reviens sur la problématique de messagerie intégrée dans les wallets (à la base outil monétaire et non outil de messagerie ou de réseau social).

Pour un commerçant A, le risque est le suivant : Un concurrent B peut très facilement voir les clients de A qui ont échangé avec A, puis les contacter directement via la messagerie du wallet en quelques clics. C’est comme si ce concurrent B avait accès à une partie de son fichier client et pouvait leur écrire instantanément pour leur proposer de meilleures conditions, concurrence agressive, stratégie d’éviction, etc.

Du coup cette fonctionnalité de messagerie intégré au Wallet de la G1 crée un outil très efficace pour un concurrent agressif de contacter directement ses clients (à notre époque pour un commerçant son fichier client représente le travail de plusieurs année). Beaucoup refuseront l’usage de la Ğ1 pour leurs ventes par peur d’exposer leurs clients.

C’est cette problématique que je voulais souligner.

PS : C’est un problème soulever par des amis commerçants que je comprend et nous n’avons pas de réponse.

7

A mon humble avis, ton problème n’est pas un problème de messagerie, mais de confidentialité. Comme tu le dis très bien dans un de tes messages.

La majorité des Crypto-monnaies sont des livres de transactions publiques. C’est ce problème avant tout que le commerçant doit résoudre. Lorsque des solutions d’anonymisation des transactions seront proposées et utilisées par les commerçants soucieux de cacher la liste de leurs client, la messagerie ne posera plus aucun soucis.

Car, qu’elle soit intégrée à Césium ou pas, une messagerie entre usagers de la June est très demandée et assez pratique. Le seul problème, pour moi, de la messagerie Césium est de recevoir des messages non soliscités. Il faudrait un système d’autorisations.

J’espère avoir répondu à la question à défaut de résoudre le problème.

8

Salut, Merci pour ton retour. Je suis d’accord que la blockchain Ğ1 est publique, c’est une caractéristique connue. Mais le point que je soulève est différent. Avec la messagerie intégrée directement dans le wallet, un concurrent peut désormais :

  • Voir facilement qui a échangé avec un commerçant

  • Lui envoyer un message directement et instantanément

C’est un niveau de facilité qui n’existe généralement pas dans les autres wallet. Ce n’est plus seulement « on voit les transactions », c’est « on peut contacter les clients d’un commerçant en 2 clics ».C’est ça qui pose problème aux commerçants : le risque concret de se faire démarcher leurs clients par la concurrence. L’anonymat total des transactions serait une solution idéale, mais en attendant, est-ce qu’on ne pourrait pas au moins protéger les commerçants avec des outils concrets dans la messagerie (liste blanche, autorisation préalable, etc.) ? C’est vraiment cet aspect « protection des clients des commerçants » qui me semble important. C’est une question pour l’évolution de la monnaie libre.

9

Vous n’avez pas besoin de cette messagerie pour ça:

  • Utiliser les liens réseaux sociaux publier les clients
  • Envoyer 1 g1 avec un commentaire de transactions aux client.

Les tentatives d’obfuscation de votre clientèle sont vaines sur ce genre de réseau.

10

Salut à tous,

La question soulevée par @Nechrom est tout à fait pertinente. Lier directement et automatiquement l’identité monétaire publique (on-chain) à l’identité de communication (off-chain) expose les utilisateurs à du ciblage marketing sauvage ou du siphonnage de clientèle. N’importe quel concurrent pourrait analyser la blockchain, lister les clés publiques des clients d’un commerce et leur envoyer des DMs d’incitation.

Pour résoudre ce problème, l’écosystème UPlanet / Astroport applique un principe de découplage strict des couches de données et utilise un protocole de génération de clés décentralisé et déterministe.

Voici comment sont fabriqués et gérés les clés :

1. Le système de “Double-Clé” déterministe (Découplage des rôles)

Le protocole n’utilise jamais la clé monétaire Ğ1 pour chiffrer ou signer les communications, et n’utilise pas non plus deux phrases de restauration distinctes (ce qui détruirait l’expérience utilisateur).

À la création du compte, l’utilisateur génère un secret unique (un couple SALT / PEPPER issu de Diceware ou dérivé d’une clé SSH). À l’aide de fonctions de dérivation (scrypt), keygen crée plusieurs clés asymétriques totalement distinctes et hermétiques en apparence :

  • La clé monétaire Ğ1 (.secret.dunikey) dédiée à Duniter v2.
  • La clé de messagerie Nostr (.secret.nostr - NSEC/NPUB) dédiée aux DMs chiffrés de bout en bout (NIP-44).
  • La clé de nommage IPFS (.secret.ipns) pour le stockage décentralisé.

L’utilisateur n’a qu’un seul identifiant/secret à sauvegarder, mais ses identités publique (financière) et privée (communication) n’ont aucun lien cryptographique évident.

2. L’association d’identité à consentement (Opt-in)

La liaison entre l’adresse Ğ1 et le profil de messagerie Nostr n’est pas inscrite sur la blockchain et n’est pas automatique. Elle est déclarée de manière décentralisée via un document d’identité DID (Kind 30800) ou des tags de profil Nostr (["i", "g1pub:<adresse_g1>"]), sous le contrôle exclusif de l’utilisateur :

  • Le commerçant choisit de lier son portefeuille à son profil de messagerie pour être facilement contacté par ses clients.
  • Le client, lui, peut laisser son profil Nostr en mode privé (public: false), ou tout simplement choisir de ne pas publier l’association entre son adresse de paiement et sa clé Nostr.

Un concurrent qui scrute la blockchain verra passer des Junes vers le portefeuille du commerçant, mais ne pourra pas en déduire la clé Nostr du client pour le démarcher.

3. Le pare-feu décentralisé (Listes blanches N1/N2)

Dans l’éventualité où la clé publique Nostr d’un utilisateur est découverte, les relais locaux (strfry embarqués sur les nœuds Astroport) appliquent des règles de filtrage à l’écriture.

Grâce à un système de liste blanche d’amis et d’amis d’amis (amisOfAmis.txt), la station n’accepte et ne notifie les DMs entrants que s’ils proviennent d’un contact de premier niveau (N1) ou de second niveau (N2). Les messages non sollicités provenant de parfaits inconnus ou de robots de démarchage sont ainsi rejetés à la périphérie du réseau, avant même d’atteindre la boîte de réception de l’utilisateur.

Ce cloisonnement entre la couche financière (Duniter) et la couche de communication (Nostr) est une approche viable pour concilier la transparence nécessaire d’un registre de monnaie libre et le respect de la vie privée des utilisateurs.

11

Pas besoin de double clé pour tout ça, il suffit de générer une dérivation.
La liste blanche N1/N2 c’est typiquement le genre d’antispam dont je parle.

Ca arrive.

12

Tout à fait, nous disons la même chose avec des perspectives différentes ! C’est l’opposition classique entre la vue “interne” (la graine/entropie d’origine) et la vue “externe” (les clés publiques visibles sur les réseaux).

Le point crucial — et c’est là que réside la sécurité du système — est que les deux protocoles n’utilisent pas le même espace mathématique (la même courbe elliptique) :

  • Duniter (v1 et v2s/Substrate) s’appuie sur la courbe Ed25519 (ou sr25519/Ristretto255) pour signer les transactions monétaires.

  • Nostr s’appuie exclusivement sur la courbe Secp256k1 (BIP-340 Schnorr, comme Bitcoin) pour chiffrer et signer les messages.

Comme il est mathématiquement impossible de convertir directement une clé publique Ed25519 en une clé publique Secp256k1, on doit obligatoirement dériver les clés privées de chaque courbe à partir d’un même secret maître (via un algorithme de dérivation de graine comme HKDF, PBKDF2 ou Scrypt).

En pratique :

  1. Pour l’utilisateur (UX) : L’expérience reste simple et unifiée. Il n’a qu’un seul mot de passe (ou une phrase de récupération) à retenir. Les applications s’occupent de dériver les clés en arrière-plan.

  2. Pour la vie privée (Privacy) : Sur le réseau, les clés publiques Ğ1 et Nostr semblent n’avoir aucun rapport. Un robot qui scanne la blockchain Duniter verra passer des transactions entre clés Ed25519, mais il ne pourra pas “deviner” ou calculer la clé Secp256k1 Nostr correspondante pour envoyer un DM, sauf si l’utilisateur a explicitement publié un lien d’attestation (comme un DID ou un tag de profil).

Le fait d’utiliser des dérivations sur des espaces elliptiques distincts permet donc de casser le lien automatique entre le grand livre comptable public et la messagerie, protégeant ainsi les utilisateurs du scraping publicitaire ciblé.

Et ravi de voir que nous sommes d’accord sur la nécessité de filtres antispam basés sur les cercles de confiance (N1/N2) ! C’est un outil indispensable pour assainir les communications décentralisées.

13

Oui ces discussions ne sont pas nouvelles, elles dates de 2018 juste après le démarrage de Cesium en prod.

On attends juste le nouveau système de données offchain pour concevoir par dessus.
En attendant, c’est juste les utilisateurs qui ont décidé d’eux-mêmes de rebrancher l’ancienne Messagerie Cs+ pour pallier un manque. Tout ça est juste provisoire.

Mais de toute manière, comme la june n’est plus utilisée que par quelques personnes, il y a peu de risque que ça pose de problème à court terme.

Et auquel cas, on fera un patch côté client vite fait en attendant ce nouveau système.

Pour le reste, comme on ne s’encombre pas avec Nostr, on n’a pas besoin de s’encombrer avec des clés jumelles Secp256k1. On reste en ed25519.

14

Salut :hugs: , Merci pour les réponses, je me sens compris dans ma réflexion. La proposition est intéressante, mais elle me semble un peu complexe pour une mise en place rapide. Personnellement, j’imagine une solution plus simple qui serait peut être de faire un fork de Cesium :
un wallet très épuré, sans messagerie, sans commentaires de transaction, et uniquement orienté portefeuilles simples (non-membres). Ça resterait 100 % compatible avec la Ğ1 et permettrait à des projets commerçants d’utiliser la G1 plus sereinement. Qu’en pensez-vous ? Des développeurs seraient-ils motivés pour participer à un tel fork avec “Claude” ? :slightly_smiling_face:

15

Il n’y a pas Tikka qui est orienté professionnels ?

16

Effectivement, pour l’instant on travaille sur des systèmes à métadonnées publiques. Donc même si le contenu du message est chiffré, ses métadonnées (émetteur, destinataire) sont publiques. Si ces données sont sensibles, il vaut mieux utiliser un autre système de messagerie.

Pour information, l’immense majorité des messageries même chiffrées partagent leurs métadonnées avec un tiers de confiance. Ce tiers a la possibilité de :

  • exploiter ces données pour son utilisation personnelle
  • vendre ces données à quelqu’un prêt à payer pour les exploiter

Voilà pourquoi il est primordial d’avoir confiance en ce tiers.

Pour contourner ce système de tiers de confiance, il faudrait par exemple des messageries p2p routées par Tor comme https://cwtch.im/ mais ça vient avec des contraintes assez fortes.

Donc pour l’instant, ma recommandation est de ne pas utiliser cette messagerie à métadonnées publiques et utiliser à la place des messageries à tiers de confiance.

17

Non, ce n’est pas ce dont parle @Nechrom.
Son problème n’est même pas que les metadata soient en clair. C’est qu’il ne veut même pas qu’on puisse voir les clients de quelqu’un. Et les contacter facilement, quel que soit le moyen.
C’est donc en amont de la communication, avant même que toute communication soit faite, donc avant même la génération de metadata de communication.

Ça n’a aucun sens, si le commerçant utilise ça, mais que tout le monde à côté utilise des apps avec messagerie, ça ne protège en rien du tout ce que vous dénoncez.

Je vous ai déjà répondu. Vous êtes sur un réseau décentralisé où les transactions se font en blockchain de manière transparente. Vous ne pourrez pas échapper à cette transparence et donc vous ne pourrez pas obfusquer vos clients.

Même si un jour on propose des fonctionnalités d’obfuscation de transaction sur le réseau Duniter, ça restera à l’initiative du client ou du vendeur.

18

Salut à tous, Je pense que nous avons fait un bon tour de la question qui avait d’ailleurs déjà été soulevée.

Ce que je retiens :
Dans l’état actuel de la Ğ1, ce problème n’a pas de solution satisfaisante.
La blockchain est transparente, les transactions sont visibles par tous, et avec Cesium il est très facile pour un concurrent de voir les clients d’un commerçant et de les contacter directement ou d’utiliser les commentaires.
Conséquence :
Les commerçants hésitent ou refusent d’accepter la Ğ1 par peur d’exposer leur fichier client. C’est un frein important à l’adoption réelle de la G1 dans leur échanges. Le Bitcoin rencontre le même problème de transparence, mais les commerçants ont développé certaines pratiques et outils pour le limiter (je vous laisse les découvrir si vous ne les connaissez pas déjà).
Mon opinion :
Un wallet simplifié (fork léger de Cesium avec un autre nom ou pas ? ), sans messagerie et sans commentaires de transaction, uniquement orienté portefeuilles simples (non-membres), serait très utile dès aujourd’hui. Ce serai un bon début même si à terme, cela sera insuffisant. Cela permettrait au moins aux commerçants de commencer à accepter la Ğ1 plus sereinement.
Question concrète :
Combien de temps faudrait-il pour réaliser cette version épurée ?
Et y a-t-il des développeurs dans la communauté motivés pour s’en occuper (bénévolement ou autrement) ? Merci d’avance pour vos avis.

19

Actuellement les commerçants filent déjà toutes leurs données aux banques et ça ne les empêche pas d’avancer. Donc il suffit de faire une banque en monnaie libre (un tiers de confiance), qui tienne des comptes non publics (hors chaîne) au nom des commerçants. Pour faire un virement, le commerçant contacte sa banque par un canal privé en lui communiquant l’identifiant du destinataire. Si le destinataire est dans la même banque son compte dans le registre privé est crédité immédiatement, s’il est dans une autre banque, il y a un transfert inter-bancaire en fin de journée comme c’est le cas aujourd’hui.

La seule différence est qu’au lieu d’avoir un compte à la banque centrale européenne, les banques ont un compte en Ğ1. Il faudrait aussi des régulations pour interdire la création monétaire, car dès qu’on tient un registre privé, rien ne l’interdit.

20

Salut Hugo,
Ton idée de créer des « banques en monnaie libre » avec des comptes est une solution et certain le feront lorsque la G1 aura du succès et sans doute avec pertinence. Mais cette direction ne m’intéresse pas et je souhaite l’éviter : on recréerait des intermédiaires de confiance et des structures bancaires, alors que personnellement je suis dans la Ğ1 précisément pour nous en affranchir. Je tiens tout particulièrement au concept de création monétaire par chaque humain. C’est pour moi un pilier important de la Ğ1 et peut-être une partie d’un chemin vers un monde meilleur. Ma réflexion actuelle est de créer un besoin en G1 et donc une utilitée de G1.