Comment fonctionne Bluesky

• Bluesky est une application de microblogging similaire à Twitter et Mastodon, mais son objectif plus large est de vérifier si des applications sociales décentralisées à grande échelle sont possibles sur AT Protocol (atproto)
• atproto n’est pas une blockchain, un DAO ni un NFT : c’est un protocole fédéré qui utilise la cryptographie et des arbres de Merkle, entre autres, pour répartir le traitement des enregistrements signés par les utilisateurs entre PDS, Relay et App View
• Sa scalabilité vient du fait que le Personal Data Server (PDS) d’un utilisateur n’envoie pas directement les publications à tous ses abonnés ; à la place, un Relay agrège les données du réseau et les expose sous forme de firehose
• La modération est divisée selon le modèle « speech vs reach » : la réplication du contenu et le contrôle de l’exposition sont séparés, et les labelers, les feed generators et les App Views appliquent le filtrage et les blocages
• Les DID stables et les handles basés sur des domaines assurent la portabilité des comptes, mais le service de résolution did:plc exploité par Bluesky reste un sujet de débat autour de la centralisation

---

La relation entre Bluesky et atproto

• Bluesky fonctionne aujourd’hui comme une application de microblogging, mais dans la vision d’ensemble, c’est une première application destinée à démontrer le potentiel de l’Authenticated Transfer Protocol, ou atproto
• Le site de Bluesky explique que « les réseaux sociaux sont trop importants pour être contrôlés par quelques entreprises » et que l’entreprise construit « une base ouverte pour un internet social où chacun peut façonner l’avenir »
• Comme Bluesky est une entreprise, on peut avoir un regard sceptique — « une entreprise construit quelque chose qui ne devrait pas être contrôlé par des entreprises » — mais le cœur de la conception réside dans atproto plutôt que dans l’application
• atproto est un protocole fédéré destiné aux applications sociales décentralisées à grande échelle

Un protocole décentralisé, pas une cryptomonnaie

• atproto peut faire penser aux cryptomonnaies à cause des expressions « réseau décentralisé » et « protocole », mais ce n’est pas une cryptomonnaie
• Ce n’est ni une blockchain, ni un DAO, ni un NFT ; il utilise seulement certaines techniques comme la cryptographie et les arbres de Merkle

Structure de base d’atproto

• atproto adopte une architecture fédérée dans laquelle plusieurs acteurs exploitent différentes parties du système et communiquent entre eux
• Pensé pour une large base d’utilisateurs, il est conçu pour confier davantage de responsabilités aux acteurs capables d’absorber la charge, tout en réduisant la charge de ceux qui ne le peuvent pas
• Au moment de la rédaction, Bluesky avait dépassé les 5 millions d’utilisateurs cette semaine-là, et était jugé beaucoup plus stable que Twitter à ses débuts
• À l’heure actuelle, atproto repose sur du 100 % public et ne propose pas de fonctionnalités comme les messages privés
  • Comme il est difficile de bien implémenter des fonctions privées dans un système fédéré, le choix est de les réaliser correctement plutôt que de publier une fonctionnalité accompagnée de réserves importantes
  • Pour l’instant, il convient de l’utiliser uniquement pour du contenu pouvant être public

Enregistrements, repositories, App View et Relay

• L’utilisateur crée des records signés cryptographiquement, et cette signature prouve l’identité de l’auteur
• Les records suivent un schéma appelé Lexicon
• Les records sont stockés dans un repository, qui fonctionne comme un service exposant HTTP et WebSocket
  • Ce type de service est généralement appelé PDS (Personal Data Server)
  • L’utilisateur peut exploiter son propre PDS ou utiliser un PDS hébergé par quelqu’un d’autre
• Les applications lisent les records stockés sur le réseau et construisent des fonctionnalités par-dessus
  • Comme ces services exposent un point de vue particulier sur l’information, ils sont appelés App Views
  • Créer une application consiste à définir un Lexicon, à lire les records qui l’utilisent, et à ignorer le reste
• Un modèle où les PDS s’enverraient directement des notifications pose de gros problèmes de scalabilité
  • S’il fallait envoyer chaque nouvelle publication directement au repository de chaque abonné, ce serait inefficace et le coût d’exploitation des repositories populaires augmenterait fortement
