Le social ouvert

• De la même manière que l’open source est devenu le standard de l’infrastructure logicielle, un paradigme de « social ouvert » émerge aussi pour les applications sociales
• AT Protocol permet aux utilisateurs de posséder et de contrôler directement leurs données sociales, en proposant un concept distinct des plateformes sociales traditionnelles
• Les données sociales ne sont plus enfermées dans un service donné, mais stockées dans un espace de stockage personnel géré directement par l’utilisateur
• Cela rend possible la réutilisation et le remix des données entre applications, et même si un service s’arrête, les données ne disparaissent pas et continuent d’exister
• Avec l’essor du social ouvert, la propriété des données pilotée par l’utilisateur et une extensibilité flexible devraient s’imposer comme valeurs clés

---

Introduction : le succès de l’open source et une nouvelle dynamique

• L’open source, malgré de nombreuses résistances par le passé, s’est aujourd’hui imposé comme la base de l’infrastructure commune
• Contrairement au passé, choisir l’open source n’est plus problématique, et dans les domaines logiciels importants, l’open source est devenu le choix par défaut
• Nous faisons maintenant face, dans le domaine des applications sociales, à un point de bascule comparable à celui de l’open source il y a 35 ans
• Une nouvelle dynamique, le « social ouvert », a émergé, et l’AT Protocol de Bluesky est considéré comme sa mise en œuvre la plus convaincante

La structure de base du web et la propriété des données personnelles

• Sur le web d’autrefois, il existait des adresses personnelles comme alice.com et bob.com, et chaque utilisateur possédait son propre espace où il publiait librement son contenu
• Si l’hébergement ne convenait pas, on pouvait migrer ailleurs tout en conservant la même adresse, sans casser les liens existants
• Les utilisateurs n’étaient donc pas dépendants d’un hébergeur précis, et les prestataires devaient se faire concurrence
• Autrement dit, grâce à l’architecture décentralisée du web, l’utilisateur gardait la main sur ses données et les prestataires n’étaient que des fournisseurs

Réseaux sociaux modernes : la perte de propriété des données

• Aujourd’hui, au lieu d’exploiter leur propre site, les gens utilisent généralement des applications de réseaux sociaux où ils publient avec des identifiants comme @alice ou @bob fournis par une entreprise
• Les données comme les publications, commentaires ou mentions J’aime sont stockées dans la base de données d’une entreprise de réseaux sociaux donnée
• C’est cette structure qui a permis l’apparition de fonctions d’agrégation sociale comme la recherche, les fils, les recommandations et les notifications
• Mais elle a aussi pour effet secondaire que les données essentielles ne nous appartiennent plus
• Les utilisateurs se retrouvent dans une situation où ils ne peuvent pas emporter librement les données et les relations qu’ils ont créées

Le problème : des utilisateurs enfermés dans la plateforme

• Lorsqu’un utilisateur part, il doit laisser derrière lui tout le réseau de liens qu’il a construit
• Il ne peut pas changer facilement d’hébergeur, et quitter la plateforme signifie aussi perdre ses connexions et ses données
• Les plateformes le savent, si bien que les utilisateurs doivent souvent supporter des changements défavorables (surcharge publicitaire, algorithmes biaisés, suppression de fonctionnalités, etc.)
• Même lorsqu’on sauvegarde ou exporte ses données, il ne s’agit souvent que de « données mortes » privées de leur contexte social, difficiles à faire revivre ailleurs

Le social ouvert : restaurer la propriété des données et le réseau

• Dans le social ouvert, des identifiants fondés sur un domaine comme @alice.com donnent aux utilisateurs la propriété effective de leurs données sociales
  • Le nom est lié à un domaine que je possède, comme @alice.com
• Les utilisateurs gèrent directement toutes les données sociales qu’ils produisent via un stockage personnel (repository)
  • Les activités comme les publications, commentaires ou abonnements sont enregistrées dans un repository personnel (repo)
  • Le stockage n’est qu’un simple serveur web qui conserve des enregistrements au format JSON
  • Les adresses prennent la forme at://alice.com/..., ce qui permet de les relier entre elles
