s@ : réseau social décentralisé basé sur des sites statiques

 (satproto.org)
9 points par GN⁺ 2026-03-13 | 1 commentaires | Partager sur WhatsApp
  • Protocole de réseau social décentralisé basé sur des sites web statiques, dans lequel chaque utilisateur possède et gère directement ses propres données
  • Toutes les données sont stockées dans un dépôt JSON chiffré, et le client navigateur agrège le fil et publie les messages
  • Fonctionne sans serveur ni relais, via une communication directe entre les sites web des amis et les navigateurs
  • Le nom de domaine de l’utilisateur fait office d’identité, avec authentification via HTTPS/TLS
  • Met en œuvre un réseau social autosouverain avec une structure simple, centré sur des échanges fondés sur la confiance entre individus

Vue d’ensemble du protocole sAT

  • s@ est un protocole de réseau social décentralisé basé sur des sites statiques dans lequel chaque utilisateur stocke ses données sur son propre site web
    • Toutes les données sont enregistrées sous forme de fichiers JSON chiffrés, que le client navigateur lit pour publier des messages et agréger le fil
    • Il fonctionne sans serveur central ni relais, les données allant directement du site de l’utilisateur vers le navigateur de ses amis
  • Les échanges de publications ne sont possibles qu’en présence d’une relation de suivi mutuel, ce qui exclut une structure centrée sur les influenceurs
  • Le protocole n’est pas dépendant d’un service d’hébergement particulier comme GitHub Pages

Identité

  • Le nom de domaine de l’utilisateur sert d’identité
  • HTTPS/TLS permet de vérifier que le propriétaire du domaine a bien publié le contenu

Découverte

  • Le chemin https://{domain}/satellite/profile.json fournit la version du protocole et la clé publique 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • Si un chemin autre que le chemin par défaut /satellite/ est utilisé, le fichier .well-known/satproto.json peut indiquer l’emplacement réel du dépôt

Modèle de chiffrement

  • Toutes les données utilisateur sont stockées dans un dépôt JSON chiffré, déchiffrable uniquement par l’utilisateur et ses abonnés
  • Une paire de clés X25519 est utilisée : la clé publique est publiée dans profile.json, tandis que la clé privée est stockée dans le localStorage du navigateur
  • Les données des publications sont chiffrées avec XChaCha20-Poly1305, et la clé de contenu est chiffrée pour chaque abonné avec crypto_box_seal de libsodium
  • Le fichier keys/_self.json contient la clé de contenu de l’utilisateur et les secrets de publication, et lui seul peut le déchiffrer

Rotation des clés et désabonnement

  • Lors d’un désabonnement, une nouvelle clé de contenu est générée et toutes les publications sont rechiffrées
  • De nouvelles enveloppes de clé sont générées pour les abonnés restants et keys/_self.json est mis à jour
  • L’utilisateur désabonné ne peut plus déchiffrer les publications

Flux de déchiffrement

  • Lorsqu’un visiteur consulte le site d’un ami, il déchiffre keys/{follower-domain}.json avec sa propre clé privée pour obtenir la clé de contenu
  • Il récupère ensuite posts/index.json et les publications individuelles (posts/{id}.json.enc) pour les déchiffrer

Structure des données

  • Chaque publication est stockée dans un fichier chiffré séparé, et posts/index.json liste les identifiants des publications de la plus récente à la plus ancienne
  • Exemple d’objet de publication : 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • Les identifiants de publication sont composés d’un horodatage UTC ISO8601 et d’un hash aléatoire de 4 caractères

Liste des abonnements

  • Stockée en JSON en clair à l’adresse https://{domain}/satellite/follows/index.json 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • Elle n’est pas chiffrée, car la relation de suivi est déjà exposée via les enveloppes de clé

Agrégation du fil

  • Le client lit la liste des abonnements et déchiffre les publications de chaque contact pour construire un fil chronologique
  • Les publications sont triées par ordre décroissant selon created_at

Réponses

  • Les réponses sont des publications dont les champs reply_to et reply_to_author sont renseignés
  • Les réponses imbriquées ne sont pas prises en charge : seules les réponses directes à une publication de premier niveau sont possibles
  • Si la publication d’origine n’est pas visible (par exemple faute d’abonnement), la réponse n’est pas affichée

Publication

  • Création d’une nouvelle publication → chiffrement avec la clé de contenu → téléversement sur le site statique → mise à jour de posts/index.json
  • Le téléversement peut utiliser l’API Contents de GitHub, entre autres
  • Les secrets de publication sont stockés chiffrés dans keys/_self.json

Exemple de structure de site statique

{domain}/satellite/
  profile.json              # clé publique et profil
  posts/
    index.json              # liste des identifiants de publication
    {id}.json.enc           # publication chiffrée
  follows/
    index.json              # liste des abonnements
  keys/
    _self.json              # clé de contenu et identifiants
    {domain}.json           # clé de contenu par abonné

