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

• 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é