• Les stockages fondés sur l’AT Protocol fonctionnent au-dessus de DNS, HTTP et JSON, et chaque donnée est stockée sous forme de JSON hyperlié
• Même pour les personnes qui ne connaissent pas la technique, un stockage est créé automatiquement lors de l’inscription à une application, si bien que les données restent la propriété de l’utilisateur indépendamment de l’application
• Les données appartiennent au stockage de l’utilisateur, et même si le fournisseur de service change, la propriété des données et la connectivité sont préservées

Structure et usages des applications de social ouvert

• Chaque application de social ouvert gère une partie du stockage social de l’utilisateur comme un CMS, et l’application n’est plus qu’un outil qui lit et écrit dans le stockage de l’utilisateur
• Par exemple, les données d’applications différentes comme Bluesky, Tangled ou Leaflet peuvent coexister dans le stockage d’un même utilisateur
  • Si j’écris un message sur Bluesky, l’enregistrement est conservé dans mon stockage, et si je mets un projet en favori dans Tangled, cela est aussi enregistré dans mon stockage
  • Les formats de données sont séparés par des espaces de noms pour éviter les conflits (par exemple app.bsky.post, sh.tangled.star, etc.)
  • Avec le temps, mon stockage devient un ensemble de données provenant de plusieurs applications

Les changements d’écosystème apportés par l’ouverture des données

• Comme les données sont stockées de manière ouverte, il devient plus facile d’intégrer les applications entre elles, de créer de nouveaux services, de référencer librement les données des autres, de les réutiliser et de les remixer
• Même si une application s’arrête, les données restent dans le stockage de l’utilisateur et peuvent être réutilisées par d’autres services
• Les nouvelles applications peuvent exploiter les relations et données du réseau existant pour surmonter le problème du « cold start »
• Comme ces données sont lisibles par tous, d’autres applications peuvent les récupérer pour charger une photo de profil ou réutiliser les relations d’abonnement existantes
• Même si une application ferme, les données restent dans le stockage de l’utilisateur, et d’autres applications peuvent ensuite les ressortir et les réutiliser

Agrégation et défis techniques

• Les données des utilisateurs sont réparties dans leurs stockages respectifs, mais des flux d’événements de modification des données sont reçus via des abonnements WebSocket puis répercutés dans une base de données locale
• Des relais de grande taille permettent de recevoir les événements de tout le réseau et de ne filtrer que ceux qui sont nécessaires
• Les enregistrements de données sont signés cryptographiquement, ce qui garantit leur fiabilité et leur cohérence
• Par exemple, des infrastructures comme Graze et Slices prennent en charge l’agrégation du social ouvert

Et les fonctions d’agrégation, comment ça marche ?

• Chaque stockage utilisateur existe séparément, mais les applications reçoivent les flux d’événements en temps réel issus des stockages utilisateurs et les enregistrent dans leur propre base de données
• Des serveurs de relais comme ceux de Bluesky collectent et transmettent l’ensemble du flux, et les applications ne conservent que les événements qui les intéressent
• La base de données ainsi constituée permet de fournir rapidement des fonctions comme la recherche, les fils et les recommandations
• Les enregistrements de données sont signés cryptographiquement, ce qui garantit leur fiabilité et leur cohérence : il n’est pas nécessaire de faire confiance au relais pour vérifier l’authenticité des données
• Des infrastructures comme Graze et Slices prennent en charge l’agrégation du social ouvert

Vue d’ensemble

• Le web d’autrefois : l’utilisateur gardait la main sur son contenu et son adresse
• Les applications sociales actuelles : il existe des fonctions d’agrégation, mais les données restent enfermées dans des bases de données appartenant aux entreprises
• Le social ouvert : les fonctions d’agrégation sont conservées, tout en laissant les données entre les mains de l’utilisateur
• Les applications deviennent simplement une fenêtre qui rassemble et affiche les données de l’utilisateur
• Même si un service disparaît, les données restent disponibles et d’autres applications peuvent les réafficher dans un nouveau contexte

Conclusion

• L’essence du social ouvert consiste à combiner les avantages du web personnel (propriété des données, liberté d’hébergement, pérennité des liens) et les forces des réseaux sociaux fermés (agrégation, extensibilité)
• Le social ouvert garantit une propriété des données pilotée par l’utilisateur, une libre portabilité des données entre applications et la continuité des services
  • De la même manière que l’open source affirmait que « le code doit appartenir à l’utilisateur », ici aussi « les données doivent appartenir à l’utilisateur »
  • Cela résout le problème de la perte de données et de connectivité que subissent les utilisateurs sur les plateformes fermées