• Le Relay réduit ce problème en agrégeant les informations du réseau et en les exposant sous forme de firehose
  • En pratique, les App Views consultent le Relay plutôt que les repositories directement
  • Lorsqu’un auteur publie, son repository en informe le Relay, et les abonnés voient le résultat filtré de la sortie du Relay par l’App View
  • Un Relay peut être volumineux et coûteux à exploiter, mais on peut aussi imaginer des Relays plus petits qui ne propagent qu’un sous-ensemble donné d’utilisateurs

Le modèle de modération « speech vs reach »

• Comme atproto est un protocole pour applications sociales, il prend en compte non seulement la manière de connecter les personnes, mais aussi la manière de rompre ces connexions
• Le modèle de modération de Bluesky est divisé en speech vs reach
  • La couche speech a pour rôle de répliquer le contenu sur le réseau indépendamment de son sens
  • La couche reach fournit des outils pour limiter la portée de ce que l’utilisateur ne veut pas voir
• Dire que Bluesky « ne fait pas de modération » ou « privilégie uniquement la liberté d’expression » est inexact
  • Les outils de modération sont intégrés au protocole lui-même et peuvent fonctionner aussi sur le contenu d’applications autres que Bluesky
  • Les utilisateurs ne dépendent pas des choix de modération, ou de l’absence de modération, d’autres personnes : ils peuvent choisir leurs propres modérateurs

Feed generator

• Dans atproto, les flux sont séparés dans un service distinct appelé feed generator
• Un feed generator reçoit le firehose produit par le Relay, filtre et trie le contenu selon les critères voulus, puis affiche une liste
• Les utilisateurs peuvent partager les flux qu’ils ont créés avec d’autres utilisateurs
• Exemples de flux :
  • Quiet Posters : affiche les publications de personnes qui postent peu souvent
  • the ‘Gram : affiche uniquement les publications accompagnées de photos
  • My Bangers : affiche ses propres publications populaires
• L’un des points forts de Bluesky est que les utilisateurs peuvent créer leurs propres flux algorithmiques et les partager facilement
• Les feeds sont une fonctionnalité ajoutée assez récemment à atproto ; ils peuvent donc ne pas encore être complets et évoluer à l’avenir

Labeler et modération au niveau du réseau

• Un Labeler est un service qui appose des labels sur du contenu ou des comptes
• Les utilisateurs peuvent s’abonner à un labeler donné et faire varier leur expérience selon les labels des publications
• Un labeler peut fonctionner comme son opérateur le souhaite
  • Il peut exécuter un algorithme automatique sur les publications
  • Des humains peuvent approuver ou refuser manuellement
  • Il peut servir de liste de blocage ou de filtre NSFW
• La fonctionnalité de label existe, mais au moment de la rédaction, il n’était pas clair si les utilisateurs pouvaient exécuter eux-mêmes un labeler
  • Bluesky exploite son propre labeler
  • Aucune sortie externe n’était encore connue
• En combinant feeds, App Views et labelers, les utilisateurs peuvent choisir leur expérience de modération dans et hors de l’application
  • Ils peuvent ne voir que du contenu SFW dans un flux, et autoriser le contenu NSFW ailleurs
  • Ils peuvent créer et partager des listes de blocage
• Comme les outils de modération fonctionnent au niveau du protocole plutôt qu’au niveau de l’application, le même labeler peut être utilisé par d’autres applications bâties sur atproto
  • Même si un clone d’Instagram est créé sur atproto, il peut utiliser le même labeler de liste de blocage
  • Un utilisateur bloqué à un endroit peut, si on le souhaite, être bloqué partout

Différences avec le modèle d’instances de Mastodon

• Le modèle d’atproto diffère de celui de Mastodon, où un « compte » existe sur une « instance » donnée
• Des questions comme « que se passe-t-il si mon instance est défédérée ? » ne s’appliquent pas telles quelles
• On peut atteindre un objectif similaire en choisissant d’ignorer les publications provenant d’un PDS donné parce qu’on ne les apprécie pas
• Mais ce choix est celui de l’utilisateur, et non une décision prise par le propriétaire du serveur au nom du compte de l’utilisateur

DID, handle et portabilité des comptes

• Le cœur de l’identité dans atproto est le DID (Decentralized Identifier)
  • Un exemple de DID a la forme did:plc:3danwc67lo7obz2fmdg6jxcr
