Ok je comprend. En effet, secp256k1 n’utilise pas curve25519.
C’est dommage car secp256k1 est utilisé par l’autres cryptos : bitcoin, ethereum…
Quand tu dis que ça oblige seulement à publier notre clé publique en blockchain, tu parles ne notre blokchain ? Ça pourrait être aussi les data-pods ?
Le but ici est de profiter de la TdC : s’assurer qu’on communique avec une clé qui est bien associée à une identité en blockchain.
J’ai aussi abandonné l’idée d’utiliser les datapods qui sont trop expérimentaux.
Bitcoin utilise secp256k1 parce que ed25519 n’était pas connu à l’époque, et que secp256k1 est un dérivé de p256 (standard du NIST) dans laquelle on peut avoir un peu plus confiance (rien ne prouve que p256 n’a pas de backdoor). Même si secp256k1 devrait être sûr, il n’y a aucune raison de l’utiliser puisque les autres courbes sont plus performantes et sûres.
Comme de toute façon on n’y arrivera pas avant la migration, et qu’en cas de besoin il y a les commentaires et peut-être Cesium+, autant s’amuser à trouver le protocole idéal sans compromis (moi ça m’amuse en tout cas).
Oui mais vraiment je pense qu’il faut faire le deuil des pods Cs+ pour v2s.
Salut, je ne suis pas du tout sur que Jami réponde à tous les critères, mais il me parait être un très très bon candidat !
En tout cas ce projet à le mérite de résister au temps, et d’être entre autre p2p et compatible SIP.
Jami est super en 1-to-1: p2p, décentralisé, chiffré, smartphone ou desktop, installable en local, appels audio et vidéo. Il y a un peu de latence, mais c’est négligeable par rapport à tous les avantages.
En revanche les swarms (conversations de groupe) sont en version bêta et il y a quelques bugs. Mais pour le sujet qui nous préoccupe ici, à savoir une messagerie fiable et sécurisée commune, Jami semble un bon candidat.
C’est mon avis d’utilisatrice et testeuse zélée, techniquement tu en penses quoi @tuxmain ?
Concernant l’utilisation ou pas de la messagerie interne de CS+ le Megadon fonctionne avec tous les jours.
Les gens se présentent et font leur demande de don au travers la messagerie CS+.
Si il n’y a plus de messagerie dans CS2 je ne sais pas comment les gens vont contacter le Megadon pour recevoir le don de bienvenue ?
Amicalement 
Pour la messagerie sécurisée externe, j’ai converti ma clef “salt/pepper” avec ~/.zen/Astroport.ONE/keygen en PGP
Puis importé la clef dans https://delta.chat on se retrouve avec une messagerie sécurisée
Par une conversion SSH et IPFS, on relie les machines en essaim privé qui peut automatiser la distribution des accès (~/.ssh/authorized_keys) et le partage de ports (ipfs p2p)…
Que diriez-vous d’une interconnexion ?
Les machines de l’essaim utilisent des portefeuilles et le Ẑen pour assurer leur compta, faire payer les services, distribuer les charges et les bénéfices aux membres co-propriétaires de l’essaim. Chacun dispose de 128Go (x2) et 24 slot horaires pour stocker et traiter ses données à l’IA
IMAP est un protocole conçus pour …
pardon… conçus pour l’échange d’email de manière asynchrone. L’utiliser pour de la messagerie instant revient à le travestir, sans son consentement. J’assimile ça à une sorte de viol protocolaire.
Ca se ressent à l’usage de delta.ch 
delta.chat, d’un côté l’aspet instant est somme tout très relatif, et de l’autre on se retrouve avec des spams infernales dans notre boite mail, si bien qu’on doit créer les filtres qui vont bien pour s’y retrouver.
Je boycott totalement cette abomination. Pour moi ceux qui l’utilise vénèrent satan secrètement le soir et mangent des enfants morts à Noël. Du moins c’est comme ça que j’image les 7 utilisateurs de delt pardon delta.chat.
C’est imagé… J’avoue que je n’utilise pas “delta” non plus 
L’email est foutu et bien trop compliqué… Enfin ça m’a donné une façon simple de fabriquer et utiliser une clef PGP sans la paumer comme à ma 1ère utilisation de delta.chat, (bitcoin aussi d’ailleurs à une autre époque)… Ce qui est fun c’est pouvoir dériver ses clefs à partir de “salt pepper” pour plus les paumer et choisir d’en placer à certaines localisations.
On peut reprendre les ports 53, 80, et 443 et relier les machines aux humains qui s’en servent.
Je n’ai pas considéré les solutions à base de PGP car il n’y a pas de forward secrecy : si ta clé privée fuite, toutes tes conversations sont dévoilées. C’est utile pour la signature ou en cas d’absence d’infrastructure spécialisée, mais tous les protocoles listés dans le tableau sont mieux.
Une solution simple serait que @megadon indique une adresse email par laquelle les demandeurs feraient leur demande.
Salut, en fait au début du Mégadon on avait mis en place un email pour que les gens fassent leur demande via ce moyen mais ça a été ingérable.
Bien souvent, ils oubliaient de donner leur pseudo et leur clef publique, il fallait leur répondre pour qu’ils renvoient une réponse, et là ils envoyaient qu’une partie de la clef publique au lieu de la clef complète, du coup parfois on les retrouvait quand même mais parfois, il fallait leur renvoyé encore un mail pour qu’ils comprennent qu’on avait besoin de la clef complète, bref… c’était vraiment pas facile à gérer de cette façon. 
Là dans la messagerie CS+, on clique sur leur nom et on atterri sur leur compte, on peut vérifier directement s’ils respectent le conditions pour recevoir le don de bienvenue, pas besoin d’échanges multiples via mail.
Suite à une discussion avec @srosset81, j’ajoute Nextgraph dans le tableau comparatif.
Il s’agit d’une base graph écrite en rust, p2p, local first, qui combine E2EE, CRDT, web sémantique avec du pub/sub et accessible en RPC/REST/GraphQL.
Cette solution pourrait répondre aux besoins de messagerie et de stockage des données hors chaîne.
Sébastien et Reconnexion travaillent sur la conception d’un réseau social universel qui pourrait s’appuyer sur la TdC de duniter si on se retrouve dans nextgraph.
La prochaine résidence de reconnexion se déroulera du 16 au 20 février 2026 aux alentours de Nîmes et cela pourrait être l’occasion de se retrouver pour un hackaton axiom en même temps.
C’est intéressant. Mais je n’ai pas compris où étaient stockées les données, ni s’il fallait des nœuds permanents pour assurer la permanence de l’accès aux données, ni même si cette permanence est assurée.
Self Hosted installation 🚀 NextGraph Docs
Self-hosting of the broker will come in 2025. Stay tuned for more features and added freedom!
When you self-host a broker, you enjoy the exact same features than with our public Broker Service Providers, but in addition, you don’t have to abide by any Terms of Services, and your data is free from any limitations.
Pour le moment ça marche avec une plateforme centralisée uniquement ? Et quand le self-hosted broker sera implémenté, pourront-ils former un réseau unifié ?
De ce que j’en ai compris les brokers assurent la disponibilité de la donnée et il est possible d’en compiler depuis les sources, c’est le packaging qui n’est pas encore réalisé.
On doit organiser une visio avec un des développeurs (niko) en janvier si ça t’intéresse je peux te mettre dans la boucle ?
Oui pourquoi pas.
J’ai corrigé quelques points dans le tableau. Un truc que je n’ai pas trouvé c’est quelle cryptographie ils utilisent (pour que ce soit compatible sans faire de plomberie il faut que ce soit ed25519).
Pour la forward secrecy, si c’est avec la granularité d’un document, et qu’un document est une discussion avec sa propre clé secrète qui n’est pas celle d’un des interlocuteurs, alors c’est déjà pas si mal. Révéler la clé secrète du compte ne révèle pas forcément toutes les discussions. (à voir comment on stocke les clés des documents protégés)
Y’a https://0xchat.com/ un client de messagerie “chiffrée de bout en bout” basé sur NOSTR
@tuxmain je suis stupéfait de voir Nostr balayé d’un revers de main avec l’étiquette “facho”.
Juger un protocole de transport de données par les opinions de certains de ses utilisateurs (ou de ses donateurs), c’est comme dire que le protocole HTTP est “facho” parce que des sites d’extrême-droite l’utilisent. Un protocole est agnostique, ou il n’est pas.
Pour répondre à la question de fond : Lequel des protocoles cités permet une réelle décentralisation multi-protocole ?
La réponse est : Aucun, sauf Nostr.
Voici pourquoi les propositions (Matrix, XMPP, Session) ratent une marche essentielle par rapport à ce que nous construisons :
Matrix et XMPP reposent sur des serveurs. Si votre serveur ferme ou vous bannit, votre identité @pseudo:serveur.tld meurt. C’est une décentralisation de façade.
Dans Nostr, votre identité est votre clé publique (compatible avec vos clés Ğ1). Vous publiez sur des relais. Si un relai ne vous plaît plus, vous changez. Vos abonnés vous suivent car ils suivent votre clé, pas un serveur. C’est la seule approche cohérente avec l’esprit de la Monnaie Libre.
Aucune des solutions de Tuxmain ne permet de sortir du “silo chat”. Nostr, via ses Kinds, permet avec la même identité :
@poka dit qu’on n’a pas de bras pour dév une messagerie v2. Il a raison ! C’est pour ça qu’utiliser Nostr est la solution : les clients ultra-performants existent déjà (Coracle, 0xchat, Amethyst).
Nous avons déjà mis en place les outils pour convertir une identité GChange en identité Nostr :
Testez ici : https://u.copylaradio.com/g1
Le réseau est déjà là, décentralisé, avec des relais comme celui de Guenoel (https://u.guenoel.fr/g1) ou le mien. La synchronisation N² (les amis de mes amis) s’occupe de la résilience sans effort de développement supplémentaire pour Duniter.
Pour ceux qui s’inquiètent de la pérennité, nous intégrons la gestion des coûts (CAPEX/OPEX) via le logiciel de comptabilité ẐEN. L’objectif est que chaque nœud/relai soit viable économiquement.
Plus d’infos sur la vision globale : UPlanet & Nostr.
En résumé : On peut continuer à chercher le protocole “parfait” en théorie pendant 2 ans, ou on peut utiliser un protocole de transport universel, souverain et déjà compatible avec nos clés Ğ1.
Je vous invite à tester la passerelle.
La messagerie tox est déjà pas mal. Et toujours en développement.
Et elle a comme qualité de ne faire que la messagerie!
Et les discussions de groupe sans modérateur : la gestion des groupes est ainsi minimaliste : t’es pas d’accord tu quittes et crée un nouveau groupe. Ça c’est top: minimaliste mais avec du sens.
C’est aussi une des seules messageries à faire un système anti-spam, dans l’adresse
tox:80E022F479ADB9A7929AAF85DD87D016CCD2455BF072E30B5C3B3C9BD565704AAF7477FCD567
la partie en gras est l’anti-spam, nécessaire pour pouvoir être contacté mais qui peut changer facilement à la demande.
Alors c’est distribué effectivement, donc consomme des données sur les appareils. Un système pour les effacer peut être top.
Nostr j’ai testé (Amethyst): bordélique, usine à gaz, et on m’a juste parlé de bitcoin alors que je suis contre cette monnaie !?
Je l’ai gardé au cas où.
C’est l’information que j’avais au moment de publier le message. Il s’agissait du fondateur (cf le lien) et donc de la communauté autour. Je ne sais pas si c’est encore vrai et c’est justement ce que je t’avais demandé au CdL. En tout cas la même personne est toujours active dans l’historique git des NIPS (faut pas être fin pour inventer un nom pareil). Le branding orienté “Twitter sans la censure” est encore un élément qui me refroidit, puisque c’est le plus souvent une revendication des fachos (une conception américaine de la liberté d’expression).
Je veux bien changer d’avis et je sais qu’il y a des gens très bien qui l’utilisent, mais j’ai des a priori négatifs. De toute façon ce n’est pas à moi de décider, et même si quelque chose est décidé ça peut être temporaire. Ce sont les devs de clients qui devront choisir quoi mettre dans leurs clients, in fine.
À propos de Tox, il semblerait que ce soit du grand n’importe quoi niveau cryptographie. Dans le même style, j’irais plutôt voir Ricochet Refresh, qui (si j’ai bien compris) passe en ed25519 avec les Hidden Service v3 (contre RSA avant), donc potentiellement compatible.