• À mesure que davantage de produits de social ouvert apparaîtront, les frontières entre applications s’estomperont et l’écosystème évoluera vers une circulation naturelle des données
  • En fin de compte, un avenir pourrait émerger où les utilisateurs contrôlent réellement leurs données et leur réseau
• Au départ, le mouvement sera sans doute porté par un petit nombre de développeurs et d’utilisateurs passionnés, mais à mesure qu’une base commune se construira, il est probable qu’un modèle ouvert finisse par s’imposer
  • Même sans comprendre des notions techniques comme la décentralisation ou la fédération, on peut ressentir des bénéfices concrets (interopérabilité des données, migration facile, continuité)
  • Le social ouvert se développera progressivement grâce à un effort communautaire de long terme et à des effets cumulatifs

[shakespeares]

Instagram est certes aussi un endroit où l’on conserve ses souvenirs, mais il semble difficile d’en partir librement.
Je pense aussi que, du point de vue du partage et de l’utilisation des données, il y a une certaine part de compromis à accepter.

[kimjoin2]

KakaoTalk... pff

[GN⁺]

Avis Hacker News

• Comme l’AT Protocol est le système de Bluesky, j’avais d’abord pensé que c’était une version corporate d’ActivityPub, mais après avoir lu cet article, j’aime beaucoup l’idée que les données soient stockées dans le « dépôt » (repository) que j’ai choisi. Cela correspond aussi à mon principe général : je pense qu’il vaut mieux faire le filtrage et ce genre de choses côté lecture plutôt qu’au moment de l’écriture. Donc il est préférable d’avoir une structure où je mets tout ce que je veux dans mon dépôt, et où les autres peuvent le lire et l’utiliser. Les flèches donnent l’impression que les commentaires arrivent dans mon dépôt, mais cela ressemble à une légère imprécision apparue en essayant d’exprimer l’idée. Dans l’ensemble, cela me semble être une architecture très élégante et décentralisée. Cela dit, quand j’ai essayé d’exploiter moi-même un PDS séparé sur AT, j’ai constaté que, même si c’est assez fluide et bien emballé, il y a quelques prérequis :

  1. gérer automatiquement des choses comme le SSL
  2. faire tourner un serveur HTTPS/WSS qui prend en charge diverses opérations RPC À cause de cela, même si je veux en pratique utiliser à la fois https://roshangeorge.dev et at://roshangeorge.dev, ce dernier nécessite aussi https://roshangeorge.dev/xrpc et wss://roshangeorge.dev. Au final, j’opère donc avec https://roshangeorge.dev et at://at.roshangeorge.dev, ainsi que https://at.roshangeorge.dev et wss://at.roshangeorge.dev. Bien sûr, c’est un détail mineur et cela ne remet pas en cause la direction générale. Mais je voulais quand même le signaler.

  • Je pense avoir semé la confusion en utilisant deux types de flèches. La flèche pleine (qui descend depuis @alice.com) indique la propriété. C’est la même logique que le regroupement par couleur. Tout ce qui est en bleu appartient à Alice. Les flèches pointillées sont des liens entre enregistrements. Comme avec <a href>, n’importe quel enregistrement peut librement pointer vers un autre, peu importe dans quel dépôt il se trouve. Si quelqu’un commente mon post, ce commentaire va dans le dépôt de cette personne et crée un lien avec le post d’origine. Le modèle de données a été conçu ainsi pour que, si la personne qui indexe possède les deux enregistrements, elle puisse facilement reconstituer la relation. Par exemple, si Bob commente le post d’Alice, le commentaire de Bob est dans le dépôt de Bob et le post d’Alice dans celui d’Alice. Si quelqu’un écrit un commentaire sur mon post, ce commentaire reste toujours dans le dépôt de cette personne. Le point essentiel est qu’on ne peut pas créer d’enregistrement dans le dépôt de quelqu’un d’autre.

  • Le packaging PDS par défaut prend en charge automatiquement le SSL, mais ce n’est pas obligatoire ; c’est surtout prévu pour que les développeurs puissent le mettre en place facilement. Les URI at:// sont de la forme at://DID/..., et les handles lisibles par des humains sont mappés au DID via un enregistrement DNS TXT (_atproto.roshangeorge.dev). Le DID pointe vers un document qui indique l’emplacement du serveur, ce qui permet de placer les routes HTTPS/WSS n’importe où. De plus, les likes, réponses, etc. faits sur mes posts vont dans le dépôt de la personne qui effectue l’action, pas dans le mien. Mon intuition sur ce point était donc correcte.