• L’identité réellement visible par les utilisateurs utilise aussi un handle, qui est un nom de domaine
  • Exemple : @steveklabnik.com
  • Les inscrits à Bluesky peuvent recevoir un handle de la forme @username.bsky.social
• Comme le DID est stable, passer d’un handle @steveklabnik.bsky.social à @steveklabnik.com n’interrompt rien pour les abonnés ; seul le handle change dans l’interface
• Pour utiliser un domaine comme handle, on récupère le DID généré par le PDS et on ajoute un record TXT au DNS de ce domaine
• Les utilisateurs qui ne connaissent pas le DNS peuvent aussi enregistrer un domaine et le configurer comme handle sans connaissances techniques grâce au partenariat entre Bluesky et NameCheap
• La portabilité des comptes repose sur les DID et les signatures cryptographiques
  • Le contenu créé par la personne utilisant un DID donné est signé et répliqué sur le réseau
  • Pour « fermer » un compte, il faudrait empêcher de force l’utilisateur d’utiliser les clés qu’il possède ; or, par conception, les autres acteurs du réseau n’ont pas accès à ces clés
  • Même si un PDS tombe, le réseau peut effectuer un backfill du contenu et signaler la migration vers un nouveau PDS

Les enjeux autour de did:web et did:plc

• Bluesky prend en charge deux méthodes de DID
  • did:web : une méthode basée sur les noms de domaine
  • did:plc : une méthode propre implémentée par Bluesky
• Le plc de did:plc signifie « placeholder », et Bluesky prévoit de continuer à le prendre en charge
• La faiblesse de did:plc est qu’il faut résoudre les bonnes informations via un service exploité par Bluesky
  • Un exemple de consultation est disponible sur plc.directory
  • À cause de cette architecture, certains critiquent le fait que Bluesky puisse bannir des utilisateurs plus fortement que ce que la conception du réseau rendrait normalement possible
• Il existe aussi des raisons de ne pas considérer ce problème comme rédhibitoire
  • On peut utiliser did:web si l’on ne veut pas de did:plc
  • Le système est conçu pour permettre une migration si une meilleure solution apparaît
  • À l’avenir, la gouvernance de did:plc pourrait être déplacée vers un modèle de consensus
  • D’autres acteurs pourraient exploiter un service did:plc et l’utiliser

Comment Bluesky s’appuie sur atproto

• Bluesky est une application construite sur le réseau atproto
• Bluesky exploite une App View ainsi que l’application web qui l’utilise
• Elle exploite aussi des PDS pour les utilisateurs qui s’inscrivent via l’application web, ainsi que le Relay par lequel ces PDS communiquent
• Bluesky publie deux types de Lexicons
  • com.atproto.* : des opérations de bas niveau nécessaires à n’importe quelle application du réseau
  • app.bsky.* : des opérations propres à Bluesky
• L’objectif produit de Bluesky est que les utilisateurs puissent s’en servir sans connaître ces détails techniques
  • Comme il n’y a pas d’instances, le parcours de création de compte ne nécessite pas de choisir une instance
  • Si un hébergeur tombe, l’utilisateur peut migrer et ses abonnés n’ont pas besoin de s’en rendre compte

Créer une nouvelle application sur atproto

• Une application atproto commence par la création d’un Lexicon
• Elle exploite ensuite une App View qui traite, parmi les données du réseau, celles qui concernent ce Lexicon
• L’application doit permettre aux utilisateurs d’écrire des données utilisant ce Lexicon dans leur propre PDS

Séparation clé dans la conception

• La séparation des rôles entre atproto et Bluesky est un élément de conception important
• Une « killer app » comme Bluesky donne une raison d’utiliser le réseau
• Bluesky joue aussi un rôle de dogfooding : vérifier qu’il est réellement possible de construire une application sur atproto

[GN⁺]

Avis sur Hacker News

