Un système de fichiers social

• Étend le concept d’informatique personnelle centrée sur les fichiers au social computing, en décrivant une structure où tout le contenu créé par l’utilisateur lui appartient, plutôt qu’à une application
• Propose le concept d’un système de fichiers social décentralisé fondé sur le protocole AT, permettant l’interopérabilité des données entre applications
• Chaque utilisateur dispose de son propre « everything folder » ou repository, où les publications, likes et follows sont stockés sous forme de fichiers JSON (records)
• Grâce aux DID (Decentralized Identifier) et au schéma d’URI at://, il est possible de conserver des liens identifiables de manière permanente même en cas de changement d’hébergement ou de handle
• Cette structure forme un écosystème social centré sur les données plutôt que sur les applications, permettant à chacun de créer de nouvelles apps fonctionnant sur les données existantes

---

Le paradigme des fichiers et son extension sociale

• À l’origine, les fichiers existent dans un espace contrôlé par l’utilisateur plutôt qu’à l’intérieur d’une app, et les apps ne servent qu’à lire et écrire ces fichiers
  • Les formats de fichiers ouverts comme .svg permettent à plusieurs apps de partager les mêmes données
  • Selon le principe « le format de fichier est l’API », l’interopérabilité entre apps devient possible
• En appliquant cette idée aux apps sociales, des actions comme les publications, follows et likes peuvent elles aussi être traitées comme des fichiers
  • Il existe un « everything folder » contenant toute l’activité en ligne de l’utilisateur
  • Les apps reflètent les données de ce dossier, qui joue le rôle de source of truth unique

Le protocole AT et le système de fichiers social

• Le protocole AT est la technologie qui concrétise cette architecture ; Bluesky, Leaflet, Tangled, Semble et Wisp s’appuient déjà dessus
• Les apps ne possèdent pas les données des utilisateurs ; grâce à un stockage séparé des données au niveau des fichiers, de nouvelles apps peuvent réutiliser les données existantes
• L’ensemble des dossiers utilisateurs forme un système de fichiers social décentralisé

Structure des records et des collections

• Chaque publication est représentée par un fichier JSON (record), sans inclure les informations sur l’auteur ni les données dérivées comme le nombre de likes
  • Exemple : { text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
• Les noms de fichiers sont générés à partir de clés de record basées sur des timestamps, afin d’éviter les collisions
• La structure des fichiers est définie par un schéma appelé lexicon, que chaque app peut concevoir pour ses propres besoins
  • Exemples : com.twitter.post, fm.last.scrobble, io.letterboxd.review
• Même pour un même concept, différentes apps peuvent utiliser des lexicons différents, les namespaces basés sur les domaines évitant les conflits

Validation et confiance

• Il n’existe pas de Lexicon Police — aucune app ne peut imposer ses données aux autres
  • Les apps valident les données à la lecture (validate on read) et les ignorent si elles ne sont pas valides
• Lorsqu’un lexicon évolue, il est indispensable de préserver la rétrocompatibilité ; les changements cassants doivent être séparés dans un nouveau lexicon
• Les lexicons peuvent être publiés ouvertement, et la preuve de propriété du domaine peut être établie via le DNS

Liens et identité

• Comme les « likes » ou les « réponses » créés par les utilisateurs doivent référencer d’autres records, un système de liens permanents est nécessaire
• Après plusieurs tentatives, l’identité a été établie au moyen des DID (Decentralized Identifier)
  • Un identifiant comme did:plc:6wpkkitfdkgthatfvspcfmjo ne peut pas être modifié
  • Chaque DID est résolu en un document contenant les informations actuelles d’hébergement, de handle et de clé publique
• Les URI at:// combinent DID, collection et clé de record pour fournir des liens qui ne se cassent pas même en cas de changement d’hébergement
  • Exemple : at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5

Hyperliens JSON et représentation des relations

• Chaque « like », « repost » ou « réponse » adopte une structure de JSON avec hyperliens qui référence d’autres records
  • Par exemple, le champ parent référence l’URI at:// d’une autre publication
• Toutes les informations de l’interface utilisateur (auteur, texte, nombre de likes, etc.) peuvent être calculées à partir de ces liens entre fichiers

Repository et flux de données

• Le « everything folder » d’un utilisateur est appelé repository et est identifié par un DID
  • À l’intérieur se trouvent plusieurs collections et records
• Un repository peut être hébergé n’importe où, et les liens restent valides même s’il est déplacé
• Les apps peuvent lire le repository comme un système de fichiers ou s’y abonner en temps réel via un flux (WebSocket)
  • Chaque commit est vérifié au moyen d’un arbre de hachage signé (Merkle tree), ce qui empêche la falsification des données
  • Les serveurs de relay se contentent de retransmettre les événements, la confiance venant de cette structure vérifiable

Exploration de l’Atmosphere et cas concrets

• pdsls.dev fonctionne comme un explorateur du système de fichiers social, en permettant de saisir un DID ou un handle
  • Il est possible d’y consulter directement chaque collection et chaque record
• L’app d’exemple Sidetrail reflète en temps réel les changements des records utilisateur, montrant que les données résident dans le repository et non dans l’app
• La démo teal.fm Relay visualise l’historique d’écoute musicale (scrobble) en indexant les records fm.teal.alpha.feed.play, sans API dédiée
  • L’outil lex-gql permet aussi d’exécuter des requêtes GraphQL fondées sur les Lexicons
• Dans Bluesky, les utilisateurs peuvent publier eux-mêmes des algorithmes de feed personnalisés
  • Par exemple, le feed « For You » de @spacecowboy17.bsky.social fonctionne indépendamment, ce qui permet à des tiers d’améliorer des fonctionnalités sur des données partagées

Conclusion

• Le système de fichiers social propose une architecture d’Internet centrée sur les données plutôt que sur les apps
• Les utilisateurs possèdent leur propre repository de données, et les apps fonctionnent de manière réactive au-dessus de celui-ci
• L’objectif n’est pas une « app qui fait tout », mais une « économie où tout devient possible »

[GN⁺]

Commentaires sur Hacker News

• Les apps peuvent disparaître, mais les fichiers restent
  Le billet de swyx souligne que ce qui dure finit par exister sous forme de fichiers ou de données
  Les données peuvent être analysées sans autorisation, et restent utiles même si elles sont partiellement corrompues, mais les incitations économiques continuent de tourner autour du code
  Si des standards apparaissent pour que le code puisse ingérer et exporter des données, cela créera une immense valeur pour l’ensemble de la civilisation
  Je pense que l’un de nos leviers les plus puissants est d’amener l’écosystème des développeurs à pousser des entreprises comme Google, Microsoft, OpenAI et Anthropic à participer volontairement à la standardisation des données

  • Je suis d’accord avec l’idée que « les fichiers sont la source de vérité »
    Mais les apps actuelles prennent la forme de sites web dépendants des revenus publicitaires, donc elles n’ont aucune incitation à fonctionner ainsi
  • Ce n’est pas parce qu’on donne à Google, MS, OpenAI ou Anthropic ce qu’ils veulent qu’on sera forcément récompensés
    Il suffit de regarder Apple pour voir que les standards ne changent pas toujours le monde
  • Ravi de lire ça :) Je n’avais jamais entendu parler de la « loi de l’indirection », mais c’est un concept assez intéressant

