Open Social
import _img01 from "./open-social-01.svg"; import _img02 from "./open-social-02.svg"; import _img03 from "./open-social-03.svg"; import _img04 from "./open-social-04.svg"; import _img05 from "./open-social-05.svg"; import _img06 from "./open-social-06.svg"; import _img07 from "./open-social-07.svg"; import _img08 from "./open-social-08.svg"; import _img09 from "./open-social-09.svg"; import _img10 from "./open-social-10.svg"; import _img11 from "./open-social-11.svg"; import _img12 from "./open-social-12.svg"; import _img13 from "./open-social-13.svg"; import _img14 from "./open-social-14.svg"; import _img15 from "./open-social-15.svg"; import _img16 from "./open-social-16.svg"; import _img17 from "./open-social-17.svg"; import _img18 from "./open-social-18.svg"; import _img19 from "./open-social-19.svg"; import _img20 from "./open-social-20.svg"; import _img21 from "./open-social-21.svg"; import _img22 from "./open-social-22.svg"; import _img23 from "./open-social-23.svg"; import _img24 from "./open-social-24.svg"; import _img25 from "./open-social-25.svg"; import _img26 from "./open-social-26.svg"; import _img27 from "./open-social-27.svg"; import _img28 from "./open-social-28.svg"; import _img29 from "./open-social-29.svg"; import _img30 from "./open-social-30.svg"; import _img31 from "./open-social-31.svg"; import _img32 from "./open-social-32.svg"; import _jetstream from "./jetstream.mp4";
Cet article est une traduction française de « Open Social » écrit par Dan Abramov et publié le 26 septembre 2025 sur son blog overreacted.io. Traduit et republié avec son autorisation.
L'open source a clairement gagné. Oui, il existe une multitude de produits et d'entreprises propriétaires. Mais l'infrastructure partagée — les biens communs — fonctionne avec de l'open source.
Nous avons peut-être tendance à considérer cela comme acquis, mais ce n'était pas une conclusion évidente il y a trente-cinq ans. Des forces puissantes voulaient que l'open source échoue. Certains croyaient au modèle open source, mais ne pensaient pas qu'il pourrait un jour rivaliser avec le logiciel propriétaire. De nombreuses catégories d'outils n'existaient qu'en version propriétaire. Un PDG de Microsoft avait qualifié l'open source de cancer — dix ans avant que Microsoft ne rebâtisse son empire autour de lui. Le mouvement de l'open source n'a peut-être pas été à la hauteur des idéaux du « logiciel libre », mais il a gagné en adoption industrielle. Aujourd'hui, personne n'est renvoyé pour avoir choisi l'open source. Pour une grande partie des logiciels essentiels, l'open source est désormais l'option par défaut.
Je pense que nous sommes aujourd'hui, avec les applications sociales, à un tournant similaire à celui de l'open source il y a trente-cinq ans. Un nouveau mouvement se lève. J'aime l'appeler « open social ». Il existe plusieurs visions concurrentes de ce que devrait être l'« open social ». Je pense que le protocole AT créé par Bluesky est la proposition la plus convaincante à ce jour. Il n'est pas parfait, il est encore en construction, mais je ne connais rien qui lui ressemble.
(Précision : j'ai travaillé chez Bluesky sur l'application cliente Bluesky. Je n'ai pas participé à la conception du protocole. J'en suis un fan, et cet article est ma tentative d'expliquer pourquoi.)
Dans cet article, je vais expliquer les idées du protocole AT, affectueusement appelé atproto, et comment il change la relation entre l'utilisateur, le développeur et le produit.
Je ne m'attends pas à ce qu'atproto et son écosystème (appelé l'Atmosphère) conquièrent les cœurs du jour au lendemain. Comme pour l'open source, cela pourrait prendre quelques décennies avant de devenir omniprésent. En expliquant ces idées ici, j'espère faire avancer légèrement le calendrier. Malgré l'emprise des entreprises de médias sociaux actuelles, je crois que l'open social finira par apparaître, avec le recul, comme inévitable — tout comme l'open source aujourd'hui. Les bonnes choses peuvent arriver ; il suffit d'années d'efforts soutenus par une communauté de passionnés obstinés.
Alors, de quoi s'agit-il exactement ?
Ce que l'open source a fait pour le code, l'open social le fait pour la donnée.
Avant le social
Le web est une belle invention.
Vous tapez https://alice.com et vous arrivez sur le site d'Alice.
Ou vous tapez https://bob.com et vous arrivez sur le site de Bob.
Votre navigateur est en quelque sorte un portail vers des millions de mondes différents, chacun avec sa propre petite juridiction. Alice seule décide de ce qui apparaît sur le site d'Alice. Bob seul décide de ce qui apparaît sur le site de Bob. Ils sont réellement propriétaires de leurs données.
Cela ne veut pas dire qu'ils sont isolés. Au contraire, Alice peut intégrer une image de Bob avec un , et Bob peut renvoyer vers la page d'Alice avec un :
Alice et Bob peuvent se citer mutuellement, mais chacun reste maître de son site.
Qu'est-ce que je veux dire quand je dis qu'Alice et Bob sont maîtres de leurs sites ? Même s'ils n'hébergent pas physiquement leur contenu sur leur propre machine, ils peuvent toujours changer d'hébergeur. Par exemple, si l'hébergeur d'Alice commence à supprimer ses pages ou à y injecter de la publicité, Alice peut déménager son contenu chez un autre hébergeur et faire pointer https://alice.com vers une autre machine. Les visiteurs n'en sauront rien.
C'est important. Les hébergeurs n'ont pas de véritable prise sur Alice et Bob. Si l'hébergeur « devient malveillant » et commence à altérer votre site, vous pouvez simplement partir et l'héberger ailleurs (à condition d'avoir une sauvegarde). Vous ne perdez pas votre audience. Tous les liens existants continueront de résoudre vers la nouvelle destination.
Si Alice change d'hébergeur, Bob n'aura pas besoin de mettre à jour les liens vers le site d'Alice. Le site d'Alice continuera à fonctionner comme si de rien n'était. Au pire, un changement de DNS pourrait le rendre inaccessible pendant quelques heures, mais le web se réparera ensuite :
Imaginez à quel point les incitations seraient différentes si les liens étaient rattachés à des serveurs physiques !
Si changer d'hébergeur faisait perdre à Alice son audience, elle y réfléchirait à deux fois avant de le faire. Peut-être resterait-elle chez son hébergeur actuel même si celui-ci altérait son site, car perdre ses connexions serait pire encore. Heureusement, la conception décentralisée du web évite cela. Parce qu'il est facile de partir, les hébergeurs sont forcés d'être compétitifs, et l'hébergement est devenu un bien banalisé.
Je trouve que le web est une belle idée. Il relie des îlots décentralisés contrôlés par différentes personnes et entreprises en une seule surface interconnectée que chacun peut indexer et parcourir. Les liens décrivent une relation entre documents logiques plutôt qu'entre serveurs physiques. Résultat : vous n'êtes pas otage de votre hébergeur.
Comme disait un sage, en théorie il n'y a pas de différence entre la théorie et la pratique, mais en pratique il y en a une. Alors qu'est-il arrivé au web ?
Le social fermé
Au début des années 90, la façon principale de publier quelque chose sur le web était d'avoir son propre site. Aujourd'hui, la plupart des gens publient du contenu en utilisant une application de médias sociaux.
Alice et Bob continuent à publier des choses. Mais au lieu de publier sur des domaines comme alice.com et bob.com, ils publient sous des pseudos comme @alice et @bob attribués par une entreprise de médias sociaux. Les choses qu'ils publient ne sont plus des pages HTML, mais des entités propres à l'application : profils, publications, commentaires, mentions « j'aime », etc.
Ces entités sont généralement stockées dans une base de données sur les serveurs de l'entreprise sociale. La façon la plus courante de visualiser une base de données est comme une suite de lignes, mais on peut aussi la voir comme un graphe. Cela ressemble alors beaucoup au web lui-même :
Qu'est-ce que ce graphe social permet que le web des sites personnels ne permet pas ?
L'avantage de stocker des entités structurées propres à une application, comme des publications et des likes, plutôt que des documents HTML est évident. Ces entités ont une structure plus riche : on peut toujours les transformer en documents HTML plus tard, mais on peut aussi les agréger, les filtrer, les interroger, les trier et les recombiner de différentes façons avant cela. Cela permet de créer plusieurs projections des mêmes données — une page de profil, une liste de publications, une publication individuelle avec ses commentaires.
Là où cela prend vraiment tout son sens, c'est lorsque beaucoup de gens utilisent la même application sociale. Comme le contenu public de tout le monde se trouve désormais dans une seule base de données, il est facile d'agréger à travers le contenu publié par de nombreuses personnes. Cela permet des fonctionnalités sociales comme la recherche globale, les notifications, les fils d'actualités, les algorithmes personnalisés, la modération partagée, etc.
C'est précisément cette agrégation sociale qui balaye le paradigme des « sites personnels ». Les gens sont des créatures sociales, et nous voulons nous retrouver dans des espaces partagés. Nous ne voulons pas seulement visiter les sites des uns et des autres — nous voulons passer du temps ensemble, et les applications sociales fournissent l'infrastructure partagée. Des fonctionnalités d'agrégation sociale comme les notifications, les fils et la recherche sont incontournables dans les produits sociaux modernes.
Aujourd'hui, la façon la plus courante d'implémenter ces fonctionnalités a la forme suivante :
Il existe toujours un modèle logique de données similaire au web — nos profils, nos publications, nos abonnements, nos likes, tout ce que nous avons créé — mais il vit à l'intérieur de la base de données d'une application sociale. Ce qui est exposé au web n'est que des projections de ce modèle — la page d'accueil, l'écran des notifications, les pages HTML des publications individuelles.
Cette architecture a du sens. C'est la façon la plus simple de faire évoluer le paradigme des « sites personnels » pour supporter l'agrégation, et il n'est donc pas surprenant que les applications d'aujourd'hui aient largement convergé vers elle. Les gens créent des comptes sur des applications sociales, ce qui permet à ces applications de construire des fonctionnalités agrégées, ce qui incite plus de gens à s'inscrire à ces applications.
Cependant, quelque chose s'est perdu en chemin. Le web que nous créons réellement — nos publications, nos abonnements, nos likes — ne nous appartient plus vraiment. Même si une grande partie de ce que nous créons est publique, cela ne fait pas partie du web ouvert. Nous ne pouvons pas changer d'« hébergeur » parce que nous sommes désormais à un pas de distance du fonctionnement d'internet. Nous, et le web que nous créons, sommes devenus des lignes dans la base de données de quelqu'un d'autre :
Cela crée un déséquilibre.
Quand Alice publiait ses affaires sur alice.com, elle n'était liée à aucun hébergeur en particulier. Si elle était mécontente de son hébergeur, elle savait qu'elle pouvait en changer sans perdre son audience ni casser de liens :
Cela tenait les hébergeurs en respect.
Mais maintenant qu'Alice publie sur une plateforme de médias sociaux, elle ne peut plus « partir » sans perdre quelque chose. Si elle s'inscrit sur une autre plateforme sociale, elle serait forcée de repartir de zéro, même si elle veut conserver ses connexions. Il n'existe aucun moyen pour Alice de rompre la relation avec une application particulière sans s'arracher elle-même, ainsi que tout ce qu'elle y a créé, du graphe social :
Le web qu'Alice a créé — qui elle suit, ce qu'elle aime, ce qu'elle a publié — est prisonnier d'une boîte qui appartient à quelqu'un d'autre. Partir, c'est laisser tout cela derrière soi.
À l'échelle individuelle, ce n'est peut-être pas si grave.
Alice peut reconstruire sa présence sociale, connexion par connexion, ailleurs. Avec le temps, elle pourrait même retrouver la même portée que sur la plateforme précédente.
Cependant, collectivement, l'effet net est que les plateformes sociales — d'abord graduellement, puis soudainement — tournent le dos à leurs utilisateurs. Si vous ne pouvez pas partir sans perdre quelque chose d'important, la plateforme n'a aucune incitation à vous respecter en tant qu'utilisateur.
Peut-être que l'application est pressée par les investisseurs, et qu'une publication sur trois est désormais une publicité. Peut-être qu'elle est rachetée par un conglomérat qui voulait éliminer la concurrence et qui la maintient sous perfusion. Peut-être qu'elle est à court de fonds, et que votre contenu disparaîtra dans deux jours. Peut-être que les fondateurs sont acquihired — un excitant nouveau chapitre. Peut-être que l'application a été rachetée par un type, et vous êtes à présent cuisiné à petit feu par l'algorithme.
Si votre prochaine plateforme ne vous respecte pas non plus, vous pourriez essayer de la quitter, elle aussi.
Mais qu'allez-vous faire ? Allez-vous « exporter vos données » ? Que ferez-vous de ce fragment isolé d'un graphe social ? Vous pouvez l'uploader quelque part sous forme d'archive, mais c'est arraché de son contexte social — un piètre souvenir de votre exil auto-imposé.
Ces mégaoctets de JSON que vous récupérez en partant sont des données mortes. C'est comme une branche arrachée à son arbre. Cela n'a plus sa place nulle part. Pour donner une nouvelle vie à nos données, il faudrait collectivement les exporter, puis collectivement les importer dans une prochaine application sociale acceptée par tous — un exploit de coordination quasi impossible. Et même dans ce cas, les effets de réseau sont si forts que la plupart des gens finiraient par revenir en arrière.
Vous ne pouvez pas quitter une application sociale sans laisser derrière vous le web que vous avez créé.
Et si vous pouviez le conserver ?
Open social
Alice et Bob utilisent toujours des applications sociales. Ces applications ne ressemblent pas beaucoup à celles d'aujourd'hui. On pourrait à peine deviner que quelque chose a changé.
Quelque chose a pourtant changé. (Le voyez-vous ?)
Remarquez que le pseudo d'Alice est maintenant @alice.com. Il n'est pas attribué par une entreprise de médias sociaux. Son pseudo est plutôt le pseudo internet universel, c'est-à-dire un nom de domaine. Alice possède le domaine alice.com, elle peut donc l'utiliser comme pseudo sur n'importe quelle application open social. (Sur la plupart des applications open social, elle apparaît sous @alice.com, mais sur certaines elle préfère avoir une identité distincte et déconnectée, elle possède donc un autre pseudo qu'elle préfère ne pas partager.)
Bob possède aussi un domaine, même s'il n'est pas technique. Il ne sait peut-être même pas ce qu'est un « domaine ». Bob pense simplement à @bob.com comme son « pseudo internet ». Certaines applications open social vous proposent un sous-domaine gratuit à l'inscription, tout comme Gmail vous donne une adresse Gmail gratuite, ou peuvent offrir un parcours supplémentaire pour acheter un domaine. Vous n'êtes pas prisonnier de votre premier choix, et vous pouvez passer à un autre domaine plus tard.
Le fait que votre pseudo internet soit quelque chose que vous possédez réellement est l'aspect le plus visible pour l'utilisateur des applications open social. Mais la différence bien plus grande est invisible pour l'utilisateur.
Précédemment, quand vous voyiez le graphe social ci-dessus, il était prisonnier à l'intérieur de la base de données d'une application sociale. Il y avait une boîte autour de ce graphe — il ne faisait pas partie du web. Avec l'open social, les données d'Alice — ses publications, likes, abonnements, etc. — sont hébergées sur le web lui-même. À côté de son site personnel, Alice a désormais un répertoire personnel de ses données :
Ce « répertoire » est un serveur web classique qui implémente la spécification du protocole AT. Le seul rôle du répertoire personnel d'Alice est de stocker et de servir les données créées par Alice sous forme de JSON signés. Alice est technique, elle aime parfois inspecter son répertoire avec des outils open source comme pdsls, Taproot ou atproto-browser.
Bob, en revanche, n'est pas technique. Il ne sait même pas qu'il existe un « répertoire » avec ses « données ». Il en a reçu un discrètement quand il s'est inscrit à sa première application open social. Son répertoire stocke ses données (provenant de toutes ses applications open social).
Reprenons cette image :
Ce ne sont pas des lignes dans la base de données de quelqu'un. C'est un web de JSON hyperliés. De la même façon que chaque page HTML a une URI https:// pour que d'autres pages puissent y renvoyer, chaque enregistrement JSON a une URI at:// pour que n'importe quel autre enregistrement JSON puisse y renvoyer. (Sur cette illustration et les suivantes, @alice.com est un raccourci pour at://alice.com.) Le protocole at:// est un ensemble de conventions au-dessus de DNS, HTTP et JSON.
Regardez maintenant les flèches entre leurs enregistrements. Alice suit Bob, elle a donc un enregistrement follow qui pointe vers l'enregistrement profile de Bob. Bob a commenté la publication d'Alice, il a donc un enregistrement comment qui pointe vers l'enregistrement post d'Alice. Alice a aimé son commentaire, elle a donc un enregistrement like avec un lien vers son enregistrement comment. Tout ce qu'Alice crée reste dans son répertoire sous son contrôle, tout ce que Bob crée reste dans son répertoire sous son contrôle, et les liens expriment les connexions — tout comme en HTML.
Tout cela se passe en coulisses et est invisible pour un utilisateur non technique. L'utilisateur n'a pas besoin de penser à l'endroit où ses données sont stockées jusqu'à ce que cela devienne important, tout comme l'utilisateur ne pense pas au fonctionnement des serveurs quand il navigue sur le web.
Les répertoires d'Alice et de Bob pourraient être hébergés sur la même machine. Ou ils pourraient être hébergés par différentes entreprises ou communautés. Peut-être qu'Alice auto-héberge son répertoire, tandis que Bob utilise un service d'hébergement gratuit fourni par défaut avec sa première application open social. Ils peuvent même faire tourner des implémentations complètement différentes. Si les deux serveurs suivent le protocole AT, ils peuvent participer à ce web de JSON.
Notez que https://alice.com et at://alice.com n'ont pas besoin de pointer vers le même serveur. C'est intentionnel : avoir un joli pseudo comme @alice.com ne force pas Alice à héberger elle-même ses données, à toucher à son site web, ni même à avoir un site tout court. Si elle possède alice.com, elle peut faire pointer at://alice.com vers n'importe quel serveur.
Si Alice est mécontente de son hébergement, elle peut plier bagage et partir :
(Cela demande aujourd'hui un minimum de compétence technique, mais cela devient de plus en plus accessible.)
Comme pour le déménagement d'un site personnel, changer l'endroit où son répertoire est servi ne nécessite pas la coopération de l'hébergeur précédent. Cela ne perturbe pas non plus sa capacité à se connecter aux applications et ne casse aucun lien. Le web se répare tout seul :
Il vaut la peine de s'arrêter un instant pour apprécier ce que nous avons ici.
Chaque bribe de donnée publique qu'Alice et Bob ont créée — leurs publications, leurs likes, leurs commentaires, leurs recettes, leurs scrobbles — leur appartient vraiment. Ce n'est pas dans une base de données soumise aux caprices d'un PDG, mais hébergé directement sur le web ouvert, avec la possibilité de « partir » sans perdre son audience ni casser de liens.
Comme le web des sites personnels, ce modèle est centré sur l'utilisateur.
Qu'est-ce que cela signifie pour les applications ?
Chaque application open social est comme un CMS (système de gestion de contenu) pour un sous-ensemble de données qui vit dans les répertoires de ses utilisateurs. En ce sens, votre répertoire personnel joue un rôle similaire à un compte Google, un dossier Dropbox ou un dépôt Git, avec les données de vos différentes applications open social regroupées dans différents « sous-dossiers ».
Quand vous publiez sur Bluesky, Bluesky met cette publication dans votre répertoire :
Quand vous mettez une étoile à un projet sur Tangled, Tangled met cette étoile dans votre répertoire :
Quand vous créez une publication sur Leaflet, Leaflet la met dans votre répertoire :
Vous voyez l'idée.
Au fil du temps, votre répertoire devient une collection de données issues de différentes applications open social. Ces données sont ouvertes par défaut — si vous vouliez consulter mes publications Bluesky, mes étoiles Tangled ou mes publications Leaflet, vous n'auriez pas besoin d'appeler les API de ces applications. Vous pourriez tout simplement consulter mon répertoire personnel et énumérer tous ses enregistrements.
Pour éviter les collisions de noms, les données du répertoire sont regroupées par format :
Dans le répertoire de tout utilisateur, les publications Bluesky voisinent avec d'autres publications Bluesky, les publications Leaflet avec des publications Leaflet, les étoiles Tangled avec des étoiles Tangled, et ainsi de suite. Chaque format de donnée est contrôlé et évolue sous la responsabilité des développeurs de l'application concernée.
J'ai dessiné une ligne pointillée pour les séparer, mais c'est peut-être trompeur.
Comme les données de différentes applications « vivent ensemble », les applications open social ont beaucoup moins de barrières pour s'appuyer sur les données des autres. D'une certaine manière, cela commence à ressembler à un multivers connecté d'applications, avec des données d'une application qui « débordent » sur d'autres applications.
Quand je me suis inscrit à Tangled, j'ai choisi d'utiliser mon pseudo @danabra.mov existant. C'est logique puisque l'identité peut être partagée entre applications open social. Ce qui est plus intéressant, c'est que Tangled a prérempli mon avatar à partir de mon profil Bluesky. Il n'a pas eu besoin d'appeler l'API Bluesky pour cela ; il a simplement lu l'enregistrement de profil Bluesky dans mon répertoire. Chaque application peut choisir de s'appuyer sur les données des autres applications.
Cela peut vous rappeler Gravatar, mais cela fonctionne pour chaque type de donnée. Chaque application open social peut tirer parti des données créées par toutes les autres applications open social :
Il n'y a pas d'API à appeler, pas d'intégrations à construire, rien dont on puisse vous exclure. Toutes les données sont dans le répertoire de l'utilisateur, vous pouvez donc les analyser (en tant que JSON typé) et les utiliser.
Le protocole est l'API.
Cela a des implications profondes sur le cycle de vie des produits. Si un produit est fermé, les données ne disparaissent pas. Elles sont toujours dans les répertoires des utilisateurs. Quelqu'un peut construire un remplaçant qui redonne vie à ces données. Quelqu'un peut construire un nouveau produit qui intègre une partie de ces données, ou laisse les utilisateurs choisir ce qu'ils veulent importer. Quelqu'un peut construire une projection alternative des données existantes — un produit forké.
Cela réduit également le problème du « démarrage à froid » pour les nouvelles applications. Si une partie des données qui vous intéressent existe déjà sur le réseau, vous pouvez amorcer votre produit à partir de là. Par exemple, si vous lancez une application de courtes vidéos, vous pouvez vous appuyer sur les enregistrements follow de Bluesky pour que les gens n'aient pas à se retrouver. Mais si cela n'a pas de sens pour votre application, vous pouvez avoir vos propres enregistrements follow, ou proposer un import unique. Toutes les données existantes sont disponibles pour la réutilisation et le remixage.
Certaines applications open social sont explicitement construites autour de ce genre de remixage. Anisota est principalement un client Bluesky, mais il prend en charge nativement l'affichage de documents Leaflet. Popfeed peut republier des avis à la fois sur Bluesky et Leaflet. Si Leaflet devient très populaire, rien n'empêche Bluesky lui-même de supporter un document Leaflet comme un autre type de pièce jointe à une publication. En fait, un client Bluesky tiers pourrait décider de le faire en premier, et le client officiel pourrait suivre plus tard.
C'est pour cela que j'aime le terme « open social ».
L'open social libère nos données comme l'open source a libéré notre code. L'open social garantit que les anciennes données peuvent avoir une nouvelle vie, que les gens ne peuvent pas être expulsés du web qu'ils ont créé, et que les produits peuvent être forkés et remixés. Vous n'avez pas besoin d'une « application tout-en-un » quand les données de différentes applications circulent sur le web ouvert.
Si vous êtes technique, vous vous posez peut-être maintenant une question brûlante.
Comment diable l'agrégation fonctionne-t-elle ?!
Puisque les enregistrements de chaque utilisateur vivent dans le répertoire de cet utilisateur, il pourrait y avoir des millions (potentiellement des milliards ?) de répertoires. Comment une application peut-elle interroger, trier, filtrer et agréger efficacement des informations à partir de ceux-ci ? Elle ne peut certainement pas les chercher à la demande.
J'ai précédemment utilisé un CMS comme analogie — par exemple, une application de blog pourrait écrire directement des publications dans votre répertoire, puis lire les publications depuis celui-ci quand quelqu'un visite votre blog. Ce cas d'usage « en solo » ne nécessiterait aucune agrégation.
Pour éviter de solliciter le répertoire de l'utilisateur à chaque affichage d'une publication de blog, vous pouvez vous connecter au répertoire de l'utilisateur par un websocket. Chaque fois qu'un enregistrement pertinent pour votre application est créé, mis à jour ou supprimé, vous pouvez mettre à jour votre base de données :
Cette base de données n'est pas la source de vérité des données de l'utilisateur — c'est plutôt un cache propre à l'application qui vous évite d'aller solliciter le répertoire utilisateur chaque fois que vous avez besoin de données.
Il se trouve que c'est le mécanisme exact que vous utiliseriez pour l'agrégation. Vous écoutez les événements de tous les répertoires des utilisateurs de votre application, vous les écrivez dans une base de données locale et vous interrogez cette base de données autant que vous le voulez, sans latence supplémentaire.
Cela peut vous rappeler la façon dont Google Reader crawle les flux RSS (RIP).
Pour éviter d'ouvrir un million de connexions de socket d'événements, il est logique d'écouter un flux qui retransmet les événements de tous les répertoires connus sur le réseau :
Vous pouvez ensuite filtrer ce flux pour ne garder que les événements qui vous intéressent, puis mettre à jour votre base de données locale en réponse aux événements qui concernent votre application.
Par exemple, Leaflet ne s'intéresse qu'aux événements concernant les enregistrements pub.leaflet.. Cependant, Leaflet peut également choisir d'écouter d'autres événements. Si Leaflet voulait ajouter une fonctionnalité qui montre les backlinks des discussions Bluesky vers un document Leaflet, il commencerait simplement à suivre aussi les enregistrements . (Édit : on m'a informé que Leaflet le fait déjà pour afficher des citations depuis Bluesky.)
Vous pouvez voir le flux d'événements combiné de tous les répertoires connus ici :
C'est un flux en temps réel de chaque événement du réseau, capturé sur pds.ls
C'est un flux en temps réel de chaque événement du réseau. Il est dominé par les enregistrements app.bsky. parce que Bluesky est l'application la plus utilisée, mais vous pouvez le filtrer pour d'autres types d'enregistrement. Ce retransmetteur (appelé « relais ») est opéré par Bluesky, mais vous n'êtes pas obligé d'en dépendre. La communauté Blacksky fait tourner sa propre implémentation de relais à l'adresse wss://atproto.africa, que vous pouvez essayer ici. Peu importe quel relais est utilisé par quelle application — tout le monde « voit » le même web.
Un détail important : les commits sont signés cryptographiquement, ce qui veut dire que vous n'avez pas besoin de faire confiance à un relais ou à un cache de données réseau. Vous pouvez vérifier que les enregistrements n'ont pas été altérés et que chaque commit est légitime. C'est pour cela que « AT » dans « AT Protocol » signifie « authenticated transfer ». Vous êtes censé le prononcer comme « @ » (« at »). Ne dites pas « ay-tee » ou vous me mettrez la honte !
Au fil du temps, nous verrons plus d'infrastructures construites autour des applications open social. Graze vous permet de construire des fils algorithmiques, Quickslice et Tap simplifient l'indexation, Constellation et Slingshot vous permettent d'interroger des backlinks et des enregistrements en cache.
Mais tout cela n'est que détail technique.
Ce qui compte, c'est la vue d'ensemble.
La vue d'ensemble
Le web pré-social des « sites personnels » a fait le bon choix sur la propriété des données, l'indépendance vis-à-vis de l'hébergement et les liens. Alice et Bob participent pleinement au web :
Le web social fermé a innové sur l'échelle et sur les fonctionnalités d'agrégation sociale. Notifications, recherche et fils sont incontournables dans les produits sociaux modernes :
Cependant, le web social fermé nous a aussi exclus nous du web. Le web que nous créons ne nous appartient plus vraiment. Nous ne sommes que des lignes dans la base de données de quelqu'un d'autre.
L'open social libère le web que nous créons des boîtes de quelqu'un d'autre. Nos profils, likes, abonnements, recettes, scrobbles et autres contenus nous appartiennent vraiment :
Les données ne vivent plus à l'intérieur des produits ; les produits agrègent nos données :
Cela brouille les frontières entre les applications. Chaque application open social peut utiliser, remixer, référencer et improviser sur les données de toutes les autres applications open social.
Le web que nous avons créé subsiste après la disparition des produits que nous avons utilisés pour le créer. Les développeurs peuvent construire de nouveaux produits pour le recontextualiser. Personne ne peut nous le retirer.
À mesure que davantage de produits sont construits sur le paradigme open social, un basculement va se produire.
Les gens ne commenceront peut-être jamais à utiliser des concepts techniques comme « décentralisation », mais ils comprennent quand les données d'une application peuvent s'écouler sans effort dans d'autres applications.
Les gens ne se soucient peut-être pas de la « fédération », mais ils remarquent quand ils se connectent à un produit concurrent et que leurs données sont déjà là, et que leur audience est intacte.
Et les gens comprennent bien quand on se joue d'eux.
Pendant longtemps, l'open social reposera sur une communauté de passionnés obstinés qui voient la promesse de l'approche et sont prêts à supporter les peines de la construction (et de l'échec) dans un nouvel écosystème. Mais je ne pense pas que cela condamne l'effort. C'est l'histoire de tout grand changement porté par une communauté. Il faut bien que quelqu'un règle les problèmes. Comme pour l'open source, l'open social est un effort qui se cumule. Chaque application open social qui rencontre un semblant de succès porte toutes les applications open social. Chaque brique d'infrastructure partagée peut bénéficier à quelqu'un d'autre. À un moment donné, l'ouvert finira forcément par gagner.
J'espère juste que ça ne prendra pas trente-cinq ans.
Discussion in the ATmosphere