Puisque avoir notre propre protocole de messagerie n’est pas réaliste pour la migration, et que même la messagerie Cesium+, qui existe déjà, demanderait trop d’implémentation chez les clients, je cherche comment faire avec les protocoles existants.
Buts
crypto compatible : On peut utiliser la PKI de la Ğ1.
Selon les cas, on peut s’en passer.
décentralisation : Fédération ou distribution, sans point central obligatoire.
bonne crypto : Usage des bonnes pratiques et algos modernes.
forward secrecy : La connaissances de secrets à un instant ne compromet pas la sécurité de toute la communication.
récusabilité : Nul (pas même l’interlocuteur) ne peut prouver qu’un message a été envoyé, même en connaissant des secrets.
possibilité de d’irrécusabilité à l’initiative de l’interlocuteur : on peut envoyer des messages sur lesquels l’interlocuteur peut briser la récusabilité.
Cette fonctionnalité semble présente nulle-part étant donné qu’aucune messagerie n’a de vraie PKI reliée à des identités.
Selon les cas, on peut ajouter une signature dans le message comme extension au protocole.
non-traçabilité : Observer les communications publiques ne permet pas de savoir qui parle à qui.
soutenable : Le projet est stable ou activement maintenu d’une manière qui semble soutenable techniquement et politiquement.
facile à intégrer : Il existe des clients qu’on peut intégrer dans les nôtres ou qui peuvent récupérer les clés depuis les nôtres. Le travail d’implémentation client et serveur est minimal.
En fait il semblerait que la version récente d’OMEMO satisfasse les critères. Il utilise des mécanismes similaires à Signal et est basé sur curve25519.
Pour annoncer son compte toto@serveur.tld, on peut publier un remarkWithEvent. L’indexeur permettra donc aux clients de trouver le compte XMPP correspondant à une adresse.
On peut utiliser des comptes existants, mais on peut aussi créer un identity provider (genre LDAP, ou module Prosody) qui permettrait à un serveur XMPP de créer des comptes automatiquement pour les clés publiques Ğ1 selon des critères donnés (identité, membre, solde).
L’intégration dans les clients consisterait soit à ouvrir un client installé sur le système (url xmpp://), soit à en embarquer un (comme Converse.js).
Je vais voir comment utiliser les clés Ğ1 avec XMPP concrètement.
Est-ce que tu pourrais ajouter Session à ton comparatif ?
C’est un fork de Signal, mais p2p. Ca utilise une blockchain pour l’enregistrement des username entre autres. J’avais l’idée de le forker pour le brancher à v2s.
Avec @Attilax et les collègues Librezo, on a fait pas mal de tests de messageries full p2p, et pour le moment, Session est celui qui semble le mieux fonctionner en groupe.
C’est pour moi un critère fondamental de bien fonctionner en groupe, car c’est évidemment la chose la plus difficile à correctement intégrer sur du p2p.
Leur whitepaper récent (Juillet 2024) semble bien fourni, même si je ne vais pas prétendre l’avoir lu, juste survolé pour le moment.
La seule chose que je reproche à Session, c’est leur système en onion (point 3.2).
Concrètement quand tu envoies un message à quelqu’un, il traverse la terre entière par plusieurs noeuds avant d’arriver à destination. On est sur du p2p qui perd l’un des intérêt fondamental du p2p, la recherche du plus court chemin possible entre 2 noeuds d’un réseau. On est sur l’exact opposé. Dans leur client on peut même voir précisément par quel pays notre message est passé, au moins c’est transparent, mais clairement la sobriété ne fait pas partir de leurs critères.
Ce qui me plait cependant, c’est l’attention toute particulière porté aux groupes et communautés. Ils expliquent bien comment ils traitent différemment les groupes des canaux simple.
C’est pour moi une grosse lacune de XMPP (en plus de ne pas être distribué), j’ai souvent eu des bugs en groupes, des messages qu’on ne voit pas, qui n’arrivent pas dans le bon ordre.
Au delà des specs tech, je pense qu’il faut passer du temps à essayer ces protocoles en situations réels.
Par exemple, certains font l’éloge de Blue Sky en ce moment d’un point de vue protocolaire, mais à l’usage ça s’avère catastrophique, des problèmes de sync.
J’ai l’impression qu’on va être obligé de faire notre propre client, ou un fork, si on veut garantir un compte à tous les membres sans utiliser de serveurs publics spammables (à ouverture de compte sans vérification).
Avec XMPP le serveur LDAP pourrait vérifier que le nom d’utilisateur correspond à une identité membre, mais le serveur XMPP devra vérifier le mot de passe, or on veut plutôt faire un challenge cryptographique pour prouver que l’utilisateur a la clé privée.
Il y aurait moyen de faire une interface web (ou dans les clients Ğ1) qui vérifie ce challenge pour créer le compte, et ensuite on fait avec le mot de passe, mais :
la vérification se fait uniquement à la création
impossible pour un utilisateur de vérifier qu’un compte qui prétend être lié à une identité est authentique (au-delà de vérifier l’annonce dans la blockchain)
de toute façon chaque client XMPP a une config différente, donc dans les faits personne n’utilisera OMEMO correctement
Donc maintenant j’aurais plutôt envie de faire la migration avec la messagerie Cesium+, et de prendre le temps de travailler à un système qui coche vraiment toutes les cases, plutôt que de bricoler un truc pas terrible.
Moi je propose de faire la migration avec rien du tout.
On a pas besoin de messagerie pour utiliser la Ğ1 et la messagerie cs+ pose trop de problèmes.
Sinon Session utilise un challenge crypto pour l’auth.
De plus si tu veux garder la messagerie CS+, ça veut dire garder l’ensemble des pods Cs+ qui sont indissociables, + l’indexer Duniter v1 qui est également indissociable du reste du pod (sisi).
Aussi, il y aurait de toute façon du dev nécessaire sur ces pods pour qu’ils autorisent les signatures sr25519 en plus de ed25519
Si on a rien de parfait autant proposer une solution ok tiers qui fait le job avec les clé Ğ1 sur un réseau existant, le temps de r&d quelque chose de notre côté. Ou rien du tout.
La messagerie pose des problèmes mais les gens l’utilisent. C’est le seul et unique moyen de communication utilisable directement par quasiment tous les junistes. (ce sera moins le cas quand d’autres clients seront plus utilisés, mais il suffit d’installer Cesium et ça marche tout seul)
Ne pas pousser officiellement un moyen de communication, c’est forcer le standard de fait, donc Telegram, Whats’app ou que sais-je.
@kimamila Qu’envisages-tu par rapport à la messagerie Cesium+ ?
C’est bien ce que j’essaie de faire, mais “solution tierce” et “clés Ğ1” est difficile à faire concorder, à moins de faire du PGP par mail, et même ça demanderait un gros travail côté client (tu veux implémenter un client IMAP/SMTP dans Gecko, ou un module PGP avec import de mnemonic dans Gmail ?).
Dans tous les cas il faut au moins forker un client.
Les deux solutions R&D qui me restent sont forker Session, ou trouver une couche de transport pour mon protocole fait maison.
Je suis d’avis avec Poka. Il n’est pas nécessaire d’avoir une messagerie instantanée intégrée pour la migration. C’est une fonctionnalité en plus qui peut venir plus tard. Le développement technique de la Ğ1 en elle-même manque de bras. Le développement du cœur, des clients et des outils pour l’écosystème v2 est encore largement sous développée. Pour les clients v2, on en est encore à intégrer le calcul des DU non réclamés dans le solde, chose de base. Développer et maintenir une messagerie intégrée avec toutes les super fonctionnalités (de sécurité) intégrées c’est un plus, plus, plus. Après, tuxmain, c’est pas pour te dire de ne pas faire ce qui fait chanter ton cœur. Si tu as envie d’apporter cette contribution, je comprends, libre à toi de continuer dans ton élan C’est une super contribution ! Un bon projet long terme !
Si c’est pour pousser encore plus loin la technique de la messagerie instantanée à la limite de l’existentiel, il y a des projets de protocoles ouverts comme XMPP et autres que tu peux rejoindre pour contribuer.
Pour montrer qu’il est possible d’intégrer un protocole de MI dans un écosystème, il y a le jeu 0 A.D. qui a intégré XMPP avec un serveur central pour les parties multi-joueurs : discussions dans le salon, dans les parties.
Je suis d’accord sur ce point-là, mais l’équipe de développeurs Ğ1 ne peux pas tous faire, on ne peut pas rendre tout le monde parfait, ou du moins l’écosystème technique de la Ğ1. Je pense qu’il faut se concentrer sur notre cœur de métier principal, le développement technique d’une monnaie libre, et ne pas trop s’éparpiller. Déjà que notre temps de contribution est limité du fait que nous ne sommes pas rémunérés pour pouvoir s’y mettre à plein temps. Et même à plein temps, on est encore limité
Je nuance ce que dit @tuxmain. Il y a déjà une messagerie principale, c’est le commentaire de transaction.
Le commentaire de transaction est souvent suffisant pour tout message court. Pour des messages plus longs et ou personnels, ne plus avoir de messagerie césium+ inciterait plus chacun à indiquer une adresse email, quitte à la camoufler un peu pour éviter les bots de spam.
Le commentaire de transaction, que je nommerais plutôt « référence de transfert », sert premièrement à indiquer à quoi fait référence ce transfert. Si un vendeur vend plusieurs articles dans la même journée, ça l’aide à se retrouver pour savoir quel transfert correspond à quelle vente, par exemple.
J’espère que personne n’utilise cette fonctionnalité comme messagerie, ça revient cher, c’est pas fait pour, et le texte est en clair
Si on a une page de profil, on a Cesium+, donc on a la messagerie Cesium+…
À moins d’utiliser des commentaires pour publier les champs de son profil, ce qui pose encore plus de problèmes pour la vie privée et la possibilité d’oubli.
J’essaie de montrer que non : sur ma page de profil il y aura Matrix et Mastodon. Sur la page de profil de quelqu’un d’autre il y aura Telegram et Facebook. On ne peut pas communiquer.
La toile de confiance requiert une communication entre voisins, mais pas globalement. Il faut pouvoir rester anonyme vis-à-vis du reste de la toile. Donc on ne peut pas demander de publier son mail ou un autre moyen de communication mainstream. Au final seuls quelques geeks publieront leurs identifiants RicochetRefresh, Tox ou Session, et ne pourront parler à personne.
Je regarde le whitepaper de Session, j’ai l’impression qu’ils ont pris Signal et lui ont retiré tout ce qui le rendait intéressant. On utilise directement les clés d’identité pour le chiffrement et la signature.
Pas nécessairement, pourquoi avoir une page de profil implique d’avoir une messagerie ? Les pages de profils, ou simplement des champs d’adresses de messagerie peuvent être stockés sur les datapods et associés à une adresse Ğ1.
C’est déjà le cas à l’extérieur de la ML, les gens utilisent plusieurs services de messagerie incompatibles et ne peuvent pas communiquer entre-eux. N’est-ce pas ? Pourquoi vouloir résoudre ce problème pour les utilisateurs de la ML ? Ça me fait penser à ce XKCD :
Je ne suis pas sûr de comprendre. En publiant une adresse de messagerie associé à son adresse Ğ1 membre publiquement on est plus « anonyme vis-à-vis du reste de la toile » ? Faut-il rester « anonyme vis-à-vis du reste de la toile » ? Pourquoi ? Après, je vois le fait de publier ses moyens de communication publiquement, comme quelque chose d’optionnel. Les moyens de communication c’est quelque chose qui se partage au cas par cas de manière décentralisée avec ses proches et êtres humains avec lesquels on a des échanges Ğ1, certifications.
J’ai un cas d’usage pour DeathReaper pour ce champ dans les datapods, si un être humain associe son adresse courriel à son adresse membre Ğ1 dans un datapod, elle pourrait recevoir une notification.
Personnellement, je trouve que l’on ne peut pas se permettre de ne pas avoir de messagerie. La June est un réseau social (au sens groupe d’intérêt commun) et une messagerie me semble la base.
J’ai eu pas mal de 1er contact par la messagerie Cesium (demande de certif, remerciement, recherche de junistes à proximité…). Ça permet d’échanger téléphone et autres canaux de communication aussi. Je vois mal comment s’en passer !?
Quel que soit le cryptosystème on peut toujours utiliser une seed commune comme source d’aléa pour générer la clé privée, le problème est que si ce n’est pas algébriquement compatible, on ne peut pas trouver la clé publique dans un système à partir de celle d’un autre système.
Par exemple ed25519 (Duniter), sr25519 (Substrate) et x25519 (Diffie-Hellman) sont liées par la même structure algébrique curve25519, et sont compatibles. On peut convertir les clés publiques et privées d’un système à l’autre.
Alors que si je génère des clés publiques ed25519, ristretto, p256, RSA, etc… à partir d’une même seed, pour un observateur extérieur elles seront indistinguables de clés choisies indépendamment au hasard.
[edit] Ça n’empêche pas d’utiliser le système incompatible, ça oblige seulement à publier notre clé publique en blockchain.
C’est une super contribution ! Un bon projet long terme !