• Si le champ createdAt peut contenir une valeur arbitraire, est-ce que ça ne permet pas de réécrire rétroactivement l’historique comme on veut ?
  Je me demande s’il existe un moyen, via une signature, de vérifier le moment de création et de savoir si le contenu a été modifié ensuite

• On peut comprendre POSSE et l’AT Protocol comme une place de marché interopérable
  Comme sur Reddit ou Instagram, le contenu des utilisateurs est le produit, l’attention est la monnaie, et la plateforme gagne de l’argent via la publicité ou les données comportementales
  Mais cette structure n’a rien d’inévitable.
  Si les utilisateurs possèdent leurs données sociales, les apps deviennent des interfaces qui lisent ces données
  J’applique un modèle similaire au commerce — les vendeurs hébergent eux-mêmes leur logique de commande et de paiement, et la marketplace s’intègre directement à l’API du vendeur
  Cela permet de réduire les frais de plateforme et de rendre la propriété à ceux qui créent la valeur

  • J’ai vu openship dans votre profil, ça m’a intrigué, je vais aller voir

• Le billet est tellement détaillé qu’il m’a semblé un peu trop dense pour faire passer l’idée principale
  Cela dit, les analogies sont excellentes. Avec un navigateur de fichiers pour PDS, on pourrait probablement le ressentir directement
  Le PDS de Bluesky est en gros un système de fichiers public, avec la réplication intégrée dans la conception, un peu comme Git
  La réplication est incontrôlable, mais elle a aussi l’avantage des sauvegardes automatiques
  En pratique, ce qu’on met sur un PDS reste comme une archive permanente, donc il faut faire attention

  • Quand j’écris, mon objectif est de transposer telle quelle la structure que j’ai en tête
    Si c’est utile mais trop long, les autres peuvent simplement en prendre les parties qui les intéressent
    La section démo à la fin de l’article montre un véritable exemple de gestionnaire de fichiers
    L’expression « un monde où tout le monde devient scraper » résume l’essentiel
  • Avec pdsfs, on peut monter un PDS en lecture seule en local via FUSE
  • pdsls.dev remplit très bien ce rôle. C’est une app entièrement côté client et open source
  • Je me demande où en est le chiffrement d’atproto. Est-ce qu’il suffirait simplement de publier des données chiffrées en sha256 ?
  • ATProto n’est pas encore un protocole achevé, et la prise en charge des données privées devrait être ajoutée prochainement