FAQ

  • « Est-ce du RSS + chiffrement ? » → Oui
  • « Une version de l’AT Protocol sans firehose ? » → Oui
  • « Est-ce scalable ? » → Non (« l’amitié non plus n’est pas scalable »)
  • « Le s signifie-t-il slow/shitty ? » → Oui
  • « Peut-on l’auto-héberger ? » → Oui, mais CORS doit être activé

À lire aussi

1 commentaires

 
GN⁺ 2026-03-13
Avis sur Hacker News

  • J’ai l’impression que ce projet rencontre les mêmes problèmes que beaucoup de réseaux sociaux alternatifs et auto-hébergés
    La conception centrée sur le chiffrement est séduisante, mais quand on change d’appareil, il devient difficile de restaurer la liste de ses abonnements, et des notions comme une paire de clés X25519 restent trop complexes pour le grand public
    Je pense qu’une structure plus réaliste serait un système basé sur identifiant et mot de passe, où le serveur se charge du chiffrement à la place de l’utilisateur
    C’est selon moi ce genre d’approche qui peut vraiment remplacer le Big Tech tout en restant utilisable par des personnes non techniques

    • Je pense à peu près pareil. Mais si on veut un monde sans intermédiaire, il faudra au final un changement culturel où même les non-techniciens gèrent eux-mêmes un minimum de choses
    • Après la configuration initiale, il suffit d’exporter la clé privée et de la stocker dans un gestionnaire de mots de passe ou équivalent. Tant qu’on n’implémente pas soi-même le protocole, ce n’est pas si compliqué
      En revanche, il faudra peut-être que je fasse l’installation à la place de ma famille ou de mes amis. Cela dit, ils pourraient quand même beaucoup apprécier d’avoir leur propre site web
    • D’après la FAQ en bas de l’article, c’est davantage une expérience conceptuelle inspirée de l’AT Protocol (BlueSky), avec certains éléments retirés
      En pratique, on peut y voir une idée d’intégration d’un blog statique à BlueSky.
      Ce serait améliorable en exploitant l’identité BlueSky, ou via un plugin de générateur de site statique qui récupérerait automatiquement les informations d’authentification
    • J’avais déjà tenté l’idée d’utiliser l’e-mail comme couche de transport pour un réseau social, mais cela n’a pas marché
      Voir cet article
    • Je ne sais pas si l’objectif est vraiment de remplacer le Big Tech. Si cela peut simplement être utile à de petites communautés, ce sera déjà une réussite à mes yeux

  • J’ai été surpris de voir que la clé privée est stockée dans le localStorage du navigateur
    Si les paramètres du navigateur sont réinitialisés ou si le navigateur est réinstallé, les données disparaissent, les sauvegardes sont difficiles, et l’accès par un malware est facile
    Au final, si la clé est perdue, le fil disparaît lui aussi définitivement, ce qui risque de faire fuir les utilisateurs

    • D’accord. Le simple fait d’utiliser naturellement des termes comme « paire de clés X25519 » montre que ce projet ressemble plus à une expérience conceptuelle qu’à quelque chose destiné à une adoption grand public
    • Je pense qu’un simple bouton « exporter la clé vers un emplacement sûr » peut régler le problème. Avec un code très simple comme URL.createObjectURL(localStorage.getItem(...)), on peut inciter l’utilisateur à enregistrer un fichier
    • Il ne faut pas laisser la quête de la perfection faire manquer une solution suffisamment bonne. Ajouter uniquement des fonctions de téléchargement et d’import de clé résoudrait déjà la plupart des problèmes
      Bien sûr, perdre la clé signifie perdre l’accès, mais les utilisateurs de 2FA ou de portefeuilles crypto acceptent déjà une responsabilité similaire, donc ce n’est pas totalement irréaliste

  • Quelqu’un propose d’utiliser /.well-known/ au lieu du chemin /satellite/
    En référence au standard Well-known URI

    • Réponse en plaisantant avec « .poorly-known »
    • Quelqu’un dit que cela lui rappelle les failles de sécurité apparues au début d’AT Proto quand le chemin racine était utilisé
    • Un autre soutient que .well-known s’applique à l’hôte entier et ne convient donc pas à des flux distincts ; il vaudrait mieux séparer plusieurs répertoires

  • La proposition .well-known/ me semble mériter une vraie réflexion
    C’est déjà un standard enregistré auprès de l’IANA et largement utilisé, notamment pour les fichiers de sécurité et de découverte
    Mettre satproto.json dans /.well-known/satproto.json plutôt que dans /satellite/satproto.json permettrait d’éviter les conflits et d’indiquer plus clairement qu’il s’agit d’un endpoint de protocole

    • Mais objection : .well-known fonctionne au niveau de l’hôte, donc ce n’est pas adapté si l’on veut plusieurs répertoires distincts par compte

  • Les protocoles de réseau social ne doivent pas exister pour la technique elle-même, mais apporter un bénéfice direct à l’utilisateur
    Comme avec BitTorrent, il faut que les gens participent simplement parce qu’ils en ont besoin, afin de créer un effet de réseau
    Une approche qui part de la gestion des données et de la facilité de partage paraît plus réaliste

    • Pour avoir essayé plusieurs réseaux sociaux décentralisés, je constate qu’au final les gens n’y viennent pas s’il n’y a pas de stimulation dopaminergique
      Lemmy ou Pixelfed donnaient l’impression d’endroits où « il ne se passe rien », faute de contenu
      Signal aussi : comme c’est uniquement de la messagerie, il n’y a pas de raison de scroller
      En fin de compte, il faut du contenu et du FOMO (peur de rater quelque chose) pour donner envie de revenir régulièrement
    • Cela dit, une bonne conception de protocole reste importante. Si c’est trop complexe ou mal préparé pour l’avenir, même une bonne idée disparaît vite

  • Pour construire une vraie messagerie sociale décentralisée et chiffrée de bout en bout, il faudrait une architecture où chaque serveur est réellement hébergé de manière indépendante, comme avec Discord
    Les comptes seraient gérés via un protocole du type Nostr, et le tout fonctionnerait sur Yggdrasil Network afin de réduire la dépendance à IPv4/6 et au DNS
    Si le trafic est encapsulé dans HTTPS et que le contournement du NAT est automatisé, n’importe qui peut exploiter un serveur
    Ce n’est qu’avec ce type de structure qu’on peut vraiment échapper au contrôle du Big Tech et des gouvernements

    • Mais la technique seule ne suffira pas. Le grand public ira de toute façon vers les plateformes qui ont le plus de budget marketing
    • Je pense qu’une approche de réseau distribué fondé sur le cache, comme BitTorrent ou IPFS, est meilleure
      Même si les serveurs disparaissent, les données restent en périphérie, et le navigateur des utilisateurs peut lui-même jouer le rôle d’hôte
      Voir ephemeral-p2p-project
    • Ce type d’architecture est déjà testé sur geogram.radio
      Chaque appareil agit comme un serveur, et la messagerie totalement P2P est implémentée via WebRTC
      Même sans Internet, l’échange de données reste possible via une liaison radio
    • Je construis quelque chose de similaire chez Mikoto Platforms. Les « Spaces » peuvent exister sur n’importe quel nœud physique, et les messages privés sont routés en E2EE via plusieurs nœuds

  • Il y a déjà eu des tentatives de réseaux sociaux totalement décentralisés, comme FOAF ou Pingback

    • Leur version moderne est Webmention
      Le wiki IndieWeb est recommandé comme bonne ressource pour explorer ce type de technologies sociales fondées sur le web personnel
    • Et il ne faut pas oublier XFN comme autre exemple

  • En lisant la description « sAT Protocol est un réseau social décentralisé basé sur des sites statiques », j’avais envie de dessiner un graphique où mes sourcils montent progressivement

    • Malgré tout, vu que le périmètre visé est réduit, le système me semble raisonnable
      En revanche, le fait que les textes chiffrés puissent être énumérés publiquement peut devenir risqué à l’ère des ordinateurs quantiques
    • Cela ressemble à une combinaison PGP + RSS. Chaque flux est chiffré de manière à ce que seules certaines personnes puissent le déchiffrer
      C’est adapté à de petits réseaux, mais difficile à étendre à grande échelle à cause des problèmes de distribution et de rotation des clés
    • Je comprends le concept comme « on transmet une base de données et le client construit ensuite un site statique »
    • La partie « Key Rotation (Unfollow) » est présentée comme une blague en ASCII art

  • Du point de vue utilisateur, j’ai l’impression qu’il faudrait d’abord expliquer quel service cela rend concrètement
    Il n’y a que des termes techniques comme fork, chemin, JSON ou chiffrement, sans qu’on voie vraiment le scénario d’usage réel

    • Cela dit, j’ai pas mal d’amis intéressés par la technique, donc j’envisage de tester cela avec des personnes qui ont un goût paranoïaque pour la sécurité
      C’est un terrain que Mastodon ou Signal ne couvrent pas vraiment, donc cela vaut le coup d’expérimenter

  • Je trouve ces expériences de réseaux décentralisés vraiment fascinantes
    Même si elles ont souvent beaucoup de problèmes structurels, j’aime découvrir de nouvelles combinaisons d’idées
    En revanche, devoir rechiffrer et reconstruire tout le site à chaque abonnement ou désabonnement est beaucoup trop contraignant
    De plus, le fait de ne pas voir les commentaires sans suivre la personne limite fortement la scalabilité
    Cela dit, le mélange de RSS, ActivityPub et site statique a quelque chose d’attirant
    Tenter de mettre en place un contrôle d’accès dynamique à une liste d’amis sur un site statique est contradictoire, mais intéressant
    Au final, c’est une architecture que j’aime et déteste à la fois. Mais je suis content et reconnaissant de voir ce genre de tentative