• Je pensais qu’ActivityPub était le meilleur protocole et qu’AT n’était qu’une imitation bon marché, mais cet article m’a fait comprendre qu’AT est bien meilleur. Le point clé, c’est que plusieurs programmes peuvent partager une même identité. C’est une fonctionnalité vraiment remarquable, et cela m’a réellement ouvert les yeux.

  • La plupart des explications sur ATProto se concentrent sur la propriété des données, mais en pratique, c’est ActivityPub qui est plus puissant sur la partie traitement des données. ATProto est structuré comme une vue publique sur le monde entier : tous les événements sont visibles par un AppServer global de confiance, qui doit tout juger lui-même, si bien que la génération des feeds, le contrôle d’accès, etc. dépendent tous d’intermédiaires de confiance. ActivityPub fonctionne plutôt comme RSS ou l’e-mail : mon serveur ne gère que les feeds auxquels je suis abonné, et l’inbox est directement composée des posts auxquels j’ai accès. C’est aussi pour cela que sur Bluesky, contrairement à Twitter, les « likes privés » sont impossibles. Chaque AppView doit suivre elle-même le nombre de likes pour tous les posts du réseau, ce qui est extrêmement pénible. À long terme, je pense que l’architecture d’ActivityPub sera plus avantageuse. Et concernant le fait que « plusieurs programmes partagent la même identité », cela existait en réalité déjà dans la conception initiale d’ActivityPub. Ce sont simplement les premières implémentations populaires qui ont retiré cette fonction pour s’adapter à leurs structures existantes.

  • Le débat AT vs AP est tellement complexe. Nous en avons déjà discuté de nombreuses fois dans notre communauté, donc je laisse ici un fil qui peut servir de référence : https://github.com/bevyengine/bevy/discussions/18302

  • Je suis heureux que cet aspect vous parle. C’est toujours frustrant de comparer systématiquement avec AP, car le périmètre est complètement différent.

  • Un article qui aborde une perspective similaire du point de vue d’un ingénieur en systèmes distribués pourrait aussi être intéressant : https://atproto.com/articles/atproto-for-distsys-engineers

  • Est-ce que cela signifie alors qu’il existe un service d’identité centralisé ?

