Il n’y a pas d’instances dans atproto

 (overreacted.io)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Chercher une « instance Bluesky » revient à appliquer tel quel à atproto le modèle d’instance de Mastodon, alors qu’atproto a été conçu en séparant l’hébergement et l’agrégation applicative
  • Comme avec RSS et Google Reader, les données ne sont pas enfermées dans l’application mais dans un référentiel hébergé, et plusieurs applications les récupèrent puis les affichent
  • Une instance Mastodon regroupe dans une seule boîte l’hébergement, l’application, l’identité et les relations de fédération, si bien que les décisions des administrateurs ou les pannes de l’instance affectent directement l’expérience utilisateur
  • Avec atproto, l’utilisateur peut changer d’hébergement ou créer et essayer de nouvelles applications, et des apps comme Tangled, Semble ou Sidetrail fonctionnent indépendamment de Bluesky
  • Pour juger de la décentralisation d’atproto, il faut moins regarder le nombre d’instances Bluesky que vérifier si la migration vers des hébergements alternatifs et le nouvel écosystème d’applications fonctionnent réellement

Un modèle plus proche de RSS et Google Reader

  • À l’époque de RSS, les utilisateurs publiaient sur leur propre blog, et des applications comme Google Reader ou Feedly agrégeaient les articles de plusieurs blogs
  • Les articles ne « vivent » pas dans Google Reader, ils restent sur chaque blog ou à l’endroit où ils sont hébergés
  • L’idée clé est la séparation entre hébergement et agrégation
    • l’hébergement est l’endroit où le contenu existe réellement
    • l’application d’agrégation ressemble davantage à une projection de contenus issus de multiples sources

Les réseaux sociaux centralisés et la réponse de Mastodon

  • Les réseaux sociaux traditionnels fonctionnent en rassemblant tous les utilisateurs dans une seule application et un seul espace
  • Cette structure produit de la centralisation et de forts effets de réseau, et la réflexion sur les réseaux sociaux décentralisés part de la question de savoir comment découper ce problème
  • L’approche à la Mastodon consiste à faire fonctionner pour chaque communauté son propre « petit Facebook » ou « petit Twitter », et cette boîte est l’instance

Ce que regroupe une instance Mastodon

  • L’utilisateur appartient à l’intérieur d’une instance donnée
    • si la forme de connexion Mastodon est [email protected], c’est parce que l’instance fait partie de l’identité
    • l’utilisateur n’est pas une « Alice » abstraite, mais « Alice de l’instance n°1 »
  • Pour que des utilisateurs de différentes instances puissent communiquer, les instances doivent s’échanger des messages
    • si Alice est sur l’instance n°1 et Bree sur l’instance n°2, quand Alice suit Bree, les publications de Bree sont transmises à l’instance n°1
    • cette relation de transmission est la fédération
  • Comme l’hébergement et l’application sont liés ensemble, l’utilisateur dépend fortement de son instance

Les contraintes créées par ce couplage des instances

  • En cas de conflit entre administrateurs d’instances, ils peuvent interrompre la fédération entre eux
    • dans ce cas, les utilisateurs peuvent ne plus voir les publications de leurs amis
  • Si l’instance d’un utilisateur tombe, l’identité liée à cette instance disparaît aussi
    • car les abonnés suivent « l’utilisateur de cette instance »
  • Le nombre de flèches de connexion entre instances augmente en O(n²)
    • ce n’est peut-être pas un gros problème aujourd’hui, mais cela pourrait le devenir si ce type de réseau social devient populaire

La différence clé d’atproto

  • atproto ne part pas du concept d’instance à la Mastodon et revient plutôt au modèle RSS + Google Reader
  • Il sépare au niveau du réseau l’hébergement et l’agrégation
    • les données résident dans l’hébergement
    • les applications agrègent des données provenant de l’hébergement de nombreuses personnes
  • C’est pourquoi il n’y a pas d’instances dans atproto
    • l’hébergement peut être changé
    • les applications agrègent les données de multiples hébergements
  • Cette structure se lit comme une forme de décentralisation plus riche que le simple fait d’exploiter plusieurs copies d’une même application