• Ça semble remarquablement bien conçu, et paraît résoudre certains des gros problèmes d’ActivityPub.
  Avant, Bluesky ne m’intéressait pas, mais maintenant j’envisage de créer un compte.

  • Le principal problème de Bluesky et de l’AT Protocol tient moins à leurs mérites techniques qu’à une forte attitude NIH (Not invented here).
    Au lieu d’utiliser les protocoles existants comme user@host et WebFinger, que tout le monde emploie, ils ont choisi « utiliser les domaines comme identité » ; et, faute de s’inspirer de ce qu’ACME gère déjà pour les certificats, quelqu’un a même pu s’approprier le domaine s3.amazon.com sur Bluesky https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
    Ils ont aussi créé un nouveau protocole d’appel distant, XRPC, et utilisent Lexicon, un schéma de données fondé sur la génération de code, dont les avantages ne sont pas clairs, hormis le fait d’être plus récent que protobuf ou jsonld.
    Il est difficile de faire confiance à un « réseau ouvert » qui montre sans cesse qu’il ne veut ni respecter les autres écosystèmes ni dialoguer avec eux ; et on peut se demander combien d’erreurs de conception courantes se sont glissées dans le projet à force de rejeter le savoir partagé.
  • L’AT Protocol paraît meilleur sur le plan technique, mais socialement sa structure semble propice à l’échec.
    Il n’existe pas d’incitation sociale à ce que quelqu’un installe et maintienne des relais et des services de modération séparés de véritables communautés ; il ne reste donc que des incitations financières comme les services payants, l’insertion de publicités, l’extraction de données ou la manipulation de l’information.
    Si la distribution des données et la modération sont centralisées, les coûts d’hébergement comme les coûts humains deviennent l’affaire de grosses entreprises, ce qui revient pratiquement à empêcher quelqu’un d’autre que Bluesky d’exploiter son propre relais ou service de modération.
    Malgré les défauts d’ActivityPub, une approche de type « communauté avec portail d’entrée » donne aux utilisateurs un sentiment d’appartenance à un serveur, et aux opérateurs comme aux modérateurs la fierté de fournir un service aux utilisateurs.
    L’AT Protocol autorise techniquement plusieurs relais et services de modération, mais on peut se demander combien verront réellement le jour.
    À mon avis, c’est une erreur de juger un protocole de réseau social uniquement sous un angle technique et antagoniste. On n’est plus lié à un serveur, mais on se retrouve aussi séparé des communautés denses, et il n’y a plus vraiment d’enjeu.
    Le fait de n’avoir rien à perdre en matière de données, d’identité et de communauté est une arme à double tranchant.

• À ma connaissance, il n’y a actuellement qu’un seul relais.
  Si plusieurs relais apparaissent, chacun aura une vision différente du réseau, et celui qui inclura le plus de publications sera le meilleur.
  Garantir une diversité de relais plutôt qu’un relais unique dominant pourrait être assez difficile, et cela ressemble aux tentatives de systèmes DNS alternatifs pour gagner de la traction. Dans ce cas, si ma publication n’est pas captée par le relais dominant, il semble qu’il n’y ait pas de solution.
  Cela dit, c’est encore très tôt, donc les choses ne tourneront peut-être pas ainsi ; et même s’il existe un relais dominant, GitHub n’est pas si catastrophique, et des alternatives existent.

  • Avant, Bluesky me semblait assez déroutant, mais j’ai récemment compris que c’était surtout à cause de la terminologie.
    Si l’on décrit le système comme [microblog] -> [indexeur] -> [client], c’est plus facile à comprendre.
    En réalité, il y a davantage d’éléments, mais le fonctionnement de base de Bluesky ressemble à peu près à ça ; les noms semblent simplement avoir été choisis de manière inattendue.
    La raison pour laquelle un indexeur est nécessaire est que l’ID utilisateur ne reste pas statique dans le système. DID:PLC commence comme une sous-chaîne d’un hachage, puis, à cause de la « rotation de clés », une étrange réorganisation cryptographique fait que l’ID utilisateur change avec le temps, même à l’insu de l’utilisateur.
    Imaginez un système comme LiveJournal où les handles changent sans cesse et où il faut une autorité pour suivre ces changements. Bien sûr, on ne peut y publier que de courts messages, sans titre ni prise en charge de Markdown.
    Personnellement, j’attends un nouveau DID:PLC qui accepterait une clé publique statique et signerait les messages avec une clé privée. Il y aurait beaucoup moins de choses à suivre, et l’auto-hébergement comme le développement local-first deviendraient bien plus faciles.
  • Si nécessaire, je pense que le client, App View, pourrait utiliser plusieurs relais en parallèle.
    Ce serait une structure de type interface GitHub locale qui récupère des données depuis plusieurs instances GitHub hébergeant des ensembles de dépôts distincts, mais pouvant se chevaucher.
    C’est aussi similaire à un client Usenet qui agrège des groupes de discussion provenant de plusieurs serveurs NNTP.
  • Je m’attends à ce que tous les relais aient l’intégralité des données, à l’exception des différences de jugement concernant les contenus illégaux.
    Je me demande pourquoi vous pensez que chaque relais aurait une vision différente du réseau.