• Peu m’importe quel protocole distribué l’emportera, mais même si l’ATProtocol paraît séduisant en théorie, en pratique ActivityPub me semble de plus en plus attractif. Je suis très actif sur Lemmy, et je trouve cela vraiment vivant et amusant.

  1. 99,99 % des utilisateurs d’AT sont concentrés sur Bluesky. C’est un service piloté par une entreprise. Même s’ils affirment ne pas contrôler le protocole, ils en sont dans les faits l’instance dominante, donc il existe un risque qu’ils le modifient à leur convenance. Je m’inquiète même qu’ils puissent un jour décider que la migration ne sera plus possible d’ici cinq ans. Ce genre de scénario s’est déjà répété de nombreuses fois sur différents réseaux sociaux.
  2. Les utilisateurs se moquent des protocoles ; l’inertie et la base d’utilisateurs comptent bien davantage. Même sur les différents remplaçants de Reddit basés sur AP, attirer des utilisateurs est déjà très difficile, et les convaincre de revenir ou de changer à nouveau l’est encore plus. J’ai peur qu’au final toutes ces tentatives ne fassent que fragmenter davantage de petites communautés, pour que tout le monde finisse par abandonner et retourner sur les plateformes dominantes. Le fait de pouvoir déplacer facilement son compte est certes une fonctionnalité sympa, mais avec des sauvegardes/restaurations de configuration et un processus déjà assez simple pour recréer un compte sur une nouvelle instance, cela ne change pas grand-chose. Site de référence : https://arewedecentralizedyet.online/ Lemmy, programming.dev, Piefed et d’autres sont aussi plutôt bien vus ces derniers temps.

  • Contrairement à Mastodon, la notion même d’instance est différente dans AT. Il y a plusieurs PDS au sein de l’infrastructure Bluesky, et cela fonctionne de façon structurellement hiérarchique et différente (voir l’article lié). Il n’est donc pas juste de parler d’une seule instance dominante. Bien sûr, la crainte qu’une entreprise pilote le protocole à sa guise est une préoccupation réaliste. Mais jusqu’ici, ils ont plutôt joué le rôle de bons administrateurs. Je pense que cela se résoudra progressivement à mesure que l’écosystème grandira. Et il y a aussi l’inquiétude que Bluesky ferme et rende toute migration impossible, mais le protocole intègre justement la sauvegarde et la migration. Tant qu’on a le fichier CAR, on peut migrer à tout moment vers un autre hébergeur. Mastodon perd beaucoup lors d’une migration de compte, alors qu’avec atproto, on peut migrer de façon 100 % transparente.

  • Au final, que l’on aille sur Bluesky ou Mastodon, on ne voit pratiquement que de la politique américaine. Je n’aime pas beaucoup le feuilleton politique hebdomadaire, donc des plateformes plus variées comme Tumblr, Pinterest ou TikTok me conviennent sans doute mieux.

  • Mastodon n’est pas exactement identique à ActivityPub, mais le fait que les réponses disparaissent soudainement me le rend peu fiable. Certains messages restent puis disparaissent ensuite, et c’est l’une des deux raisons pour lesquelles j’ai quitté Mastodon.