Une décentralisation que les utilisateurs peuvent pratiquer eux-mêmes

  • Les utilisateurs peuvent changer d’hébergement
  • Il est aussi possible d’essayer de nouvelles applications ou d’en créer soi-même

Pourquoi le « nombre d’instances Bluesky » est une mauvaise mesure

  • Dans Mastodon, il est naturel de mesurer la décentralisation au nombre d’instances
    • car la principale manière d’y distribuer le réseau consiste à faire tourner davantage de boîtes où hébergement et application sont couplés, puis à les faire communiquer
  • Dans atproto, toutes les applications sont proches d’une projection de l’ensemble de l’Atmosphere
    • c’est la même structure que Feedly ou Google Reader montrant l’ensemble de la Blogosphere
  • Il est possible d’exploiter plusieurs copies complètes du serveur de base de données de Bluesky, mais cela n’est généralement pas plus utile que de faire tourner de nombreuses copies de Google Reader
  • Certaines copies existent pour des besoins spécifiques
    • Blacksky est un exemple répondant à des besoins particuliers, comme une autre philosophie de modération
    • le client reddwarf.app n’utilise pas de base de données dédiée, mais le cache gratuit géré par la communauté, constellation
  • Des infrastructures réseau partagées comme Relay auraient été exploitées à faible coût pendant un an