• Ce que je me demande, c’est comment BlueSky peut s’engager de façon fiable à n’utiliser que les parties ouvertes du protocole.
  BlueSky semble en fait assez centralisé, donc je ne vois pas de raison technique imposant que le client propriétaire soit forcément un client ATProto.
  À court ou moyen terme, faire autrement serait une trahison majeure de la confiance des utilisateurs, mais la structure de facto distribuée d’ActivityPub me paraît ici être une garantie plus solide.

  • Je ne comprends pas ce que vous entendez par client BlueSky propriétaire.
    Si vous voulez dire que le relais propriétaire et le PDS pourraient communiquer via un autre protocole, je ne comprends pas bien ce qui vous inquiète.
    Deux clients ActivityPub peuvent aussi communiquer entre eux via un protocole qui n’est pas ActivityPub.
  • On peut lui faire confiance parce que tout le code est open source.
    C’est effectivement ce qu’ils font, et s’ils commençaient à changer de direction, les gens s’en apercevraient très vite.

• C’est bien d’être allé jusqu’à distinguer « expression » et « portée », mais à long terme, pour des raisons de simplicité, Mastodon me semble être le choix le plus intelligent
  À court terme, la sélection des fils sur Mastodon est clairement plus difficile, donc cela peut être moins amusant ou moins utile
  La question centrale est : si un acteur malveillant hypothétique, probablement riche ou puissant, voulait faire bouger les lignes ici, comment pourrait-il s’y prendre ?
  L’article expédie cette partie beaucoup trop vite, avec des formules du type « je ne sais pas vraiment comment fonctionnent les fils », ce qui est très suspect. On dirait qu’il sait très bien comment les fils vont fonctionner, qu’il sait aussi que c’est là que se trouvent le pouvoir et l’argent, et qu’il essaie de mettre la main dessus

  • Résumer cela par « je ne sais pas vraiment comment fonctionnent les fils » ne me paraît pas approprié
    L’auteur dit ceci : « Les fils sont une fonctionnalité récemment ajoutée à atproto ; ils existent, mais ne sont peut-être pas encore finalisés et pourraient évoluer à l’avenir. À suivre. De mon point de vue, ils fonctionnent bien, mais je ne suis pas les détails techniques de bas niveau. »
    Le paragraphe juste au-dessus donne aussi ce contexte : « L’une des killer features de BlueSky par rapport aux autres outils de microblogging, c’est le choix total laissé à l’utilisateur. Si je veux créer mon propre algorithme de fil, je peux le faire, et le partager facilement avec d’autres. »
  • Je ne vois pas d’où vient l’idée qu’il ne saurait pas comment fonctionnent les fils
    Les fils sont open source, ils existent aujourd’hui, et on peut les exécuter soi-même
    Ce que signifie « faire bouger les lignes », et quelles lignes exactement, n’est pas clair non plus. Il y a beaucoup de pièces en mouvement ici

• L’idée selon laquelle, si l’utilisateur choisit un fournisseur de modération indépendant de son fournisseur d’hébergement, il a moins à se soucier du choix de l’instance, paraît intéressante
  Cela dit, les instances devront probablement toujours modérer pour éviter d’héberger du contenu illégal localement
  Au final, cela risque de devenir assez difficile pour les personnes qui exploitent des instances, et de créer pas mal de confusion. Je me trompe peut-être

  • La personne qui héberge du contenu doit gérer les conséquences juridiques du contenu qu’elle héberge, et c’est inévitable
    Mais c’est pareil quel que soit le protocole utilisé
  • Tu ne te trompes pas. À mon avis, la décentralisation de Bluesky est proche d’une fausse décentralisation
    Un PDS peut tourner sur une machine Ubuntu correcte, mais même cet article reconnaît que les relais sont coûteux et constituent un énorme point de contrôle centralisé
    Quel est le plan de Bluesky contre le spam ? Ce sera probablement de bloquer au niveau des relais
    Le serveur DID est aussi un autre point de contrôle centralisé
    Cela dit, on pourra toujours faire tourner des PDS comme on veut