• Je trouve un peu dommage qu’au final, même si chaque application utilise ses propres types de collections et qu’elles peuvent partager certaines collections entre elles, on ne sache pas vraiment si les applications seront réellement interopérables. L’un des beaux aspects d’ActivityPub, c’est qu’un utilisateur de Mastodon peut suivre un utilisateur de Pixelfed sans avoir à y penser spécialement. C’est un peu comme si Twitter, Instagram, Reddit, YouTube et Substack se connectaient automatiquement entre eux sans configuration particulière.

  • Avec AP, plusieurs services s’interopèrent bien par défaut sur les types Status et Question. Mastodon, Pixelfed, Misskey, Pleroma, etc. tournent tous autour de cette structure. Mais la prise en charge des autres types est très limitée, donc les autres formes de contenu sont mal supportées. Le problème est le manque d’organisation communautaire autour des extensions hors standard. ATproto, lui, exige de suivre les définitions de lexicon/schema pour les collections de données, et les implémentations de référence comme tierces proposent une validation de schéma. L’interopérabilité de base est donc plus clairement structurée, mais je pense qu’il faudrait aussi davantage de souplesse, par exemple avec une prise en charge optionnelle de certains champs supplémentaires. Il existe aussi des cas comme Bridgy Fed, qui attache des métadonnées telles que l’URL d’origine ou le texte aux données venues d’APub. (Voir https://fed.brid.gy/docs#bluesky-fields)

  • Des efforts sont en cours pour améliorer les lexicons communs : https://github.com/lexicon-community

• Je commence à penser que les projets qui se présentent comme le « Twitter de nouvelle génération » passent légèrement à côté du problème dans leur manière de le résoudre. Après avoir parfaitement recréé les fonctionnalités de Twitter, ils se retrouvent seulement bloqués par le manque d’utilisateurs et de contenu — le classique problème de la poule et de l’œuf. Au final, les gens vont là où il y a déjà des gens, et c’est encore Twitter. À l’inverse, une direction comme la timeline récemment lancée par OpenAI me paraît plus pertinente : collecter d’abord les données en arrière-plan, puis les livrer à l’utilisateur. L’implémentation concrète peut varier, mais la direction me semble bonne. La plupart des utilisateurs n’accordent pas tant de valeur à la possibilité de publier des tweets ; la vraie valeur est dans la consommation des données (l’approvisionnement en contenu). Vu sous cet angle, un lecteur RSS multi-réseaux sociaux avec option P2P me paraît une meilleure direction. Ce n’est qu’un avis personnel.

  • Comme l’explique l’article, le microblogging sert d’abord de cadrage initial, mais en pratique on peut aller bien au-delà des seuls équivalents de Twitter. Par exemple, Tangled est du « Github sur atproto », et Leaflet du « Medium sur atproto ». La limite des approches P2P côté client, c’est qu’elles rendent difficile la gestion de l’agrégation à grande échelle et la garantie de cohérence, alors que ce sont des attentes de base dans la plupart des applications sociales grand public. L’exemple d’OpenAI est aussi précisément un domaine où atproto montre sa force. Les données existent déjà sur le réseau, donc il est facile d’y brancher crawling, indexation et outils d’automatisation. Pour un premier exemple, voir https://github.com/graze-social/iftta.

  • Les réseaux sociaux ne se développent pas selon une logique « la même chose, mais avec un petit plus ! », ils grandissent quand apparaît une manière nouvelle qui était impossible sur les plateformes précédentes.

  • C’est pour cela que Nostr est différent ! On peut y construire un blog, un équivalent de Twitter, un service de streaming, une messagerie, etc. Exemples : https://nostrapps.com

• Je me demande si un TLD gratuit serait possible. Quel est en réalité le coût de l’enregistrement d’un domaine ? Quand on voit que Let’s Encrypt a rendu les certificats gratuits, on peut se demander pourquoi une organisation à but non lucratif ne pourrait pas aussi fournir gratuitement des domaines. Ils n’ont même pas besoin d’être élégants. Empiler plusieurs UUID v7 me va très bien, du moment que c’est unique à l’échelle mondiale et gratuit. Une fois connecté, le navigateur s’en souviendra, donc une adresse longue n’est pas forcément un problème. Est-ce vraiment une si mauvaise idée ?

  • Dans atproto, c’est did:plc qui joue ce rôle. On peut obtenir un ID gratuit sur https://web.plc.directory/. Par exemple, mon ID est https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr. On peut ensuite l’associer à un domaine via un enregistrement TXT pointant vers ce did:plc.

  • Un TLD gratuit est en pratique difficile à réaliser. Les TLD et la public suffix list s’accompagnent de diverses règles, coûts et particularités de gestion ; voir https://github.com/publicsuffix/list. En revanche, les domaines ordinaires hors TLD peuvent être utilisés librement, et on peut distribuer des sous-domaines gratuits. Mais dès qu’on exploite réellement un tel service, on se prend vite de plein fouet le spam, le phishing et d’autres attaques du dark internet, au point de regretter de l’avoir lancé. C’est un peu comme les redirections d’URL : n’importe qui peut en créer une, mais l’exploiter en production est une tout autre affaire. Dès qu’on le fait sérieusement, les problèmes arrivent. C’est une réalité regrettable.

  • C’est en pratique proche de la distribution d’adresses IPv6. Aujourd’hui, la plupart des connexions internet résidentielles reçoivent un IPv6 public en /64, mais les FAI bloquent généralement les ports avec des firewalls, ce qui empêche de l’exploiter réellement. En plus, il est facile de perdre son adresse en changeant de FAI. Pour en faire de vraies adresses IPv6 permanentes et portables, il faudrait distribuer gratuitement aux particuliers un espace d’adressage provider-independent, puis le raccorder au routage global via BGP. C’est théoriquement possible, mais cela n’a encore jamais été mis en œuvre (un peu comme avant l’arrivée de Let’s Encrypt). Je ne vois pas bien pourquoi un système de nommage fondé sur DNS serait nécessaire ici, mais si l’objectif n’est pas d’avoir quelque chose de court et mémorisable, alors DNS n’est pas particulièrement adapté. En revanche, une approche à la ngrok, qui attribuerait des domaines via son propre gTLD, pourrait se tenter. D’ailleurs, le ccTLD .me a autrefois distribué des domaines gratuits de cette façon, en échange d’une insertion de publicité dans tout le trafic via un proxy intermédiaire.

  • .tk était gratuit, et c’était le plus grand ccTLD du monde en nombre d’enregistrements. Il était surtout connu pour les abus. Facebook a poursuivi l’opérateur (la société néerlandaise Freenom) pour son implication présumée dans le phishing, et la gratuité a depuis disparu.

  • Il existait autrefois une initiative de TLD .FREE, mais à cause de problèmes d’exécution et de délais non tenus, elle est aujourd’hui retombée dans l’oubli : https://icannwiki.org/.free

• Quand je vois un article de Dan, je clique. Le fait que l’open web ait réussi grâce à son avantage de premier entrant m’inquiète un peu. Mais quand je vois l’open source réussir, cela me redonne de l’espoir. J’aimerais vraiment voir un monde où quelque chose comme atproto réussit. C’est vraiment dommage que, à cause des effets de réseau, les meilleures applications n’arrivent pas à s’imposer.

  • Si HTML a réussi, c’est parce que c’était « gratuit ». À l’époque, il existait beaucoup de standards hypermédia payants, et contrairement à eux, celui-ci était très accessible. Tout le monde pouvait facilement créer un navigateur ou un serveur.

  • Le fait qu’ATProto soit conçu pour briser les limites des effets de réseau est aussi un énorme avantage. Si tout le monde migre vers atproto, alors il n’y a plus besoin de déplacer son réseau social « une toute dernière fois ». À terme, cela peut offrir un environnement décentralisé où la concurrence reste libre.

• En pratique, j’ai du mal à imaginer qu’un tel système puisse se diffuser largement. Le public visé par les réseaux sociaux traditionnels et celui attiré par la décentralisation sont complètement différents. La plupart des gens ne s’intéressent qu’à la plateforme comme simple outil, pas au système sous-jacent. Si tout le monde finit juste par créer un compte Bluesky, cela se concentre de nouveau sur quelques gros services comme avant, et tout cela perd son sens.

  • Même si tout le monde se regroupe sur bsky.social, ce serait déjà un immense progrès par rapport à aujourd’hui. De la même manière qu’on ne dit pas que le web est centralisé simplement parce qu’une grande quantité de serveurs tourne sur AWS, chacun peut partir à tout moment si nécessaire.

  • En réalité, Bluesky n’a pas encore implémenté une fédération complète. Tout le trafic dépend d’un seul serveur routeur « BGS ».

  • Malheureusement, au fond, la source du problème, ce sont les gens.

• Je suis partagé sur tout cela. D’un côté, l’idée correspond totalement à mes goûts. Elle s’inscrit dans la continuité du mouvement Indie Web, où chacun possède son propre contenu, et je suis vraiment impressionné par le soin apporté à cette page et à ces articles. D’un autre côté, très peu de développeurs appliquent réellement ce type de standard à leur blog personnel ou à leurs projets open source, et même chez les blogueurs/vlogueurs ou les utilisateurs ordinaires, l’adoption reste faible. Le fait que tant de gens soient indifférents à la propriété des données, à l’ouverture et à l’interopérabilité m’inquiète. On dirait que les gens ne veulent plus que des feeds comme TikTok ou les Reels Instagram. Je respecte la vision et les efforts, mais je me demande si cela peut vraiment devenir grand public plutôt qu’un hobby de niche.

  • Il reste encore à améliorer l’expérience développeur pour la rendre plus simple. Mais le rythme de progression dans cet espace est extrêmement rapide, et les 6 à 12 prochains mois me semblent très prometteurs. La plupart des gens ne comprennent pas encore qu’ATProto ne se limite pas à Bluesky et peut s’appliquer à des domaines bien plus variés ; il faudra du temps pour que cela apparaisse plus concrètement sur le marché.

  • Je me demande pourquoi la notion de « propriété des données » est jugée si importante, et en quoi le fait que le grand public ne s’en soucie pas serait réellement inquiétant. Par le passé, les gens ont toujours consommé des contenus sans propriété, comme la télévision, les livres ou la radio. Aujourd’hui, on leur donne simplement la possibilité de publier quelque chose et de le montrer à leur entourage ; mais est-ce si important de savoir si l’on « possède » vraiment son post Instagram ?

  • Je suis d’accord. Au final, si nous voulons que cette technologie réussisse, nous devons nous-mêmes la diffuser activement et contribuer à sa popularisation. Peut-être qu’un jour, un fondateur ou un CTO passionné par l’open social lancera une application grand public à succès ; mais si l’on ne fait rien, cela ne réussira jamais.