Nostr aujourd’hui, c’est le chaos car il n’y a pas de structure d’identité forte. Les relais ne se parlent pas entre eux, et l’utilisateur doit espérer que ses amis sont sur le même relai que lui. C’est le point faible. Cela rend complexe et hasardeux la bonne distribution des messages.
L’avantage majeur de la Ğ1, c’est que nous avons déjà une identité forte via la WoT. Nous pouvons l’utiliser pour structurer le réseau Nostr de manière beaucoup plus saine que ce qui existe ailleurs :
Le Capitaine : Admin garant du logiciel et de la configuration du relai.
Les Utilisateurs : Qui bénéficient du service apporté par le relai et qui sont amis avec le capitaine (eux même amis avec d’autres capitaines).
Ensuite le protocole N² (les amis de mes amis) va créer une synchronisation intelligente entre relais. Au lieu d’avoir des silos isolés, les relais synchronisent les messages en fonction du graphe social des utilisateurs. C’est une couche de connectivité qui rend la distribution des messages enfin fiable et prévisible, sans centralisation.
En déployant (avec duniter) nos propres relais régionaux interconnectés par N², nous pouvons créer une infrastructure de communication aussi solide et souveraine que notre monnaie.
Je suis Niko, l’auteur de NextGraph. Merci de m’avoir invité ic i et merci pour votre interet pour NextGraph!
Comme vous l’avez compris, Nextgraph est encore en alpha, mais les choses devraient bien s’accelerer en debut 2026.
En ce qui concerne le comparatif, nous utilisont bien ed25519.
Pour ce qui de la Récusation, ce n’est pas vraiment possible dans NextGraph car tous les messages sont signés par la clé privée ed25519 de l’utilisateur (qui peut etre changée certes).
Pour la PFS, on ne l’a pas, de base, car ca pose de gros problemes insurmontables pour la collaboration sur les documents. Pour les DMs, on pourrait l’ajouter a termes. Pour les discussions de groupe, surement pas (trop compliqué, ne rajoute pas tellement de securité car souvent les groupes sont ouverts, et surtout: les utilisateurs n’aiment pas la PFS dans les groupes car quand un nouveau membre est ajouté, ce membre ne peut pas lire les anciens messages).
Pour l’intracabilité, je ne sais pas trop quoi dire car vous avez mis Session comme intraçable, donc dans ce cas, NextGraph l’est aussi car Session et NextGraph on a peut pret le meme Threat model.
Les données sont stoquées sur les appareils clients, et une copie E2EE se trouve aussi sur le broker de l’auteur, ainsi que sur les brokers des destinataires.
Pour le moment nous n’avons qu’un seul Broker car le protocole de synchronisation entre broker n’est pas fini d’etre implementé.
Mais toute la conception des protocoles et de l’architecture de NextGraph est basée sur un reseau de brokers, qui forment un Pub/Sub dans des overlays. Le tout completement chiffrés de bout en bout.
Ca n’est pas arrivé en 2025, mais ca le sera en 2026.
Le broker est dors et deja disponible en self-hosting (il faut le compiler soi-meme) pour faire des tests. mais il ne pourra pas se connecter avec d’autre borkers pour le moment.
Oui c’est correct.
Les clés des documents sont stoquées localement dans le Wallet. Elles se synchronisent avec tous les appareils de l’utiliseur automatiquement
Bien d’accord avec cette analyse.
C’est pour cette raison qu’avec NextGraph nous avons voulu resoudre definitivement le probleme de la portabilité des comptes, des identités et des données.
Meme si Nextgraph a besoin de Brokers (des serveurs) pour fonctionner, aucun identifiant n’est lié au Broker. On peut changer de broker a n’importe quel moment, et les données se deplacent sur le nouveau broker, sans qu’aucun identifiant ne change. C’est pour cette raison qu’on utilise le scheme did: et non pas http, qui lui a besoin de nom de domaine, alors que nous ne nous basons que sur des clés publiques, et le protocle IP en interne.
Sur les discussions de groupe, chiffrées ou non, ce n’est pas prioritaire.
Sur l’intraçabilité, je crois que c’était une des prétentions de Session, mais je n’ai pas vérifié.
Pour envoyer un message, comment ça marche ? On l’envoie sur le pubsub de la clé publique destinataire ? Du coup le broker sait quel est le destinataire, et puisqu’on aura besoin d’un antispam qui vérifie l’existence d’un compte blockchain associé à l’expéditeur, il sait aussi quel est l’expéditeur.
L’intraçabilité totale (aucun acteur, dont les brokers, ne peut traquer un message) me semble inatteignable sans routage en oignon ou cryptographie particulière. En revanche si les brokers sont liés à des identités membre, on peut leur faire confiance à un certain point (ce qui est de toute façon nécessaire pour la pérennité des données). Alors seul le broker qui reçoit en premier un message devra vérifier l’antispam, mais n’a pas besoin de stocker (ni de publier) la signature qui identifie l’expéditeur. Les autres brokers peuvent vérifier l’identité du broker et lui faire confiance. Seul le destinataire peut alors retrouver l’identité de l’expéditeur, si elle est indiquée dans le message chiffré.
Cette intraçabilité publique (n’importe qui ne peut pas obtenir un graphe social en demandant des données publiques aux brokers) me semble importante et suffisante, si les brokers sont suffisamment distribués et liés par un enjeu social (identifiés par la toile de confiance).
Je ne sais pas si tout ça est compatible avec le modèle de NextGraph…
En effet c’est bien le broker “home” celui sur lequel on a un compte (compte anonyme d’ailleurs dans la plupart des cas) qui va filtrer le spam, et qui va router les messages vers les brokers destinataires, sans connaitre lidentites des utilisateurs destinataires. Seul mon broker a moi, me connais (un peu). Les autres brokers ne me connaissent pas du tout.
En ce qui concerne l’identite des expediteurs, elle est toujours revelée aux destinataires. mais elle sous-entend que les 2 interlocuteurs ont deja etablis une connexion entre eux (comme une demande d’amitié. NextGraph est basé sur un reseau de confiance P2P).
Le broker n’a pas de donnees publiques, et pas de donnes en clair non plus.
Comment ca se passe pour envoye run message : il faut avoir etablit une “connexion” avec l’autre utilisateur au prealable. Cette connexion s’etablit par un QRcode qui est scann´, un lien qui est cliqué, ou un autre mechanisme (je pense que la G1 a deja son reseau de confiance donc on pourrait se baser la dessus pour faire le premier “key exchange” / connexion).
Par la suite, c’est tres simple d’envoyer un message. il y aura une API tres bientot qui le permettra. il suffit d’aller dans la lsite des contacts et choisir le destinataire. Ce mechanisme marche deja, mais je n’ai pas documenté l’API.
Cependant, afin de faciliter encore plus les echanges, et pour des raisons li´es a la crypto/securité, ce qu’on fait en pratique, c’est que lors du premier echange, on crée un document dans lequel les deux interlocuteurs sont editeurs, et ce document devient leur “chat room”, seulement pour eux 2. A aprtir de la, on utilise le mechanisme de synchronisation des documents, qui est plus simple encore, pour echanger les DMs. ca permet aussi de garder l’historique. car sinon l’inbox ne garde pas d’historique. l’inobx c’est vriament bas niveau.
Ça a l’air intéressant NextGraph, il faut creuser ça pour les datapods v2, je garde dans un coin de ma tête pour quand je m’y remettrai. Merci pour le partage de la présentation à l’OSE et merci à @nikoNG d’être passé ici ^^
Pour ma part ça va être compliqué pendant la résidence Reconnexion car je vais être sur tous les fronts. Mais ça pourrait être le vendredi 20 février en fin de journée, puisque notre résidence sera terminée et je serai probablement de retour chez moi. Par exemple vers 18h, mais je peux m’adapter s’il y a d’autres contraintes.
