Compte-rendu de l’atelier proposé par Sébastien pendant la résidence d’hiver 2026 (mardi). Synthèse générée par IA à partir d’une retranscription (disponible en bas du post), puis revue et corrigée par Sébastien.
Historique
Niko, le créateur de NextGraph, a été motivé par les révélations de Snowden. Après plusieurs engagements (Gilets jaunes, etc.), il s’est consacré au développement de NextGraph il y a environ trois ans, dont deux ans de développement pur. Depuis un an et demi, il rencontre activement des acteurs travaillant sur des projets similaires pour les fédérer.
Il a lancé un consortium européen, nommé Encrypted Local First Application (ELFA). Ce consortium, composé de treize partenaires, a récemment obtenu un financement européen de 3 millions d’euros sur 3 ans pour créer une suite d’outils de productivité sur NextGraph, en alternative aux GAFAM. L’Union européenne est motivée par les tensions géopolitiques (dépendance aux infrastructures américaines, cas du Health Data Hub hébergé par Microsoft en cours de rapatriement, etc…).
Le concept Local-First
Le Local-First désigne une architecture où les applications fonctionnent d’abord en local, sur la machine de l’utilisateur, même sans connexion réseau. Ce n’est pas du « local only » : quand une connexion est disponible, les données se synchronisent avec d’autres appareils et utilisateurs.
C’est un retour au local (comme les logiciels de bureau type Word) mais avec les avantages du cloud (synchronisation, collaboration), et en ajoutant le chiffrement des données.
CRDT (Conflict-free Replicated Data Type)
Le CRDT est un algorithme qui permet la convergence déterministe des modifications faites indépendamment par plusieurs utilisateurs sur un même document. Contrairement aux pads actuels où le CRDT est géré côté serveur, dans NextGraph le CRDT s’applique en local, sur chaque appareil. Chaque appareil résout les conflits de manière identique, garantissant un résultat final identique partout.
Limite reconnue : si deux utilisateurs modifient exactement le même endroit d’un texte en même temps, le résultat peut être « bizarre », mais l’algorithme fait au mieux pour intégrer les deux contributions. Pour des modifications sur des champs distincts (liens, photos, métadonnées d’un événement), la convergence se fait sans problème.
Architecture : brokers et chiffrement
NextGraph n’a pas de serveurs au sens classique. Il utilise des brokers : des serveurs qui stockent et relaient des données chiffrées qu’ils ne peuvent ni lire ni modifier.
Fonctionnement :
- À la création du compte, l’utilisateur choisit un broker principal (en lecture et écriture).
- D’autres brokers répliquent automatiquement les données.
- Si le broker principal tombe, un réplica peut prendre le relais, éventuellement de manière automatique.
- L’hébergeur d’un broker n’a aucune responsabilité sur le contenu (il ne le voit pas).
Toutes les données sont chiffrées, y compris les données binaires (images, vidéos). Le chiffrement se fait en local, sur l’appareil de l’utilisateur. Les clés de lecture et d’écriture sont distinctes et peuvent être partagées sélectivement avec d’autres utilisateurs (cryptographie asymétrique). Les métadonnées sont également chiffrées (end-to-end à plusieurs couches).
NextGraph n’a aucune dépendance avec le DNS : il fonctionne directement sur la couche IP (overlay).
Comparaison avec ActivityPods
L’architecture ActivityPods, actuellement utilisée par Reconnexion, repose sur des portes-données hébergés en clair chez un hébergeur de confiance (type CHATONS). Plusieurs limites ont été identifiées :
- Les données en clair sont une cible pour les hackers (centralisation du risque).
- Le choix d’un hébergeur fiable est problématique pour l’utilisateur (tendance à la re-centralisation, comme mastodon.social pour Mastodon ou le succès de Bluesky par sa simplicité).
- La portabilité entre hébergeurs est limitée.
- Toute donnée stockée en clair finit tôt ou tard par fuiter.
NextGraph résout ces problèmes par le chiffrement systématique et la réplication entre brokers, rendant les hébergeurs interchangeables et non responsables du contenu.
Web sémantique, RDF et ontologies
NextGraph enregistre les données au format RDF (web sémantique), promu par Tim Berners-Lee. Les données sont structurées selon des « ontologies » : des vocabulaires partagés qui définissent comment représenter un événement, un contact, un message, etc., sous forme de triplets (sujet — prédicat — objet, ex. « Pierre est le fils de Marie »).
Cela garantit l’interopérabilité entre applications : toute application qui connaît l’ontologie peut lire et exploiter les données sans traducteur intermédiaire. C’était, avec le contrôle des données par l’utilisateur, l’une des deux conditions essentielles pour adopter NextGraph dans le cadre du réseau social universel.
Le requêtage se fait via SPARQL, y compris des requêtes fédérées (interrogation de données réparties chez plusieurs utilisateurs). Des requêtes complexes (ex. trouver tous les contacts ayant une compétence donnée) sont déjà implémentées. La contrepartie est un temps de latence potentiellement important (jusqu’à 24h pour des requêtes fédérées, le temps que les contacts se reconnectent).
Sécurité et chiffrement
Les algorithmes de chiffrement actuels sont considérés fiables : attaqués depuis 20 ans par des chercheurs, ils n’ont pas été cassés, et resteraient résistants même avec des machines bien plus puissantes. L’asymétrie entre la puissance nécessaire pour chiffrer et celle nécessaire pour casser protège les données.
Concernant la résistance quantique : le chiffrement symétrique (utilisé pour les données) résiste aux ordinateurs quantiques. Les signatures ne résistent pas en l’état, mais un passage à un schéma hybride quantique-résistant est envisageable. Niko y réfléchit.
Pour la récupération de clés en cas de perte d’appareil, deux mécanismes sont prévus : un formulaire de questions personnelles (qui génère une clé de déchiffrement du wallet stocké chiffré sur le broker) et un social recovery (clé découpée en morceaux distribués à des tiers de confiance). Ce sujet est identifié comme l’enjeu le plus sensible par les participants.
Modèle économique et coûts
L’hébergement d’un broker est peu coûteux pour un usage modeste : de l’ordre de 30 € par an pour quelques centaines d’utilisateurs avec des données légères (texte, métadonnées, photos). Le coût augmente proportionnellement au volume de données stockées (la vidéo étant le plus lourd).
Plusieurs modèles sont envisagés : hébergeurs associatifs (gratuits ou mutualisés), hébergeurs professionnels (payants), auto-hébergement via une box à domicile (business model envisagé par Niko), ou financement par les collectivités. Les utilisateurs ne sont pas captifs : ils peuvent changer de broker à tout moment.
Implications légales
L’architecture local first déplace la responsabilité légale : le broker ne voit pas le contenu, il n’est donc pas soumis aux obligations de modération ou de vérification d’âge qui pèsent sur les hébergeurs classiques. Il reste soumis à l’obligation de conservation des logs de connexion (IP, horodatage).
Le risque réglementaire identifié est le déplacement de la pression vers les développeurs d’applications, avec des tentatives législatives d’imposer des backdoors avant chiffrement. L’histoire du chiffrement (tentatives d’interdiction de niveaux élevés dans les années 2000) montre que la technologie a jusqu’ici dépassé les contraintes réglementaires.
État d’avancement
NextGraph est en version alpha. La version bêta est prévue avant l’été. La communication inter-brokers n’est pas encore implémentée (un seul broker fonctionne de manière autonome pour l’instant). Il n’y a actuellement qu’un seul broker européen en service.
Questions ouvertes
- Gestion fine de la synchronisation sur mobile (stockage limité) : paramétrage sélectif probable mais à confirmer avec Niko.
- Architecture DHT comme alternative aux brokers : Niko n’a pas retenu cette option, question à lui poser.
- Contacts avec Framasoft / CHATONS pour le déploiement de brokers : pas encore à ce stade.
- Cadre juridique à construire en parallèle du développement technique.
Transcription améliorée (par IA)
Sébastien : Je remets le warning, je ne suis pas expert de NextGraph, on va avoir un call avec Niko jeudi soir au point cuisine. Il va pouvoir répondre aux questions pointue. Là l’idée c’est plutôt d’essayer un peu de débroussailler aussi, de comprendre qu’est-ce qu’il y a comme différence entre NextGraph et ce qu’on a actuellement, qu’est-ce que ça permet en plus, quels sont les avantages. Un peu comprendre, voilà. Donc, l’idée, c’est de la vulgarisation. Mais je pense que ça peut être aussi intéressant pour les personnes qui sont déjà au niveau de la compréhension en français. Je le dis là aussi, peut-être que vous avez fait un livre, c’est très bien aussi, plutôt que de répondre aux questions, c’est de laisser les autres répondre. Donc, peut-être que je vais aussi faire ça.
Sébastien : Et donc là, c’est juste le site, ça permet de voir un peu de quoi il parle, les différentes clés, et puis de vous approfondir et de mieux prendre ça. Et on a la chance d’avoir Sylvain avec nous, qui est quand même, ça fait quand même… Pas mal d’années que tu aies toutes ces questions-là aussi, d’étudier différentes solutions de ce type-là, et finalement de voir que NextGraph semble répondre à ce que tu cherchais depuis 20 ans. J’ai dit récemment 15 ans. C’est déjà pas mal.
Sébastien : NextGraph d’ailleurs, en parenthèse, c’est un écho, donc c’est quelque chose que je connais bien depuis 8 ans. On a fait des choses ensemble, etc. Et lui, ce qu’il a activé, c’était les révélations de Snowden. Il avait arrêté de faire du développement, il avait plein d’autres projets, etc. Et quand il a vu ça, il a dit, il faut faire quelque chose. Et quand il a vu que personne d’autre ne faisait ce qu’il fallait, il a eu pas mal de mouvements, il a aussi été, à un moment, c’est ce que je disais à Amélie, il a été… Il a fait une place pour les Gilets jaunes, il a fait un nombre de trucs et puis finalement il a… Voilà, du coup il y a trois ans il s’est mis au développement de scratch, donc ça a pris deux ans pour le faire. Et du coup depuis une année, une année et demie, il a été beaucoup beaucoup sur le fait de discuter avec le maximum d’acteurs qui faisaient des choses similaires. C’est un plan, des fois il manque une petite brique, des fois c’est très similaire, mais voilà, il a essayé d’en embarquer pas mal. Et donc là, récemment, il a quand même réussi.
Sébastien : A lancé un consortium qui s’appelle Everything Local First Application, maintenant c’est Encrypted Local First Application. Et du coup, ils vont avoir 3 millions et 3 ans. Partenaires pour créer une suite. Pour tous les outils de productivité qu’on trouve actuellement chez les GAFAM, pour que ça puisse passer sur une architecture comme ça. L’Union européenne est prête à financer ça parce qu’il y a une grosse pression quand même avec la bataille qu’il y a eu avec Trump, etc. Il y en a quand même qui ont commencé à capter en disant si c’est les États-Unis qui décident de couper. Donc, pour ce moment, ils pourraient couper tout Internet. Le nombre de mails, c’est pas sûr que ça pourrait encore fonctionner s’il y avait vraiment une guerre. Donc, ça crée de la tension. C’est aussi pour ça qu’ils sont en train de voir que même le Health Data Hub, qui était hébergé par Microsoft, là, d’ici à la fin de l’année, ça devrait être rapatrié. Donc il y a quand même une grosse pression pour les Européens.
Sylvain : Et là-dessus, on peut d’ailleurs ajouter dire que NextGraph n’a aucune dépendance, en fait, avec ce genre de choses-là, même pas avec le système DNS. C’est que du overlay. C’est au niveau réseau, ça utilise les IP, mais rien de ce qui est au-dessus du web existant.
Sylvain : C’est pas juste ça.
Locuteur 5 : C’est juste la couche basse, Internet.
Sébastien : Alors là, il y a déjà quelques mots-clés qu’on voit. Là, c’est les partenaires. Il n’y a pas de problème. Sur NextGraph, on voit encore des mots-clés. Peut-être le premier quand même, c’est le Local First. Donc, local first, qu’est-ce que c’est ?
Locuteur 6 : Est-ce que tu peux me dire si vous, moi, j’ai un… De ma compréhension de ce que c’est que Local First. C’est une application qui est conçue pour pouvoir, en premier lieu, fonctionner sur une machine déconnectée de tout réseau. Et le local first, on va aussi dire pas local only, prévoit de pouvoir interagir avec d’autres choses par réseau, mais c’est du local first. Donc avant tout, ça peut fonctionner en local. Et je pense qu’il y a quand même la notion de réseau de quand il y a une autre instance local first, les deux peuvent communiquer ensemble quand il y a une liaison réseau qui se fait. Donc il y a des mécanismes de synchronisation pour ça.
Sébastien : Et historiquement, on dit justement qu’au début, les applications, c’était sur les ordinateurs. C’était du vrai… Word, etc. Et on créait nos documents, donc on était habitués à ça. Ce qui est bien, c’est qu’on pouvait fonctionner sans Internet. Le problème, c’est que les documents étaient que sur notre ordinateur. Si on avait un problème, on perdait tout. Et puis, ce n’était pas collaboratif. Et donc, au fur et à mesure des années, quand on est arrivé sur le cloud, qui sont juste des serveurs, des gros serveurs, et bien en fait, de plus en plus, il y avait des applications où c’était entièrement, tout était, c’est-à-dire que si tu avais une mauvaise connexion internet, tu n’avais plus accès à rien, alors après ils ont essayé de faire des… Ils ont essayé, il y a des techniques de cache. Du coup, il y avait besoin de synchronisation pour essayer de pallier au moment où il n’y a plus de connexion, etc. Mais ça restait problématique. Et du coup, le local first, c’est on revient sur le local, c’est-à-dire que… On revient sur le local, mais on peut se synchroniser, ce qui offre deux avantages. Donc, grosso modo, mes données sont créées localement, et ensuite elles sont synchronisées sur des serveurs, mais encryptées, parce qu’on n’a pas envie que les serveurs voient nos données. Et là, il y a deux avantages. C’est que déjà, si on a des documents sur plusieurs appareils, il n’y a aucun souci pour travailler avec plusieurs appareils. Voilà.
Locuteur 7 : Est-ce que dans le concept de local first, ça inclut la notion d’identité, le collectif et le…
Sébastien : Je pense que c’est le cas.
Sébastien : Donc voilà, et puis l’autre avantage c’est que ça peut faire des choses collaboratives, c’est-à-dire que s’il y a d’autres utilisateurs qui peuvent travailler sur le même document. C’est quand même quelque chose qui maintenant est un peu plus intéressant, les pads, des choses comme ça, c’est quelque chose qui est quand même très utile et qu’on voit sur l’évolution de faire des outils collaboratifs. C’est très intéressant. Et peut-être que ça peut être l’occasion d’expliquer les CRDT.
Locuteur 8 : Vas-y. CRDT, c’est Conflict-free Replicated Data Type. En fait, c’est tout un concept qui est plus… Je peux le refaire. Conflict-free Replicated Data Type. C’est CRDT. En fait, c’est tout un concept pour le temps réel. Mettons, toi, tu travailles sur un document, une autre personne travaille sur un document. On a le même curseur, le curseur au même endroit. Si on écrit en même temps, il faut un mécanisme qui puisse être sûr qu’on ne mélange pas tout et que ça met bien les données au bon endroit pour chacun.
Locuteur 2 : On a ce problème-là sur les pads.
Locuteur 8 : C’est ça, les pads utilisent du CRDT pour pouvoir résoudre ce problème-là avec des notions de latence réseau. Si jamais tu écris et que finalement le temps que ça arrive sur l’autre personne, ça met deux secondes, il faut un mécanisme qui puisse gérer tout ça et remettre bien les choses dans l’ordre. Sinon, ça va tout mélanger. Voilà, ça permet de résoudre ces conflits de latence réseau et de temps réel. C’est du temps réel tout ça. Et en lien avec le local first.
Sylvain : Voilà, dans le local first, du coup, on a ce problème, même hors temps réel, parce que justement, on travaille en local, et du coup, on a des données qu’on a localement, mais il y a une personne qui était en train de travailler sur le même document, localement lui aussi, parce qu’on est tous les deux hors réseau, et à un moment donné, il faut faire converger tout ça en une seule version, qui intègre ce qu’a apporté chacun. Donc c’est vrai, il faut l’indiquer, c’est qu’on n’est même pas en temps réel. Mais il faut absolument que ça converge et que ça ne dise pas à un utilisateur « Ah ben non, désolé, ça a été modifié par quelqu’un d’autre, tu dois annuler tout ce que tu as fait et reprendre l’autre version et recommencer à travailler. »
Sébastien : Il y a une technique pour ça, non ?
Sylvain : C’est le CRDT qui permet ça.
Sébastien : Sauf que là, contrairement aux pads, si je ne me trompe pas, les pads qu’on connaît actuellement, le CRDT se fait au niveau du serveur. Qui reçoit les différentes informations, alors que là, ça s’applique en local. C’est-à-dire qu’il n’y a pas de serveur qui va dire, ok, c’est toi qui gagnes sur ça, etc. C’est au niveau de chaque appareil. Du coup, chaque appareil, au début, celui qui a travaillé sur l’utilisateur A, qui a commencé à travailler, il reçoit les données de l’utilisateur B. Et après, parallèlement, il y a l’utilisateur B qui reçoit les données de l’utilisateur A. Il faut que le résultat entre les deux soit exactement le même. Parce que sinon, tu te trouves avec des documents qui ne sont pas les mêmes. Donc c’est cet algorithme-là qui permet de s’assurer qu’il y a une sorte d’assurance que les données vont toujours se synchroniser de la même manière sur tous les appareils.
Sylvain : C’est vraiment déterministe. Chacun va faire la même chose de son côté, mais ça va donner forcément le même résultat.
Sylvain : De toute façon, il n’y a pas de serveur du tout. Il n’y a pas de relais. Il y a des relais, mais ils ne font pas de calcul. Ils reçoivent des données chiffrées et ils peuvent les partager, mais ils ne peuvent pas les modifier. Je pense qu’on verra ça après.
Locuteur 9 : Et quand il y a des modifications de la même… Par exemple, le premier utilisateur fait une correction dans un sens, et l’autre fait sur le même espace.
Sylvain : Ça fait quand même pas de… Si les deux agissent vraiment dans le même endroit, ça peut faire quand même quelque chose de bizarre. Si les deux sont modifiés au même moment, c’est quand même quelque chose de bizarre. Mais ça fera au mieux pour que ce soit une convergence des deux modifications. Si jamais elles sont sur deux lignes différentes, par exemple, ça ne posera aucun problème.
Sébastien : Après, le cas des textes, c’est le truc potentiellement le plus problématique parce que ça peut créer des trucs un peu bizarres avec un mot qui a été rajouté, etc. Après, dans beaucoup de cas, ça peut être quelqu’un qui a rajouté un lien sur un projet. Souvent, ça va s’harmoniser quand même plutôt bien. Si on imagine par exemple, on a chez nous des événements, du coup si on imagine qu’il y a deux utilisateurs qui peuvent modifier l’événement, il y en a un qui va rajouter un lien, va faire quelque chose d’autre, il y a une photo, etc. Puis il y en a un qui fait autre chose, du coup ça va s’harmoniser.
Locuteur 6 : Est-ce que sur le côté totalement déterministe, c’est basé sur un temps commun ? Ou est-ce que, justement, vu que d’une machine à une autre, il y a des décalages, c’est juste une notion d’antériorité de contenu qui permet d’avoir un comportement déterministe ?
Locuteur 10 : Il y a plusieurs règles, ça dépend du type de contenu. Il y a des contenus qui vont être en graphe.
Sébastien : Il y a plein de… Est-ce qu’au niveau des gens qui sont nettement moins techniques, est-ce qu’il y a des choses là qui vous dépassent complètement, vous avez besoin d’explications ?
Sébastien : Ce n’est pas du côté technique, c’est quand tu as dit que c’était Niko qui avait quasiment créé le consortium. J’aimerais bien comprendre la place de Niko dans le consortium historiquement et maintenant.
Sébastien : Oui, alors, au solo, Niko, comme je disais, une fois qu’il a fini la première version de NextGraph, il a passé beaucoup de temps à rencontrer, soit en visio, mais soit aussi dans les… Et rencontrer physiquement, beaucoup d’acteurs, et ceux qu’il a réussi à embarquer avec lui, il les a embarqués dans ce consortium, et du coup, le but du consortium, ça va être de créer des applications sur NextGraph. Mais c’est des acteurs qui faisaient aussi des choses un peu différentes.
Sébastien : Et Reconnexion, qui n’est pas partie encore du consortium ?
Sébastien : Pas de celui-là, parce qu’on n’était pas prêts à l’époque où ça s’est fait. Maintenant, au niveau de l’Union européenne, c’est les treize acteurs qui ont candidaté. Le consortium, c’était pour répondre à l’appel.
Sylvain : C’est un consortium pour obtenir un financement européen. Il est vraiment orienté pour cet appel. Il y a un rapport de l’État qui est en train de travailler sur le sujet.
Sébastien : Oui, parce qu’il a aussi eu des contacts avec des gens qui travaillaient dans l’Union européenne, qui ont vraiment compris l’intérêt de ce qu’il faisait, etc.
Sébastien : C’est vrai qu’au début, quand il m’a parlé, moi, je n’y croyais pas du tout.
Sébastien : Peut-être par rapport à l’aspect local first. Par rapport à l’aspect local first, il y a le… Ce qui est aussi intéressant, je trouve, dans la dynamique… à la fois de… Enfin… Donc c’est le fait qu’il n’y a plus de serveur. Donc en fait il n’y a que des serveurs qui se contentent de prendre des données, qui reçoivent des données qui sont encryptées, donc encryptées avec la clé de l’utilisateur. Donc il n’y a que l’utilisateur qui peut les lire. Après il peut donner des clés à d’autres utilisateurs pour dire je te donne le droit de lire cette donnée. Donc là c’est ce qu’on appelle la cryptographie asymétrique. C’est des clés qui permettent de déchiffrer la donnée. Si tu n’as pas la clé, tu ne peux pas déchiffrer la donnée. Et il y a aussi des clés qui permettent d’écrire les données. Si tu n’as pas la clé, tu n’as pas le droit de modifier la donnée. Donc c’est ces deux types de clés, avec tout un système complexe, notamment pour l’édition, où là il faut une sorte de rotation, notamment quand il y a des nouvelles données qui sont ajoutées, il faut faire tourner toutes les clés, pour ça là on est dans des sujets techniques. Et laissons Niko en rendre compte.
Locuteur 11 : Par rapport à ce qui est présenté sur le site web, ça en est où ? De l’avancement ? Est-ce qu’on parle d’un truc qui est embryonnaire ?
Locuteur 12 : Un truc qui est déjà en prod, exploitable.
Sébastien : Là, c’est une version alpha et la version bêta doit sortir avant l’été. Donc la version bêta, normalement, c’est une phase où on commence à… On continue à être dans une phase où c’est pas complètement stable, etc. Mais c’est plus alpha où il y a potentiellement tout qui peut encore changer sur les manières de faire. En bêta, normalement, on est plutôt sur les ajustements. C’est ça. Après, pour l’instant, une chose qui manque, par exemple, c’est la communication entre les brokers. Alors peut-être qu’on peut parler des brokers, comment…
Locuteur 1 : Oui, alors…
Sébastien : Donc le fait de ne plus avoir de serveur, c’est intéressant parce que déjà, c’est aussi ce qu’on a… Voilà, ça c’était une des limitations qu’on a explorées avec ActivityPod. C’est du coup toute l’architecture de dire, on va avoir des hébergeurs de pod de données qui vont du coup être responsables de nos données. Donc ça c’était l’architecture sur laquelle on s’appuyait avec ActivityPod. Potentiellement l’hébergeur il a accès à nos données parce que les données ne sont pas encryptées. Donc on disait, on va être plutôt dans une architecture type CHATONS, ou alors des petites assos, voire des familles, des collectifs, etc. Du coup on est chez un hébergeur local, on fait confiance, et du coup on est ok pour mettre nos données potentiellement accessibles à la personne qui nous héberge. Elle peut faire des choses malveillantes, mais on a confiance qu’elle ne va pas le faire.
Sébastien : Malheureusement, en fait, cette architecture, elle peut vite trouver des limites. Alors déjà, parce que… Déjà parce que ces données-là personnelles vont devenir une cible de choix pour les hackers. Parce que généralement les hackers, régulièrement ils piratent sans arrêt des sites. Il y a un site qui s’appelle « Bonjour la fuite », je ne sais pas si vous le connaissez. Ça répertorie tous les jours les 3-4 sites qui ont eu des données piratées. Des fois c’est les fédérations sportives, des fois c’est l’URSSAF, France Travail, tout ça. Et du coup ce qui les intéresse c’est plus il y a de données personnelles, c’est-à-dire s’il y a juste un prénom et une adresse mail c’est pas très intéressant, si par exemple il y a une adresse postale, s’il y a une date de naissance, plus il y a de données en fait plus ça leur donne tout un contexte sur la personne et plus ça devient possible de faire des attaques un peu poussées genre je t’envoie un mail en disant je connais ta date de naissance je connais ta vie, ta femme, tous ces trucs-là et du coup ça donne la confiance où on t’appelle et on te dit voilà il y a ta fille qui vient d’avoir un accident, on peut imaginer plein de trucs et du coup ça crée des failles pour attaquer.
Sébastien : Et là, le problème avec l’architecture en pod de données, qu’on promeut en réseau social universel, c’est que du coup, toutes les données sont dans un endroit. Donc quelqu’un qui réussit à accéder à ce pod de données, en fait il a accès, si on imagine que ça marche, dans une optique où cette architecture prend vraiment, il y a plein d’applications, du coup il y a des montagnes de données personnelles qui sont au même endroit. Donc ça devient des cibles d’attaque très importantes, et du coup ça demande que les hébergeurs aient vraiment des bonnes pratiques sur la manière dont ils gèrent leur… les clés de leur serveur, les mots de passe, les machins, et qu’ils ne se fassent pas avoir. Et du coup, en fait, il y a un risque que ça amplifie plutôt le besoin d’avoir des hébergeurs de confiance, de confiance dans le sens qu’ils sont suffisamment pros, qu’ils sont gros, etc. Et du coup, ça peut aller un peu comme avec Mastodon actuellement, où en fait, il y a presque tout le monde qui va sur mastodon.social, parce que c’est le serveur qui est un peu officiel. Et du coup, ils se disent, bon, celui-là, au moins, on est sûr qu’il va rester. Alors que les autres, en fait, ils peuvent du jour au lendemain tomber. Donc il y a toute une problématique aussi quand tu choisis un hébergeur de confiance, c’est de choisir le bon. C’est ça le blocage principal. Pourquoi d’ailleurs Bluesky a marché mieux que Mastodon ? C’est à cause de ça, parce que Bluesky n’avait pas ces frictions.
Sébastien : Et voilà, donc du coup, nous, on a la même problématique. Les utilisateurs vont dire, mais quel hébergeur vous choisissez ? Sur quelle base ? Du coup, s’il n’y a pas d’hébergeur près de chez eux, comment est-ce qu’ils font ? Est-ce qu’ils vont choisir n’importe quel hébergeur ? Voilà, donc en fait, tout ça, ça ajoute des étages de complications. Et puis au final, il y a une phrase qui se dit un peu dans le milieu, qui dit que dès qu’une donnée est stockée en clair, en fait, tôt ou tard, elle fuira. Parce que si tu vois, vu que tous les jours, il y a des données qui fuient, tu vas partir du principe que tôt ou tard ça fuitera. Donc, c’est pas terrible.
Sébastien : Donc tout ça, ça fait que si demain, on proposait le réseau social universel avec des pods de données sur des hébergeurs de confiance, en fait, on risque très vite d’arriver au stade où il y a en fait, je ne sais pas, en Europe, 3-4 gros gros hébergeurs qui ont accès à des millions de données d’utilisateurs. En fait, on est pratiquement dans la même situation que les GAFAM. On fait confiance à quelqu’un pour avoir accès à tout. C’est aussi en partie pourquoi on s’est dit que c’était important d’aller sur les…
Sébastien : Avec NextGraph, pour revenir sur la question des serveurs, il y a des serveurs, mais en fait les héberger, c’est rien du tout, parce que c’est comme les nœuds de la Monnaie Libre, ça ne demande pas une expertise particulière. Et puis si le nœud tombe, il n’y a aucun souci, parce que… du broker en l’occurrence, parce que nos données sont automatiquement répliquées. Pour clarifier un petit peu, il y a quand même un serveur principal qui est là où se retrouvent toutes nos données. Donc quand on se crée un compte, au début on choisit un serveur principal. Et ça c’est important, d’ailleurs sur tous nos appareils, c’est toujours ce broker qui va être le broker en lecture et en écriture. Et après, naturellement, il y a d’autres serveurs qui vont répliquer les données. Ce qui fait que si le serveur principal à un moment il tombe, on peut très facilement dire, ça peut se faire même automatiquement, on switch le serveur principal et ça devient un autre serveur qui devient le serveur sur lequel on va écrire.
Sébastien : Donc ça fait que pour l’hébergeur, il n’y a pas de pression, c’est-à-dire, tiens, j’ai envie de contribuer, j’ai un serveur, je le mets à disposition pendant un certain temps, à un moment, j’ai d’autres choses à faire, ça ne m’intéresse plus, j’arrête. Du coup, ce n’est pas que les données de 10 utilisateurs sont perdues. On avait prévu un mécanisme pour qu’on puisse migrer, mais cette migration, ça fonctionnerait à condition que l’hébergeur ne disparaisse pas du jour au lendemain. Et puis même si à un moment quand même il disparaît, il peut y avoir quand même des problèmes comme avec Mastodon en fait. J’ai fait un webinaire précisément sur ces questions-là, la portabilité dans Mastodon. C’était un webinaire sur l’interopérabilité en général et la portabilité sur Mastodon, en fait, ça avait des grosses limites. Nous, on a relevé la limite. Alors qu’avec les brokers de NextGraph, on n’a pas ce problème.
Locuteur 13 : C’est quoi la différence entre l’hébergeur et le serveur ?
Locuteur 13 : L’hébergeur, c’est celui qui gère le serveur.
Sébastien : Oui, c’est comme ça qu’on l’appelle, sauf que là, avec NextGraph, c’est un hébergeur. Il n’y a pas ce côté-là, je suis responsable de tes données. Et même, je suis légalement responsable. Parce qu’il y a des lacunes sur le plan légal. Voilà. Donc si le serveur arrête, ce n’est pas un souci. C’est une sorte de résilience. Le fait que même si la moitié des serveurs tombent, c’est pas grave, ça continue. La blockchain, c’est pareil. Je ne sais pas combien il y a de serveurs actuellement, mais même si il y a la moitié des nœuds qui disparaissent, ça continue à tourner.
Locuteur 14 : J’entends une contradiction un petit peu dans ce que tu disais. Tu disais que là, contrairement à ActivityPod, on n’a plus les données à un seul endroit comme un CHATONS. C’est en local first, mais tu dis en même temps qu’il y a un premier broker où toutes nos données sont dessus.
Sébastien : Et elles sont cryptées.
Locuteur 14 : Mais la nuance que tu mets, c’est qu’elles sont chiffrées. Voilà. Et est-ce que toutes les données sont chiffrées ? C’est-à-dire que même si je veux partager un film, dans le cas où…
Sylvain : Ce film va être chiffré aussi ?
Locuteur 15 : Oui, les données binaires sont chiffrées aussi.
Sylvain : Donc il doit y avoir une forte charge des serveurs, j’imagine, pour chiffrer des grosses données, si je mets un film en…
Locuteur 15 : C’est chiffré en local.
Sylvain : C’est chiffré en local, oui. C’est chiffré en local. Donc il faut que j’aie même une machine assez puissante pour chiffrer, pour hacher et chiffrer les données.
Sylvain : La raison pour laquelle aussi, toutes les données sur un broker, c’est que ça permet facilement de se synchroniser entre ses différents périphériques. Et que si on perd son téléphone, et que l’on a peut-être que ça comme périphérique pour accéder à ces données, elles ne sont pas perdues, elles sont toujours sur son broker. Ça les sauvegarde derrière.
Sylvain : Et moi, j’ai une autre question.
Locuteur 6 : Moi, la question que j’ai autour de, justement, cette notion de serveur principal par rapport aux autres, tu disais qu’on peut facilement en changer. À quel point on peut facilement en changer, dans le sens, si par exemple, je fais une application qui utilise NextGraph et qui regarde parmi les différents brokers, c’est lequel celui avec lequel il y a le meilleur ping et qui se dit, bon ben, je dis c’est celui-là le master et puis je me balade et puis le lendemain je me reconnecte sur l’appli et puis ok c’est plus la même, c’est celui-là le principal. À quel point la migration se fait avec autant de fluidité, ou est-ce qu’il y a quand même un peu plus de friction, il y a un principal qui a une responsabilité un peu plus élevée, c’est quoi là ? En gros qu’est-ce qui différencie principal de autre et pourquoi il y a besoin de cette notion de principal ?
Locuteur 6 : Alors si tu veux passer sur un serveur sur lequel tu n’as aucune de tes données, il va y avoir un peu plus de temps, c’est possible, c’est ce qu’on a vu au cours de la semaine, mais c’est juste que du coup ça prend un peu plus de temps, parce que si tu as déjà tout qui a été répliqué, après il suffit de basculer, c’est très rapide de changer de serveur.
Sylvain : Les réplicas, c’est un mécanisme de failover. Il y a un master et des slaves. Il n’y a qu’un seul qui peut écrire pour un utilisateur donné. Moi, j’ai choisi que c’était mon serveur principal. Je peux changer, mais il ne faut pas qu’il y en ait deux qui écrivent pour moi. Ok. Et donc, il y a cet aspect-là. Et ensuite, si je veux changer vers un serveur qui n’a pas mes données, donc qui n’est pas un réplica actuellement, il va falloir faire toute une migration de données selon le volume de données que j’ai.
Locuteur 13 : Toujours pour les nuls, c’est peut-être idiot pour les gens qui ont un bon niveau. Toute la confidentialité de mes données est basée sur le cryptage ou le chiffrage. Toute la guerre de 40, ça a été que des guerres de chiffrage qui ont été déchiffrées. Quelles sont les garanties du non-déchiffrage ?
Locuteur 16 : Je désignais Sylvain dans le sens, ça me paraît être la personne qui me paraît la plus compétente pour fournir des réponses. Les années 40, c’était le début du chiffrement et il n’y avait pas de… Pas d’algorithme prouvé fiable. Aujourd’hui, les algorithmes, ça fait 20 ans, ça fait 20 ans qu’ils sont attaqués par des chercheurs qui essaient de les casser, on n’arrive toujours pas à les casser. On pense que même avec des ordinateurs, peut-être 1000, 1 million de fois plus puissants, on n’arrivera toujours pas à les casser. Donc tant qu’on respecte les standards du chiffrement d’aujourd’hui, ça devrait être fiable.
Sylvain : Il y a une grande asymétrie entre la puissance qu’il faut pour chiffrer et la puissance qu’il faut pour déchiffrer. Et tant qu’on a ça, ça protège. Et cet aspect-là, il y en a un autre, c’est qu’il faut aussi déjà accéder aux données. Donc on a deux niveaux de protection. Ça dépend de qui on veut se protéger. Si on veut se protéger des hébergeurs, il y a un niveau. Si on veut se protéger de l’extérieur, il y a quand même un niveau. Les données ne sont pas propagées en clair sur Internet.
Locuteur 17 : C’est peut-être un peu hors sujet, mais c’est important. Est-ce que c’est quantique-résistant ?
Locuteur 16 : En tout cas, le chiffrement, ça résiste… Le chiffrement symétrique, pour chiffrer un giga de données, c’est ce qu’on utilise, ça résiste à un ordinateur quantique. Après, c’est tout ce qui est échange de clés ou les signatures. Ça, ça ne résiste pas, mais c’est possible de passer sur un schéma hybride qui résiste à un ordinateur quantique.
Locuteur 11 : Je crois que la question avait été posée à Niko lors de l’apéro au 47. Il avait dit que c’était prévu, il y réfléchissait.
Sébastien : Il y a une autre chose qui est aussi importante par rapport au besoin d’avoir des serveurs, c’est que souvent il y a l’idée de peer-to-peer. Donc, d’ailleurs, il n’utilise pas ce terme, c’est-à-dire le peer-to-peer, c’est-à-dire plutôt que de passer par des serveurs, tu communiques directement. Tu peux dire souvent, on n’a pas de serveur, on a un téléphone, on communique directement avec l’autre. Mais le problème pour ça, il faut que les deux appareils soient en ligne et disponibles. Et ça, c’est, en fait, dans beaucoup de cas, c’est pas le cas. Si tu envoies un mail à quelqu’un, c’est utile de passer par un serveur parce que comme ça tu envoies dans sa boîte aux lettres sur son serveur et quand il se connecte il va récupérer son mail. Si tu essaies de lui écrire directement et qu’il n’est pas connecté tu vas avoir une erreur et du coup il faut attendre que les deux soient connectés en même temps. Donc ça va être important, le fait de passer par un serveur, ça permet d’avoir une sorte de boîte aux lettres. Et du coup il y a aussi la communication, on a parlé de documents partagés mais il y a aussi la possibilité d’échanger, d’envoyer des messages, de communiquer entre utilisateurs et du coup là il faut que tu envoies sur cette boîte et le serveur il attend le moment pour après envoyer les données à l’utilisateur, il attend qu’il soit en ligne. Donc ça c’est vachement important pour avoir quelque chose qui fonctionne.
Locuteur 14 : Le plus gros souci souvent du chiffrement de bout en bout, c’est le perfect forward secrecy. Si je perds ma clé, moi je crée mon compte en local, je vais me connecter à un broker, je vais envoyer mes données chiffrées. Si je perds mon appareil, je perds ma clé de chiffrement. Est-ce qu’il y a un mécanisme de secret forwarding qui est en place pour… Pour si jamais je perds ma clé de chiffrement, comment ça se passe ? Est-ce que c’est des CRDT ? Est-ce que ça rentre dans le scope du CRDT pour savoir… Pour savoir est-ce que j’ai plusieurs possibilités d’avoir plusieurs clés de chiffrement par session ? Est-ce que vous savez ça ?
Sylvain : Les détails des clés de chiffrement par session, non, mais il y a une notion de wallet que j’ai sur mon appareil, sur lequel j’ai créé mon compte, qui contient les clés maîtresses qui permettent de déchiffrer tout le reste, par exemple, l’ensemble des clés. Et ce wallet, je peux le transférer sur un autre appareil. Et à partir du moment où il est actif sur deux appareils, toutes les données sont synchronisées entre les deux appareils. Ça c’est une première chose, c’est pour l’utiliser sur plusieurs appareils en même temps. Et après, Niko a prévu des mécanismes pour si l’on perd une donnée, via des choses qui pour nous, les utilisateurs, sont un peu habituelles, c’est répondre à un ensemble de questions à l’avance, avoir préparé des questions de… Le prénom de ma femme ou quelque chose comme ça. Et ça, ça permet de générer une clé qui va servir à déchiffrer. Pour avoir ça, il faut avoir le wallet qui est présent sur le broker, mais qui est chiffré.
Locuteur 14 : Le wallet de la clé privée ?
Sylvain : Le porte-clé de ces clés. Oui, l’ensemble des clés chiffrées, surchiffrées avec la clé qui vient du formulaire. Donc il a prévu des mécanismes un peu comme ça, où il est possible d’avoir le wallet qui est sur le serveur, ce qui ne doit pas arriver normalement, on est dans du local first, mais chiffré. Alors il y a ce mécanisme-là, le formulaire. Il envisage aussi une solution qu’il appelle le social recovery, je crois, où il y a une clé qui est découpée en plusieurs morceaux, qui est passée à plusieurs personnes.Et cette clé sert à chiffrer le wallet là aussi, et qui est mis en sécurité sur le serveur.
Locuteur 14 : Ça, ça va être pour moi l’enjeu le plus crucial, le plus sensible. C’est toujours ce qui pose le plus de problèmes. Récupérer les clés. Non mais ce ne sont pas des mots de passe, ça c’est chiffré. Il doit être chiffré. Comment je les déchiffre si je n’ai plus ma clé ? J’ai hâte de voir en détail.
Sylvain : Tout le monde attend ça aussi. Il y a plein de gens qui sont emballés par son truc. Oui, mais il n’y a pas encore ça. Nous, on ne veut absolument pas. Il comprend, mais…
Locuteur 18 : J’ai deux questions. Est-ce qu’il y a un risque, justement, qu’il y ait une forme de spéculation pour arriver à récupérer des bouts de clé distribués en échange de rançon ? Avec du vrai argent, on se dit, tiens, là, on te donne des sous, tu nous donnes un bout de clé. Est-ce qu’il y a un risque par rapport à ça ?
Sébastien : Ce qu’il a parlé de social recovery, c’est un truc… Il y a plein de manières de le faire. C’est vraiment un sujet un peu…
Locuteur 18 : D’accord. Et l’autre chose, c’est… Il disait tout à l’heure que, en fait, pour une question aussi d’économie de ressources et de ne pas s’appuyer sur le peer-to-peer, en fait, c’est attendre que les appareils soient en ligne. C’est pour ça que ça passe par des serveurs pendant ces temps-là. Et vous disiez que ça ne posait pas de problème particulier, mais que ça prenait quand même plus de temps si on voulait que les données soient vraiment migrées d’un serveur à un autre. Donc, est-ce que là, il y a un point de questionnement important ? Si tout le monde se mettait d’un seul coup à dire, sur les futures applications, on veut tous migrer nos données.
Locuteur 19 : Est-ce que ça ne créerait pas un…
Sylvain : En fait, Niko explique que cette histoire de serveur, ça va être des hébergeurs en fait. Donc ça va être des hébergeurs associatifs, ça va être des hébergeurs professionnels qui vont faire payer, parce qu’ils stockent des gigas et que du coup ils pourront légitimement faire payer. Il dit que tout ça, ça n’a pas d’importance. Il faut qu’il y ait des acteurs qui le proposent, qu’il y ait une diversité d’acteurs et que chacun soit libre d’aller chez qui il a envie d’aller et de le faire soi-même.
Sébastien : Et lui, il aimerait bien faire une… Pour une fois, il aimerait bien… Ça pourrait entrer dans le business model de ce qu’il fait, c’est de proposer des box. Tu peux mettre dans ton salon et du coup, tu n’as plus ce problème-là. Tu as ta box qui peut fonctionner avec ta box internet, en fait, que tu branches dessus. Et du coup, tu peux héberger tes données. Et tu peux voir que tu as réglé le problème. Et tu peux aussi héberger, par exemple, ta famille.
Locuteur 6 : En lien avec ce que tu disais en matière de transfert d’un serveur à un autre, etc. Est-ce que c’est par simplicité, dans un premier temps, que tout est sur un serveur ? Ou est-ce qu’il y a un obstacle architectural à passer sur un système plus DHT, distribué entre différents…
Locuteur 20 : C’est une question pour Niko. Oui, c’est ça.
Sébastien : Et d’ailleurs, je tiens à dire qu’il y a une question de qu’est-ce qui est implémenté, etc. La communication entre serveurs, ça c’est un truc qui est déjà, enfin, il sait exactement comment il va le faire, mais c’est pas encore implémenté. Pour l’instant, il y a un serveur qui fonctionne avec lui-même, et tu peux déployer ton propre serveur, mais ils n’ont pas de communication. Et ça, c’est juste que ce n’est pas une priorité par rapport à ce qu’il fait.
Sébastien : Peut-être un truc qui n’a pas été mentionné et qui est important, c’est que du coup, une des particularités de NextGraph, qui s’appelle Graph, c’est qu’il enregistre les données avec ce qu’on appelle le web sémantique. Et ça, c’est quelque chose qui est clé, qui est souvent oublié par notamment tous les acteurs de la blockchain, etc. Le sémantique, ça permet que les données soient enregistrées dans un format qui va être facilement interopérable. Et qui permet que dès qu’une application connaît le vocabulaire, on parle d’ontologie, connaît l’ontologie, c’est comme si elle parle la langue par rapport à ce type de données. Par exemple, ça peut être des événements, des contacts, toutes sortes de données qu’on peut avoir. On voit les événements s’enregistrer et la date du début de l’événement est enregistrée avec un format qui est reconnu par toutes les applications qui reprennent ce vocabulaire. Et du coup, ça c’est vraiment hyper important dans la notion de pod de données, où on dit qu’on a justement toutes nos données, on va se connecter sur les différentes applications qui vont pouvoir y accéder. Si l’application enregistrait des données n’importe comment, comme elle veut, en fait, il faudrait mettre en place des sortes de petits traducteurs qui disent, lui, il a enregistré comme ça, mais du coup, pour moi, ça va signifier ça, etc. Et là, c’est là où ça devient un enfer. Une interopérabilité sans cet aspect-là, c’est très difficile. Et ça, c’est ce qu’on appelle le RDF, ce format de données. C’est quelque chose qui est poussé par Tim Berners-Lee, l’inventeur du web, depuis très longtemps, comme une manière de, dans le même esprit qu’un Internet ouvert.
Sylvain : C’était pour nous, pour le réseau social universel, c’était une des deux conditions essentielles techniquement pour qu’on puisse l’adopter. C’est que non seulement les données sont stockées chez moi, je les contrôle, et en plus elles sont stockées d’une manière suffisamment standard pour que si un jour je ne suis plus satisfait de l’application de chat que j’utilise, je peux passer sur une autre, j’aurai toujours mes données, mes contacts, tout ça, ça ne change pas en fait. J’ai juste changé d’application.
Locuteur 13 : C’est juste pour comprendre s’il s’agit d’ontologie et de web sémantique. Un format particulier de données, c’est-à-dire un format Word ou PDF ou autre chose, on peut dire que c’est le langage de ce type de données. Quelle différence avec l’ontologie ? Je ne sais pas, vous aussi, expliquez.
Sébastien : Alors, il peut gérer… Ça, c’est… Si c’est un format… Par exemple, une image, ça, c’est pas dans le web sémantique. Ça, ça va être considéré comme ce qu’on appelle un binaire.
Locuteur 6 : Un binaire. C’est une boîte noire. C’est une image. Après, un PDF, là aussi, ça va être un document. C’est intérieur. Dans un PDF, il y a plein de mots. Par exemple, chacun de ces mots, il est codé en langage du PDF.
Locuteur 6 : Oui, ça c’est pas… Pourquoi ce PDF n’est pas une ontologie ? En fait, pour moi, le web sémantique par rapport au PDF, ce serait plutôt, en tant qu’auteur du PDF, est-ce que ce PDF, c’est mon CV, ou est-ce que c’est une facture d’électricité, ou est-ce que c’est autre chose ? Bref, c’est en gros, quel type de données c’est ce PDF ?
Locuteur 6 : Ça accélère la convertibilité des données ?
Locuteur 6 : En fait, c’est quoi la notion de format ? En fait, PDF, par exemple, ça veut dire Portable Document Format. Un événement, il y a une date de fin, il y a un auteur, il y a un ensemble de champs qui sont liés à un événement. Et si on s’est mis d’accord pour dire que la date de début, on l’appelle comme ça, une autre application va le reconnaître et va dire, ah, ça c’est le type événement, je le reconnais, je peux l’utiliser automatiquement. Et il faut juste qu’à un moment donné, il y ait un accord qui se fasse sur comment on stocke un événement, comment on stocke un message de chat, comment on stocke une personne, pour que ça soit reconnu de manière universelle sans qu’il y ait besoin d’adaptation.
Sylvain : C’est ça l’ontologie, c’est ce vocabulaire qui permet de…
Locuteur 13 : C’est des métadonnées, c’est un peu comme ce qu’on appelle le langage universel. C’est une langue.
Sylvain : C’est une langue, c’est une façon structurée.
Sébastien : Concrètement, un exemple d’ontologie, c’est « Pierre est le fils de Marie ». Du coup, ça, il y a « Pierre », il y a « est le fils de », et « Marie ». Donc ça, ça va être un triplet, parce que c’est un triplet. Et « est le fils de », c’est ça qui va être utilisé, qui va être décidé dans une ontologie pour dire, ça c’est un truc qui est reconnu, et que du coup, quelqu’un qui connaît ce truc-là, il va pouvoir comprendre que là, la relation de ces utilisateurs, c’est une relation de mère-fils. Voilà, ça c’est un exemple.
Sylvain : C’est à ce moment-là que vous mettez « est le fils de », ou « est le fils de ».
Locuteur 6 : Ma question, elle est sur… Tu disais que les données sont chiffrées, qu’elles sont stockées selon les utilisateurs sur un serveur ou sur un autre en version chiffrée, et que par le côté sémantique, il y a le côté interopérabilité, et par SPARQL, le côté requêtage. À quel point est-ce qu’on peut, en matière de montée en charge ou de performance, si je veux requêter avec des aspects graphes grâce à l’aspect sémantique, des données qui sont des données que j’ai produites, mais aussi que quelqu’un d’autre a produites pour lesquelles j’ai accès en lecture, comment est-ce que ça fonctionne ? Il a déjà un petit SPARQL qui tourne ?
Sébastien : Alors, en fait, là, il faut accepter que les performances ne vont pas être les mêmes. Ça, c’est la contrepartie. En fait, SPARQL, c’est le moteur, c’est le langage de requête pour aller faire des recherches, pour savoir qui est le fils de Marie. Ça peut être une requête de ce type-là pour déterminer ça. Et on peut avec SPARQL faire des requêtes fédérées, c’est-à-dire une requête qui va aller sur plein de serveurs et trouver par du coup qui est l’ami de l’ami, etc. Et ça, il a implémenté déjà Niko, par exemple, pour pouvoir trouver, j’aimerais savoir, tous les contacts qui ont cette compétence de logement chez l’habitant. Du coup, il va faire la requête déjà sur les données qui sont locales, et ensuite il va lancer les requêtes sur les serveurs, enfin sur les contacts, qui peuvent accepter ou pas cette requête, et ensuite retourner. Et là seulement, il y a un temps, parce qu’ils peuvent être… Là par contre, ils doivent être connectés, parce que… Alors ça, je n’ai pas compris pourquoi, mais bon, ils doivent être connectés, donc la requête, elle va venir une fois qu’ils se reconnectent sur le réseau. Donc ça, ça permet de faire des requêtes complexes. Dans une architecture centralisée, il n’y a pas de problème, avec toutes les données chez LinkedIn. On peut faire ça immédiatement parce que c’est centralisé. Quand on est sur une architecture comme ça, décentralisée et cryptée, là c’est quelque chose de plus compliqué. Mais a priori, il n’y a pas de solution miracle. Il faudra que les utilisateurs acceptent qu’il y a un temps de latence et peut-être que tu envoies la requête et tu as une réponse peut-être 24 heures plus tard. Mais c’est des requêtes quand même très particulières.
Locuteur 6 : Sur le fait qu’il y ait besoin que l’autre soit connecté, est-ce que ça veut dire que quand on partage un droit en lecture, on ne transmet pas à toutes les personnes à qui on donne ce droit la clé d’accès en lecture pour qu’elle puisse être utilisée à n’importe quel moment par ces personnes ?
Sylvain : C’est une bonne question, parce que ça me paraît important. Justement, c’est l’élément que je voulais apporter en complément à ce que tu viens de dire, c’est que ce que Niko nous a dit, c’est qu’à partir du moment où les données sont partagées, automatiquement elles sont récupérées. Quand on partage quelque chose, mon serveur récupère une copie de ces données automatiquement.
Sylvain : Mon serveur, ma machine, tu veux dire, mon broker.
Sylvain : Le broker auquel je suis connecté, c’est lui qui est en charge aussi des abonnements. Donc il y a un pin automatique. Et ma machine aussi va récupérer parce qu’il y a synchronisation. Dès que l’appareil est disponible, il va se synchroniser et récupérer tout ce qui le concerne, ses propres données et celles partagées.
Sébastien : Et ça c’est vrai que c’est hyper important, on ne l’a pas activé dans ActivityPod par défaut. Dès qu’il y a un partage de l’information, on la met en cache.
Sylvain : D’accord, donc il y a des problématiques de… Je vais manquer de place disque localement. La problématique est plus dans le volume de données locales. En revanche, ça améliore les problèmes de performance.
Sylvain : Et l’autre point par rapport à ta question, c’est que c’est dans l’identifiant de partage du document qu’il y a la clé de lecture. La clé de lecture vient avec l’identifiant qui permet d’y accéder.
Locuteur 16 : Et du coup, il y a forcément des métadonnées publiques pour que le serveur puisse gérer les documents. Quelles sont les métadonnées publiques et est-ce que le RDF, il est protégé ou pas ?
Sébastien : Je pense que c’est une grosse question parce que souvent quand on parle de E2E et de chiffrement, souvent il y a plein de métadonnées qui ne sont pas encryptées et c’est un problème de sécurité. Donc là oui, il y a une encryption à plusieurs couches. Et en fait, tout est end-to-end. Les métadonnées, c’est plus ou moins protégé du coup.
Locuteur 16 : Du coup, un deuxième truc que je me demande, c’est que si, par exemple, je veux notifier quelqu’un que je lui partage un document, est-ce que le seul moyen, c’est de lui envoyer le lien de partage ? Ou si le broker peut lui envoyer une notification ? Mais du coup, ça veut dire que mon broker sait à qui je veux l’envoyer. Donc, il faut que je lui fasse confiance.
Sébastien : Non, parce que pour envoyer à quelqu’un, tu dois être en relation avec lui, et après tu peux passer par un mécanisme de boîte de réception. Des boîtes d’envoi et de réception.
Sylvain : Il peut y avoir des bots aussi, des services annexes qui sont associés au broker, qui vont apporter des services. Ça peut être un service d’envoi de mail, ça peut être un service de notification push, ça peut être tout un ensemble de services comme ça. Et à chacun de ces services, il faudra que moi, je les autorise volontairement. Tels événements, je veux bien que ce service y accède. Du coup, quand je crée un événement de cette nature, c’est paramétré pour que le service en question ait accès à l’événement. Et du coup, il fait son action de le transférer automatiquement par un bridge ActivityPub, mais aussi ça peut déclencher automatiquement un email. Parce qu’il y a un service qui a ce droit.
Locuteur 18 : Je reviens sur une question de tout à l’heure, une réaction de tout à l’heure, quelqu’un qui disait, les commercialisations, et là on vient bien de dire que selon Niko, et je suis tout à fait d’accord avec ça, c’est pas si grave si à un moment donné il y a quand même des acteurs privés qui interviennent dans la création de nouvelles valeurs, de nouvelles formes de valeurs. Ça veut dire qu’en étendant ce principe-là, il va y avoir effectivement des gros acteurs qui vont du coup être sur une partie totalement commercialisée du truc. Et tu as même prononcé le mot business model avec l’idée qu’il puisse y avoir des box vendues, ce qui contribue en fait à l’ensemble du système. Mais ça suppose quand même que l’ensemble de l’écosystème qui est en train de bosser autour de ça considère que c’est possible et qu’il ne fasse pas un blocage net en disant « bah ouais, mais attendez, on va se… »
Sylvain : On est habitué à ce que tout soit gratuit. C’est gratuit. En fait, plutôt que d’avoir des données partout, si tu as tout…
Sébastien : C’est-à-dire qu’au final, tu dois juste payer un hébergement. Alors, soit du coup, une box que tu gères toi-même, soit tu paies un hébergement. Au final, ça n’a pas de coût caché. C’est le coût réel de la chose. Soit ça peut être pris en charge parce que tout à coup, les collectivités comprennent que c’est un truc fondamental. Et du coup, avec nos impôts, on… On paie notre… On peut toujours rêver. Non, mais c’est pas complètement idiot. Mais dans la façon de… C’est comme ça. Les infrastructures, c’est comme ça.
Locuteur 18 : Oui.
Sébastien : Donc, il n’y a pas de problème.
Locuteur 18 : Moi, je ne vois pas de problème. Je pense que ça peut être un élément clé de diffusion ou pas.
Locuteur 1 : De ces concepts ?
Sébastien : En fait, vu qu’au début, on peut changer de broker, on peut très bien au début avoir plein de brokers qui sont gratuits, etc. Et peut-être qu’à un moment, il y aura des problèmes, ils seront un peu trop lents, etc. Et les gens diront, ok, je suis prêt à payer 5 euros par mois pour avoir quelque chose de fiable. En fait, les gens ne sont pas bloqués. C’est vraiment du service au sens pur.
Sébastien : Ce que je comprends, c’est qu’au début des hypercalculateurs, des centaines de milliers de personnes mettaient à disposition un morceau de leur ressource. Donc ça, techniquement, ça permet de faire du calcul distribué.
Locuteur 21 : Pour les nuls toujours, broker, hébergeur, la même chose ?
Locuteur 21 : Oui, broker, c’est le nom dans NextGraph.
Locuteur 21 : Et deuxième question aussi, vous avez dit que ça ne coûtera pas grand-chose, c’est le coût d’un hébergeur, malgré tout, au démarrage, vu en plus qu’il n’y aura pas beaucoup d’utilisateurs, donc il faudra bien que ça soit… C’est quoi ? C’est de l’ordre de 100 euros par mois ? Ça aussi, ça peut être un sacré frein pour embarquer des gens sur le réseau.
Sébastien : En fait, c’est lié à l’utilisation. Tant qu’il y a une utilisation modeste, pas beaucoup de données, pas beaucoup d’utilisateurs, ça ne coûte presque rien. C’est vraiment… C’est juste 10-15 euros par an.
Locuteur 21 : Donc tu parles de 5-15 euros par an.
Sébastien : Là, si on devait tous utiliser ça pour faire Festipod et quelques centaines d’utilisateurs avec un seul serveur, on n’a pas de souci. C’est quand vraiment on passe sur les gros volumes.
Locuteur 11 : En fait, une infrastructure, elle a un coût. Ta question, c’est qui supporte ce coût ? Mais elle a un coût. De toute façon, il y a des serveurs. Le serveur à 15 euros, il ne va pas héberger des gigas de films.
Locuteur 11 : Il n’a pas dit 15 euros par mois. Il a dit 15 euros par an.
Locuteur 11 : Non, mais c’est pour dire que c’est aussi l’usage qu’on en fera. Si on décide de stocker tous nos films perso, en HD sur un broker, ça va coûter de l’argent. Il y aura un surcoût. Et donc, le prix sera probablement proportionnel au volume de données stockées. Donc, si… Non, mais évidemment. Ça dépend de l’usage, je pense. Et c’est comme ça que ça fonctionne.
Locuteur 11 : Et c’est par appli ou pas ? Parce que ça va être 15 euros pour Festipod, et puis si j’ai les livres, c’est 15 euros.
Locuteur 11 : Non, c’est ton pod. C’est ton sac à dos. C’est un gros sac à dos. Il a pris l’exemple des films parce que c’est le truc qui pèse mille fois plus que tout le reste.
Locuteur 14 : Justement, moi j’allais donner cet exemple des films au début parce que tout n’est pas forcément pertinent à héberger sur un système encrypté comme ça. L’IPFS joue un rôle aussi, il peut y avoir d’autres systèmes qui ne chiffrent pas, pour des données qui ne sont pas pertinentes à chiffrer.
Locuteur 11 : Si tu es facturé au volume, c’est à toi de voir tes capacités. À un moment donné, ces choses-là ont un coût. Et après, le modèle économique, ça peut être public, ça peut être privé, ça peut être coopératif, etc. Là, l’hébergeur peut avoir son propre modèle économique.
Locuteur 11 : Et si on reste que sur Festipod ?
Locuteur 21 : Il n’y a pas de film, je pense que c’est juste…
Locuteur 11 : Non, par exemple, c’est une application. Les données, quand tu regardes l’application, les données derrière, il n’y en a pas beaucoup. C’est essentiellement les photos.
Locuteur 11 : Oui, oui, le plus lourd sera effectivement les photos et les photos de tes contacts.
Locuteur 21 : Et si je fais un petit film de 3 minutes de ce qui s’est passé là, là, tout d’un coup, ça…
Locuteur 11 : C’est proportionnel au volume. La vidéo, c’est ce qui est le plus lourd. Ensuite, tu as le son et après, tu as les photos. Après, tu as des gros documents, gros PDF avec des photos.
Locuteur 18 : Si je l’évoque, ce n’est pas que je suis contre, au contraire, mais c’est peut-être le moment aussi de penser en termes de nouvelles monnaies, de monnaies libres, etc.
Locuteur 8 : Et est-ce que chacun doit avoir son propre broker ou se connecter à un broker ? Toute personne peut se connecter à un broker. Tout le monde va le décentraliser et pas le distribuer.
Sébastien : L’idée c’est qu’il peut aussi dire j’ai un broker mais il est en accès limité, c’est moi qui choisis qui a le droit de se connecter. Ou alors tu peux dire il n’y a que moi qui suis sur mon broker.
Locuteur 8 : On peut se passer du broker aussi, non ? Est-ce qu’on peut se passer du broker ?
Sébastien : Non, pas dans l’architecture, parce que justement il n’y a pas de peer-to-peer.
Locuteur 8 : Il n’a pas prévu ça ?
Locuteur 14 : On la remet ? On a dit que c’était du local first ? Ben non, parce que c’est le local first, c’est ce qui ne l’empêche pas. Pourquoi est-ce qu’une machine ne pourrait pas être un broker ?
Locuteur 14 : Si, tu peux avoir ton broker sur ta machine, c’est possible. Non mais sans avoir à installer un truc en plus.
Sylvain : Parce qu’il y a un mécanisme de synchronisation, quand quelqu’un partage quelque chose pour toi, il faut que ça soit récupéré quelque part. Et là, c’est récupéré sur ton broker en fait. Si tu n’as pas de broker, tu ne peux pas le récupérer. Parce que ton appareil, il n’est pas connecté tout le temps, donc après, quelqu’un qui veut te contacter, comment il sait où envoyer ?
Locuteur 11 : C’est comme auto-héberger ton serveur de mail. Ton client de mail est ton serveur de mail sur la même machine.
Locuteur 14 : Oui, par un système DHT. Les DHT peuvent servir à…
Sylvain : Oui, on pourrait rajouter d’autres trucs d’architecture, d’autres solutions pour explorer cette voie-là, mais Niko n’est pas parti là-dessus. Il est parti sur un système avec le broker.
Locuteur 14 : Ok, d’accord.
Locuteur 11 : La DHT, ça ne corrige pas le problème. C’est qu’il faut garantir que tes données soient au moins sur un nœud, en plus de ta sauvegarde locale.
Sylvain : C’est ça, le broker, il simplifie la localisation des données.
Locuteur 14 : Si tous les users deviennent brokers, il y a une solution.
Sylvain : Si tous les users ont un serveur allumé, tu peux dire. Non, ils hébergent leur propre.
Locuteur 6 : Il faut des serveurs qui sont en ligne tout le temps et qui ont une IP fixe.
Sylvain : Une IP fixe, c’est pour ça qu’il y a cette idée de pouvoir avoir son propre serveur à la maison. Et même si ça change d’IP, le serveur est disponible, mais il faut un serveur.
Locuteur 6 : Oui, c’est ça que je dis, un serveur, c’est une IP fixe. Non, un serveur, c’est une machine online, c’est un service toujours disponible.
Sylvain : C’est deux logiciels différents. On pourrait les mettre sur la même machine et ça marcherait. Mais en fait, tu peux avoir plusieurs appareils. On a tous plusieurs appareils. On a un ordinateur, on a un téléphone. On a facilement la synchronisation entre tous. Ils sont tous clients en plus. C’est un équilibre. Il y en a d’autres.
Locuteur 8 : Est-ce qu’un broker, lui, il n’a absolument aucune connaissance sur la personne qui l’utilise ? C’est vraiment ce que je veux savoir. Est-ce qu’un broker peut dire, tiens, je sais qui est cette personne, je la bannis, je ne veux pas… Je l’empêche d’envoyer des messages ou des choses comme ça ?
Sylvain : Il faut le voir comme un hébergeur. Il peut y avoir une relation contractuelle entre les deux. Il y a au moins un identifiant, il peut y avoir une adresse parce qu’il y a une facturation. Il y a ce minimum-là parce qu’il y a un lien de « j’ai créé mon compte là-bas ». Et du coup, il peut y avoir un bannissement, il peut y avoir ce genre de choses. Ça dépend de la relation entre les deux, de si c’est purement associatif.
Sylvain : Mais il ne voit pas le contenu. Il voit le volume de données, par exemple.
Locuteur 8 : Oui, mais il n’a pas de connaissance du contenu. Il ne peut pas le déchiffrer.
Sylvain : Il n’y a pas d’anonymat.
Locuteur 22 : Est-ce qu’il y a des métriques pour paramétrer le réseau sur le nombre de brokers nécessaires pour un certain volume d’usage ?
Sylvain : Je pense qu’on n’en est pas là. Pour l’instant, il y a un broker européen. C’est tout.
Sébastien : Peut-être qu’on peut aussi dire qu’en rapport aux avantages de cette architecture, c’est que du coup, il n’y a plus la responsabilité légale des brokers. Ça permet aussi de résoudre tous les problèmes qui, actuellement, il y a beaucoup de choses, de dire qu’on veut de plus en plus d’obligations aux hébergeurs. Il y a des trucs sur est-ce que tous les serveurs Mastodon, ils devraient commencer à devoir filtrer les utilisateurs, est-ce qu’ils sont mineurs, maintenant avec la loi qui est passée sur les réseaux sociaux, sans dire qu’est-ce qu’ils entendent par réseaux sociaux, potentiellement ça s’applique aussi à tous les serveurs Mastodon. Qui doivent du coup payer un service pour vérifier l’âge des utilisateurs. Etc. Donc toutes ces obligations légales, en fait, avec une architecture local first, on n’a plus vraiment ce problème parce qu’en fait, les données de base, c’est l’utilisateur qui les a. Le serveur, il joue juste le rôle d’intermédiaire. Du coup, c’est vraiment un cadre très différent.
Sébastien : Comme la Monnaie Libre, s’ils disaient qu’on interdit les serveurs de la Monnaie Libre en France, rien n’empêcherait de faire des serveurs partout dans la planète et ça continuerait à tourner. Donc ça c’est quand même par rapport à la tendance actuelle qui est de contrôler de plus en plus Internet. C’est un avantage, après bien sûr si c’est au point où tu ne peux plus accéder à Internet sans être identifié, là on ne pourra pas faire grand-chose, mais les contraintes actuelles, c’est un peu compliqué, parce que ça va à l’encontre de toute l’architecture d’Internet.
Sébastien : Au niveau du déploiement NextGraph, est-ce qu’il y a des contacts par exemple avec Framasoft, avec les CHATONS, pour les… pour les brokers ?
Sébastien : À ce stade, il n’y a pas de communication entre les brokers. Ok.
Locuteur 9 : Vincent, c’était par rapport au côté chiffré ?
Locuteur 6 : Des brokers qui permettent de sortir des enjeux légaux liés aux hébergeurs. Du coup, ça déplace l’enjeu légal au niveau des développeurs d’apps avec une tentative de loi d’obligation d’avoir pour ce niveau un backdoor, c’est-à-dire avant que ce soit chiffré, directement sur les terminaux. C’est ça, des obligations pour déchiffrer potentiellement. Ils cherchent quand même des chemins pour…
Locuteur 6 : Il reste 3 minutes.
Locuteur 23 : C’était un peu dans la lignée.
Locuteur 18 : Un contrat et je me dis qu’il va devoir être fait en parallèle justement pour créer tout un cadre juridique autour de ça.
Locuteur 24 : C’est plus ce que je me dis qu’il y a à faire pour l’avenir.
Sébastien : Là déjà, pour essayer de caler tout ce qui se passe, c’est déjà un gros chantier. Nous c’est juste que du coup, c’est comme si on n’est pas concernés. Jusqu’à ce qu’ils arrivent à… Enfin, pas concernés. Non, pas directement. Pas dans la case qui est visée pour l’instant. Il y a aussi les obligations de l’hébergeur, si il y a des données sur ton serveur, de donner accès. S’ils disent qu’il y a un terroriste qui a hébergé des données chez vous, vous êtes obligé de donner accès. S’il donne des données chiffrées, il y a… Je ne sais pas. Je n’ai aucune idée. Je ne peux pas les déchiffrer. En fait, c’est ça le truc…
Sébastien : Ça, c’est le problème du chiffrement en général. C’est pour ça qu’à un moment, ils avaient essayé d’interdire certaines clés trop fortes… Je ne me souviens plus exactement de l’histoire, mais c’est dans les années 2000, je crois. Ils voulaient essayer d’interdire certains niveaux de chiffrement pour au moins s’assurer de pouvoir toujours déchiffrer les données. Ils n’ont pas… Ils ont essayé, là, la technologie les a clairement dépassés. Maintenant, on a accès à ce qu’on veut. Il y a plein de choses qui ne sont pas déchiffrables.
Locuteur 14 : Rapidement, moi je vais donner un détail, c’est un détail un peu de la présentation, mais moi quand vous dites que forcément, tout est synchronisé, toutes les données auxquelles je dois accéder sont téléchargées en local, ça me rappelle un peu Scuttlebutt ou des réseaux un peu où tout est absorbé, est-ce que c’est possible de paramétrer ça, notamment sur mobile ? La plupart des usages du numérique sont sur mobile aujourd’hui, très très largement, et du coup on n’a pas de stockage pour stocker les données de tout le monde, de tout mon réseau. Est-ce qu’il y a des modes différents d’accès pour prévoir des usages un peu extrêmes comme ça ?
Sylvain : Je ne sais pas la réponse de Niko, mais je pense que oui, je pense que c’est vraiment une logique d’abonnement sélectif. Au début c’est un abonnement automatisé pour synchroniser au maximum.
Locuteur 14 : C’est-à-dire désactivable ou affinable selon les types de données, mais pas forcément la même chose.
Locuteur 11 : Je propose de… Oui, on essaie de conclure. Oui. Juste pour rebondir sur ce que tu viens de dire. Par exemple, sur Nextcloud, il y a la synchro sélective de fichiers. Sur le téléphone, tu peux dire, je ne synchronise pas…
Locuteur 14 : Oui, mais là, ça pourrait être un problème d’architecture, en fait, de la nécessité de devoir tout synchroniser.
Locuteur 14 : C’est le cas ? Non, ce n’est pas le cas. C’est le cas.
Locuteur 11 : Denis, toi, tu as été CHATONS. L’obligation légale de conservation des logs. Il y a les adresses IP qui sont là. Et c’est combien de temps ? C’est au moins un an. Donc un broker, on peut lui demander… Il n’a pas les données, mais on peut lui demander quelle IP s’est connectée à quelle heure ? Les autorités peuvent faire des choses. C’est ça l’obligation légale. Ce n’est plus le contenu, il n’est plus responsable. On ne peut pas lui demander de censurer le contenu. Mais on peut quand même lui demander les logs de connexion.
Locuteur 11 : En fait, c’est un sujet, je pense, qu’on pourrait encore traiter pendant une heure. Je propose de terminer en sachant qu’on a prochainement un point prévu avec Niko, jeudi soir. Donc, tout le monde est bienvenu, mais ça risque d’être très, très technique. Il n’y aura pas trop de temps de vulgarisation.