• Je pense que la notion même de « fichier » est déjà dépassée
  Si on traite tout comme des blobs de données basés sur des hash, beaucoup de problèmes disparaissent
  Ce que veulent les utilisateurs, ce n’est pas une app mais une capacité
  Par exemple, « pouvoir regarder des vidéos de yoga » ou « pouvoir partager des nouvelles avec ses proches », et non YouTube ou Bluesky en tant que tels
  Les apps ne sont qu’une manière d’assembler ces capacités
  Il faut des workflows sur mesure, par exemple pouvoir chercher un mot dans une app de messagerie puis partager directement le résultat dans la conversation
  Je me suis inspiré de PerKeep

  • Le système de fichiers est une métaphore
    Je l’ai utilisé pour expliquer la « relation many-to-many entre les apps et les formats de fichiers »
    Si vous regardez la description de la structure des repositories d’ATProto, c’est basé sur une structure adressée par contenu fondée sur un arbre de Merkle
    Lexicon n’a pas de relation 1:1 avec les apps, donc AT se dirige déjà vers l’ère post-app

• Je pense que les plateformes fermées sont le résultat des préférences des consommateurs
  Quand Internet a tout ouvert, les gens ont commencé à vouloir de petits espaces centrés sur une culture ou des idées spécifiques
  IG ou Snap sont en quelque sorte des groupes de discussion très segmentés
  Et au fond, je préfère que mes posts IG ne soient pas partagés automatiquement sur HN ou Truth Social
  J’ai du mal à voir l’intérêt de la portabilité des données. Faire se croiser des plateformes aux contextes différents ne me semble pas très pertinent

  • Les apps ATProto ne partagent pas automatiquement tous les « fichiers » par défaut
    Anisota, que j’ai créé, a été conçu pour prendre en charge à la fois les fichiers de Bluesky et de Leaflet
    Par exemple, on peut voir le même post sur Bluesky et sur Anisota
    J’ai aussi créé un projet appelé Aturi pour fournir des liens universels vers le contenu basé sur ATProto
  • Quand Twitter a été racheté, j’aurais aimé pouvoir emporter avec moi mon identité, mes posts, mes likes et mon graphe social
    Avec ATProto, une app utilisant le même Lexicon permet une portabilité complète de l’identité et des données
  • Moi non plus, je ne vois pas très bien le besoin de portabilité des données
    Les images originales sont en local chez moi, et chaque plateforme n’est qu’une représentation différente
    Je ne veux pas d’une intégration sans sens entre plateformes
  • Si Truth Social n’avait pas retiré le code de fédération, les posts écrits depuis Mastodon et d’autres services y seraient apparus tels quels
  • C’est une bonne chose que différentes apps conservent chacune leur propre « ambiance »
    AT se contente de rendre l’interopérabilité possible, sans tout fusionner
    Par exemple, Leaflet récupère et affiche des posts Bluesky pour suivre les citations
    Grâce à cette structure, même si on fork un produit, il reste entièrement compatible avec le réseau, ce qui stimule la concurrence
    Blacksky en est un exemple concret : c’est un fork de Bluesky avec une politique de modération différente

• Les billets de Dan sont toujours intéressants. En lisant, on finit toujours par comprendre que c’est lui l’auteur

  • Merci :)

• Je suis sceptique face au modèle de données auto-descriptif
  L’affirmation d’ATProto selon laquelle « il suffit d’ajouter un Lexicon pour qu’un client apparaisse » me semble exagérée
  En pratique, pour construire une UI, il faut comprendre le sens des données, et Lexicon seul ne suffit pas
  Au final, ce n’est pas très différent du fait de lire la documentation et d’implémenter soi-même
  La standardisation est une bonne chose, mais ce n’est pas forcément un problème qui exige une base de données répliquée à l’échelle mondiale
  Cela dit, j’apprécie vraiment les efforts pour réduire le lock-in
  Mais le vrai problème qu’a connu Twitter relevait surtout de facteurs sociaux, comme les contenus politiques ou le spam

  • Dans l’exemple que vous donnez, s’il n’y a pas de client, c’est simplement parce que personne ne s’y intéresse
    Mais si un service apprécié comme Bento disparaît, quelqu’un voudra probablement restaurer ces données
    Par exemple, Blento est un remplaçant de Bento basé sur ATProto, open source, que n’importe qui peut remettre en ligne
    Ce type d’architecture constitue un progrès réel pour garantir la pérennité du contenu utilisateur

• En lisant The Unix Programming Environment, j’ai réalisé qu’on pouvait faire énormément avec de simples outils et des fichiers texte
  Ça m’a fait imaginer à quoi aurait ressemblé Slack s’il avait été conçu dans un style UNIX centré sur les fichiers
  J’aimerais revenir à des systèmes simples et composables

  • Unix a apporté d’excellentes idées d’architecture, mais traiter toutes les données en texte brut était une limite
    Une sérialisation lisible par les humains, c’est bien, mais devoir parser et reformater à chaque fois est pénible

• L’idée que de nouvelles plateformes sociales partagent des protocoles communs et des formats de données dans un environnement distribué et fédéré est intéressante
  Mais il sera sans doute difficile de convaincre les plateformes commerciales existantes
  Si ces standards s’imposent, les outils de social marketing pourront gérer plus facilement plusieurs réseaux de façon unifiée
  Mais dans la réalité, ce sont encore des écosystèmes fermés comme Facebook, Instagram et TikTok qui dominent