Les bons critères à regarder dans atproto

  • Pour juger de la décentralisation d’atproto, il ne faut pas regarder le « nombre d’instances Bluesky », mais plutôt les points suivants
    • est-ce que des gens migrent vers des hébergements alternatifs ?
    • est-ce que des gens créent et utilisent de nouvelles applications ?
  • Séparer l’hébergement et l’application peut corriger les incitations défaillantes aussi bien dans les réseaux sociaux fermés que fédérés
  • Le cœur d’atproto est de garder les données des utilisateurs hors des applications, et de laisser celles-ci les agréger par-dessus

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires Hacker News

  • La question « où est l’instance Bluesky ? » semble être volontairement mal interprétée pour mettre ATProto en avant et rabaisser ActivityPub
    Cela finit par omettre ou déformer des faits techniques intéressants, comme les relais d’ATProto et leurs avantages et inconvénients, ou encore la migration de compte dans ActivityPub et ses forces et faiblesses, et crée un conflit inutile entre deux plateformes qui essaient de résoudre des problèmes similaires
    Certaines personnes emploient peut-être aussi « instance » dans un sens plus général, pour parler d’un serveur, d’un logiciel en cours d’exécution, d’une machine virtuelle ou d’un conteneur ; je ne vois pas pourquoi il faudrait absolument l’entendre uniquement au sens de Mastodon
    Les diagrammes et les explications étaient bons, mais les petites piques contre ActivityPub donnaient malheureusement l’impression de venir davantage d’une hostilité de fond que d’une volonté d’informer

    • Le ton du billet était volontairement un peu taquin, mais je pense que la question « où est l’instance Bluesky ? » revient souvent à cause d’une incompréhension de l’architecture, où le nombre d’instances d’application est pris comme mesure de la décentralisation
      La comparaison avec « où est l’instance Google Reader ? » me semblait bien montrer le caractère bancal de cette question, et je pense que les deux schémas à la fin de l’article éclairent assez bien des points souvent négligés dans les premières discussions sur atproto/ActivityPub
      J’ai expliqué pourquoi je n’avais pas inclus les relais ici : https://news.ycombinator.com/item?id=48600963
      Les relais relèvent davantage d’une optimisation des performances que du cœur du modèle, donc je voulais que l’article se concentre sur le modèle lui-même
    • Cela dépend du contexte, mais dans les discussions autour d’ATProto, d’ActivityPub et de Mastodon, « instance » désigne souvent un nœud ActivityPub qui héberge les données utilisateur et les URL de profil, et l’article semble viser ce contexte précis
      À mesure que le mot se charge d’un concept et d’une structure spécifiques, beaucoup de gens voient « réseau social décentralisé » et imaginent une fédération à la ActivityPub ; puis, en regardant ATProto, ils demandent : « pourquoi n’y a-t-il qu’une seule instance Bluesky où les gens s’inscrivent ? »
      Ce n’est peut-être pas une perspective entièrement nouvelle, mais cela me semble être un article utile à relier plus tard pour les personnes chez qui ces associations d’idées préexistantes sont déjà bien ancrées
    • ATProto contre ActivityPub, cela ressemble peut-être au grand schisme d’Orient et d’Occident du Fediverse
      Sauf qu’au lieu d’un édit sur le « filioque », on a des billets de blog où chaque camp parle d’autre chose en donnant sa propre définition de la « fédération »
    • Je pense qu’il est utile de distinguer et de comparer Mastodon et ATProto
      Le modèle Fediverse est facile à comprendre depuis le point de vue des réseaux sociaux existants, mais ATProto est un nouveau concept qui cherche à donner aux utilisateurs la souveraineté sur leurs données tout en obtenant la scalabilité d’un réseau social centralisé

  • À mon avis, l’analogie ici ne tient pas
    RSS ne dépendait absolument pas de Google Reader, et même à son apogée, il en dépendait moins que l’e-mail ne dépend aujourd’hui de Gmail
    Dans ATProto, pour qu’un AppView devienne utile, il dépend fortement des relais, et le coût d’exploitation de ces relais est aussi assez élevé
    En outre, le cercle jaune dans le schéma RSS représente un blog, alors que les cercles représentant des publications Facebook sont d’une autre nature. Un blog est autonome en lui-même
    Je ne dis pas qu’ATProto est mauvais, mais cet article me semble ajouter de la confusion plutôt que d’apporter de la clarté

    • Les relais sont désormais en pratique assez bon marché
      Avant, ils coûtaient un peu plus cher parce qu’ils stockaient tout le trafic, mais cette partie a été retirée dans sync 1.1, et aujourd’hui on peut en faire tourner un assez facilement même sur une machine virtuelle à 20 dollars par mois
    • Les relais font bien partie des composants relativement lourds de l’infrastructure AT Protocol, mais leur coût d’exploitation tourne aujourd’hui autour de 30 dollars par mois, ce qui reste abordable pour la plupart des gens
      Ce qui est vraiment cher et difficile, que l’on soit dans un modèle centralisé ou décentralisé, c’est la modération
      L’auteur de cet article avait traité il y a 9 mois un malentendu fréquent au sujet des relais : https://news.ycombinator.com/item?id=45077291#45078223

  • À mes yeux, les relais sont la colle qui permet à ATProto de bien fonctionner en pratique
    Ils transportent les données sans se soucier du contenu et semblent surtout servir à réduire le nombre de services que chaque AppView doit connaître
    Comme le dit aussi l’article, la grande amélioration par rapport à Mastodon est que les relais, les AppView et les PDS sont des services séparés avec des besoins de montée en charge différents, et c’est une solution assez élégante à un problème d’architecture système
    [1] https://atproto.com/guides/glossary

    • Oui, les relais sont une manière de faire cela
      Cela dit, c’est une optimisation invisible, et comme il existe d’autres stratégies, je l’ai en grande partie laissée de côté dans l’article
      Par exemple, beaucoup de petites applications aujourd’hui ne construisent pas leur propre index de base de données et s’appuient à la place sur Constellation(https://constellation.microcosm.blue/), donc elles n’utilisent pas du tout de relais
    • Il arrive aussi que du contenu soit supprimé directement au niveau des relais
      Ils affirment ne retirer que les contenus dont l’hébergement serait illégal, mais je ne sais pas dans quelle mesure c’est vrai, et il y a toujours un risque que cela change à l’avenir
      https://docs.bsky.app/blog/blueskys-moderation-architecture#...

  • Le fait d’expliquer la différence entre les deux approches était appréciable.
    En revanche, c’était frustrant de ne pas répondre à la question : « comment ATProto résout-il le problème que les instances résolvent ? »
    Par exemple, si le billet réduit la défédération à une sorte de raison obscure expliquant pourquoi on peut ne pas voir les publications d’un ami, alors il ne répond pas à la question : « dans ce cas, comment atproto résout-il le problème que la défédération résout ? »
    Dans ce cadrage, la réponse de base qui vient naturellement est : « il ne le résout pas »

    • S’il s’agit de parler de modération, cela fonctionne à peu près comme on pourrait s’y attendre dans un monde où tout est du RSS.
      Au niveau de l’hébergement, un hébergeur peut bloquer un compte pour quelque chose de manifestement illégal, comme blogspot.com ou Cloudflare le feraient sur certains sujets.
      Au niveau de l’application, les administrateurs d’apps et les modérateurs arbitrent comme dans d’autres services web gérant du contenu généré par les utilisateurs.
      C’est un choix de l’éditeur de l’application : il peut fournir des éléments de base de modération d’espaces utilisateurs comme Reddit, ou brancher un service de modération séparé comme Bluesky.
      Comme il n’existe pas d’équivalent à des « instances communautaires » pouvant entrer en conflit entre elles, il n’y a pas non plus de défédération. Il n’y a que de l’hébergement, des apps et de la modération au niveau de l’app selon les choix de l’app et de son éditeur.
    • À mon avis, la meilleure question est plutôt : « comment ActivityPub résout-il les problèmes créés par la défédération ? »
      C’est fondamentalement très proche de ce que fait Microsoft avec l’email. En dehors des plus gros fournisseurs, il jette les messages, et en pratique il fédère de telle sorte que, pour faire parvenir leurs messages, les utilisateurs doivent passer par Microsoft ou un autre grand acteur établi.
      Les nouvelles instances ne peuvent alors plus faire passer de messages ni gagner d’utilisateurs. Cela crée, pour les grands acteurs en place, une incitation perverse à ne pas se fédérer avec les nouvelles instances.
      Ce choix d’architecture a, à long terme, pour effet de consolider un oligopole.
      On dit que c’est nécessaire contre le spam, mais certains fournisseurs ne le font pas, tout en restant généralement capables de délivrer vers Gmail s’ils configurent correctement DKIM, le reverse DNS, etc., et ils n’ont pas davantage de problèmes de spam pour autant.
      L’alternative évidente consiste à filtrer côté client. Si le filtrage est fourni non pas par un opérateur comme Microsoft mais par un fournisseur de listes de filtres du type uBlock, il n’a aucune incitation à attirer tout le monde sur sa propre instance puisqu’il n’exploite pas lui-même une instance donnée.
    • Cela ne résout pas ce problème.
      À moins d’imaginer un univers alternatif où il existe énormément d’AppView capables de consommer l’intégralité du firehose, entre lesquels on peut choisir librement, et qu’on peut exploiter soi-même à faible coût.
      ATProto se rapproche plutôt d’un RSS dans un monde où l’on ne pourrait lire RSS qu’avec Google Reader ou un service clone de taille comparable, sans lecteur RSS sur ordinateur ou mobile.

  • Si ça cancane comme un canard, c’est un canard.
    Un compte a un seul PDS, et le DID pointe vers le PDS qui constitue le flux de données canonique de l’utilisateur ainsi que sa cible d’écriture.
    Les données peuvent être répliquées, mais le PDS est traité comme la source de vérité.
    Cela ressemble bien davantage à une architecture client/serveur qu’à une architecture distribuée.
    Il n’y a pas de base de données P2P, pas d’écriture dans une DHT ni chez des pairs. On écrit dans un PDS, puis cette écriture est mise en miroir de manière optionnelle.
    La découverte se fait aussi via DNS, donc on ne demande pas non plus les données à des pairs.
    On se connecte aux relais non pas comme à des pairs, mais comme à des clients qui demandent des copies de données dont la version canonique est hébergée sur le PDS.
    Je ne pense pas qu’il soit exagéré d’appeler le PDS une instance et le relais un miroir.

    • Cette formulation me paraît acceptable.
      Il faut simplement noter que ce n’est pas ce que les gens veulent généralement dire quand ils parlent d’« instance » à propos de Mastodon.
      Dans Mastodon, une instance est un ensemble indissociable combinant hébergement des données, application, communauté et modération.

  • Je comprends qu’ATproto sacrifie la vraie décentralisation au profit de la cohérence, tandis que Mastodon et ActivityPub sacrifient la vraie cohérence au profit d’une décentralisation plus accessible
    parce qu’exploiter un nœud ActivityPub est bien plus accessible pour un utilisateur ordinaire en auto-hébergement qu’exploiter un relais de contenu AT
    Au final, ce qu’on peut « décentraliser » sur AT, ce sont seulement ses propres données, et cela se rapproche davantage de la propriété de ses données que d’une copropriété d’une partie du réseau
    C’est aussi quelque chose qui a déjà été répété plusieurs fois sur HN

    • C’est un point de vue intéressant, mais d’après ma compréhension actuelle, AtProto me semble plus accessible et plus décentralisé
      Avec ActivityPub, gérer une instance signifie prendre en charge les données, l’application et les problèmes d’extension qui suivent, donc il faut soit assumer soi-même cette responsabilité d’exploitation, soit dépendre de l’instance de quelqu’un d’autre
      Et même si on n’aime pas l’instance qu’on a choisie et qu’on veut migrer, si cela n’a pas encore changé, on est pratiquement obligé de repartir de zéro
      Avec AtProto, il est facile de passer à une autre plateforme applicative tout en gardant la même identité, et il est aussi possible, au moins en théorie même si l’expérience utilisateur reste difficile, d’exporter ses données depuis la plateforme pour les auto-héberger
      Par exemple, j’ai essayé Tangled récemment pour la première fois, et j’ai pu me connecter avec mon domaine existant basé sur bsky (h14h.com). Je n’ai pas eu besoin de créer un nouveau compte ni un nouveau nom d’utilisateur, j’avais l’impression d’être déjà là
      La configuration pour auto-héberger un dépôt git sur un VPS m’a pris au plus une demi-journée, et cela tourne comme un service backend qui ne demande presque aucune attention
      Dans le pire des cas, un bandeau apparaît sur tangled.org disant quelque chose comme « le dépôt est ancien et peut ne pas être compatible avec la dernière version de Tangled », et il suffit de reconstruire puis redéployer l’image Docker avec la version la plus récente
      D’un point de vue architectural, AtProto est clairement plus difficile à appréhender mentalement, mais je pense qu’il est bien plus simple dès qu’il s’agit de le mettre réellement en contact avec des utilisateurs
    • Je ne sais pas vraiment s’il existe une « vraie » décentralisation
      Dans ma tête, cela ressemble moins à un curseur unique qu’à un buffet de compromis
      À noter qu’au sein du monde AP aussi, des individus et de petites équipes exploitent des relais, des miroirs, des caches, des AppView, etc. En revanche, il est vrai que cela peut coûter plus cher à mesure qu’on change d’échelle
    • C’est en partie vrai, mais cela n’explique pas tout
      AT ne fournit pas seulement de la cohérence, mais aussi un modèle de données partagé à l’échelle des applications
      Cela permet aux applications de référencer et d’afficher le contenu d’autres applications. C’est une sorte de web de JSON typé, et les différentes applications sont des lentilles qui regardent le même réseau
      N’importe qui peut créer une nouvelle expérience au-dessus des données existantes, et il n’y a presque pas d’équivalent à cela dans AP
      AP couple les données à l’application, alors qu’AT se rapproche davantage d’une base de données globale unique contenant les données du monde entier, que toutes les applications interrogent
      Je ne comprends pas pourquoi la discussion se bloque toujours sur les relais. Aujourd’hui, si on le souhaite, on peut faire tourner un relais pour environ 30 dollars par mois, et on peut aussi utiliser gratuitement Bluesky ou des relais communautaires
      Beaucoup d’applications n’utilisent aucun relais du tout et s’appuient sur des index communautaires comme Constellation(https://constellation.microcosm.blue/). Il existe même des applications qui ne font tourner ni leur propre serveur ni leur propre base de données
    • Mastodon a aussi des relais de contenu
      Mais j’aurais plutôt tendance à soutenir l’inverse : ATproto est plus décentralisé, ou au moins essaie davantage de l’être
      Dans l’univers ActivityPub, l’identité, l’application et l’hébergement sont fondamentalement liés
      Pour utiliser Lemmy, il faut soit créer un deuxième compte ActivityPub permanent et séparé sur cette instance Lemmy, soit n’utiliser Lemmy que dans la mesure où mon instance Mastodon sait envoyer des messages que Lemmy comprend
      Chaque nouvelle application ActivityPub crée de nouveaux problèmes d’interopérabilité, parce que chaque application possède sa propre identité et son propre hébergement
      Il n’existe aucun moyen pour mon instance Mastodon auto-hébergée de fournir mon identité à un serveur Lemmy, puis pour ce serveur Lemmy de demander à mon instance d’héberger le contenu pour moi
      Pour atteindre ne serait-ce que le niveau dont parle ATProto, il faudrait au minimum cela. Après, je ne sais pas dans quelle mesure cela correspond à l’ATProto réellement existant, et l’ActivityPub réellement existant n’est pas non plus aussi interopérable que ses partisans le disent

  • Ce blog explique bien l’architecture
    Mais dans la pratique, je pensais que le « problème » était que la société Bluesky exploite l’application principale et héberge la majorité des données utilisateur
    Au niveau du protocole, c’est décentralisé, mais le système réel reste encore très centralisé du point de vue de qui exerce le contrôle
    Je ne dis pas forcément que c’est la faute de Bluesky, mais j’ai l’impression que c’est ainsi que les choses se sont passées jusqu’à présent

    • Le « problème », c’est que les gens cherchent un problème
      Ce problème n’est propre ni à Bluesky ni à ATProto : qu’il s’agisse d’une organisation à but lucratif, d’une organisation à but non lucratif ou d’un groupe de bénévoles, quelqu’un trouvera toujours quelque chose à pointer comme problème
      Je n’ai aucun conflit d’intérêts avec Bluesky, si ce n’est que j’étais un utilisateur précoce et non un investisseur. Dans les limites de mes capacités, je comprends aussi le protocole, l’entreprise et le site web
      Le site et l’application fonctionnent bien. Les gens se concentrent trop sur la recherche de problèmes au lieu de construire des solutions plus vastes et meilleures
      La majorité des gens ne veut pas de solutions P2P provisoires comme Lemmy ou Mastodon. Ils veulent que le contenu soit au même endroit, et pouvoir demander des comptes à l’entité qui en a la charge
      C’est pourquoi je pense que les réseaux sociaux P2P ne se démocratiseront jamais. Il y a eu plus de drames autour de Lemmy et Mastodon qu’autour de Twitter, Reddit et Facebook réunis
      C’est mon humble avis, et mon conjoint ainsi que mes amis semblent penser la même chose
    • Il existe d’autres applications, d’autres hébergements de données utilisateur, de l’hébergement personnel, et d’autres services backend
      C’est décentralisé aussi bien en théorie qu’en pratique
      Certes, Bluesky exploite la plus grande part, donc on peut dire que ce n’est pas décentralisé au niveau de la communauté ou du mindshare, mais cela aussi est en train de changer
    • Est-ce vraiment si bien expliqué ?
      Dire seulement « il n’y a pas d’instances » n’explique pas comment cette architecture contourne des problèmes comme l’authentification, la synchronisation ou la découverte

  • Le choix de Google Reader comme analogie me semble de mauvais augure
    Le RSS a survécu à l’arrêt de Google Reader, mais toutes les communautés qui utilisaient le RSS n’ont pas survécu, et beaucoup d’entre elles ne savent toujours pas ce qu’est le RSS aujourd’hui
    Prétendre que c’est décentralisé tout en pointant sans cesse l’énorme centralisation sociale de l’écosystème décentralisé comme un bon exemple donne une impression presque freudienne
    D’autant plus que nous connaissons déjà la fin de cette histoire
    Google Reader a rassemblé de nombreuses maisons RSS en une seule, y a ajouté de la valeur avec le graphe social et les commentaires, puis s’est effondré au gré des lubies des dirigeants de Google, tuant presque le RSS et détruisant un graphe social impressionnant
    Une telle analogie n’inspire pas une grande confiance envers ATProto

    • Le point clé d’atproto, c’est que le graphe social vit lui aussi du côté « blog/RSS »
      les apps ne font que l’indexer
      Donc, dans cette analogie, n’importe qui peut ressusciter Google Reader ou lui faire concurrence en utilisant le même graphe
      Si ça t’intéresse, http://leaflet.pub fonctionne réellement de cette manière aujourd’hui
    • De mauvais augure, mais exact
      Il suffit d’imaginer que tu ne peux pas utiliser de lecteur RSS sur desktop ou mobile, et que tu ne peux lire le RSS qu’avec Google Reader ou un service clone d’une ampleur comparable
    • Sauf qu’aujourd’hui, il existe beaucoup d’excellents lecteurs RSS
      Quelqu’un a encore parlé de NetNewsWire récemment

  • La différence importante, c’est qu’un blog a son propre site web, et qu’il n’est pas nécessaire de mettre l’intégralité des billets dans le flux RSS
    Bluesky ne fonctionne généralement pas comme ça. Tout ce qui se trouve sur le PDS est répliqué
    Et pour faciliter la réplication, on encourage aussi à mettre les billets de blog complets dans le PDS
    Dans ce cas, toute personne qui veut les indexer peut en prendre une copie, sans que tu puisses contrôler ce qu’elle en fera
    Ce n’est pas une obligation. On peut aussi publier son blog sur son propre site web et ne poster qu’un lien sur Bluesky

    • En quoi est-ce différent d’un scraper qui récupère directement le blog ?
    • Honnêtement, c’est aussi parce qu’atproto est un protocole de données brutes
      Ajouter un front-end HTTP au-dessus d’un compte atproto est la manière recommandée de faire, et beaucoup le font déjà
      C’est aussi comme ça que je procède sur pfrazee.com, et les billets de blog leaflet dont la version de référence est sur atproto sont eux aussi rendus sur mon blog

  • La comparaison avec le RSS induit en erreur
    Les apps Atproto ne sont pas comme des lecteurs RSS qui s’exécutent sur l’ordinateur de l’utilisateur et se connectent directement à la source du contenu
    Les apps Atproto sont des serveurs qui contrôlent, filtrent et mettent en forme le contenu présenté au lecteur
    Les apps Atproto peuvent faire de la censure, du shadow ban, de l’exposition publicitaire, de l’algorithmisation du fil, comme elles l’entendent
    Les utilisateurs sont impuissants, et les créateurs deviennent des victimes qui ne peuvent rien faire d’autre que crier
    Le fait que n’importe qui puisse héberger les données n’importe où n’a absolument aucun sens s’il n’existe aucun moyen de distribuer ces données

    • Ce n’est pas vrai
      D’abord, on peut utiliser une autre AppView qui ne fait pas ce genre de choses
      Les fils peuvent être algorithmisés comme l’utilisateur le souhaite, et s’il existe plusieurs apps, on n’est pas lié à l’algorithme voulu par un producteur central unique