• Petite anecdote amusante sur Bluesky, en lien avec un article récent : c’est aussi, d’une certaine manière, tiré d’un nom de personne
  Le nom de la CEO signifie littéralement blue sky en chinois

  • C’est amusant, car Twitter avait déjà nommé le projet bluesky avant que j’y participe
    C’est une coïncidence. En revanche, mon deuxième prénom signifie bluesky en chinois

• Cette courte BD est bien aussi : https://bsky.social/about/welcome-to-bluesky-comic

• Si Bluesky abandonne la prise en charge de did:plc, toutes les identités PLC existantes seront-elles cassées ?
  Je me pose la question, car PLC repose sur des pings envoyés à ce service

  • https://plc.directory peut être répliqué, et si cela arrivait, un nouveau miroir pourrait devenir le serveur faisant autorité

• Je suis sceptique vis-à-vis des labelliseurs tiers
  Comment empêcher les abus ?

  • L’utilisateur choisit à quel labelliseur tiers il s’abonne
    Si un service de labellisation commence à abuser de sa position, l’utilisateur peut simplement s’en désabonner
    Une explication détaillée de la façon dont Bluesky veut intégrer les labelliseurs dans l’écosystème se trouve ici : https://github.com/bluesky-social/proposals/tree/main/0002-l...
  • La réponse dépend du type d’abus dont on parle
    Je peux donner mon avis, mais la question est trop large et je ne sais pas par où commencer
  • Nous publierons bientôt beaucoup plus d’informations sur la modération, mais les bases des labelliseurs sont les suivantes
    N’importe qui dans le réseau peut labelliser n’importe quoi, y compris d’autres labelliseurs
    Les apps peuvent exposer les labelliseurs auxquels l’utilisateur peut s’abonner, comme les fils personnalisés de Bluesky aujourd’hui
    Les apps peuvent aussi sélectionner la manière dont les labelliseurs sont exposés et classés, comme elles exposent et classent aujourd’hui les fils personnalisés selon leur popularité, exprimée par les likes et les enregistrements

• L’approche selon laquelle « les outils de modération relèvent de la couche de portée. Ils récupèrent toutes les prises de parole, mais fournissent un moyen de limiter la portée de ce que je ne veux pas voir » finit par ressembler à une modération du type « si tu ne veux pas voir, ferme les yeux »
  Je sais que c’est une philosophie appréciée dans la Silicon Valley, mais je la considère comme fondamentalement défectueuse
  Il existe des situations légitimes où il faut empêcher d’autres personnes non concernées de parler d’un sujet donné ou d’obtenir certains contenus
  Les exemples typiques sont le cyberharcèlement, le doxxing et le revenge porn. Deux personnes ou plus discutent de la manière de nuire à un tiers, ou publient des informations privées, humiliantes ou fausses
  Retirer ces informations du fil de la victime est totalement inutile, et il est probable qu’elles n’y apparaissent même pas au départ. Le préjudice vient du fait que d’autres personnes voient ce contenu ou participent à la discussion, mais ce préjudice est bien réel
  Dans les systèmes de modération traditionnels, les modérateurs peuvent mettre fin à ce comportement en supprimant la publication pour tout le monde ou en bloquant les auteurs. Dans un système qui « se contente de masquer le contenu », c’est impossible
  Les listes de blocage partagées ou les « labels » ne fonctionnent pas non plus. Les consommateurs du contenu n’ont aucune motivation à les bloquer et, au contraire, peuvent avoir envie de voir du revenge porn
  C’est la victime qui veut bloquer, mais elle n’a pas le pouvoir d’obliger tout le monde à utiliser une liste de blocage précise. Car le principe même de ce système est que personne ne peut imposer une liste de blocage aux autres

  • Il y aura davantage de choses à venir sur ce domaine. Dans cet article, je me suis concentré sur les cas normaux et n’ai pas abordé les mauvais cas
    L’équipe a examiné ces problèmes et « consulté aussi des experts », mais comme c’est encore un travail en cours, je ne me sens pas légitime pour en parler
    Le point selon lequel « les labels ne fonctionnent pas parce que les gens veulent voir cela plutôt que l’empêcher » fait partie de l’espace de problèmes que l’équipe a explicitement reconnu
    Référence supplémentaire ici : https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei