Cet article est traduit et remâché. Source Originale

Plus d'informations sont disponibles sur le site de documentation de Bluesky ainsi que sur celui de ATproto

ATproto est conçu pour avoir les qualités suivantes (et bien d'autres) :

• Identité et données fédérées basées sur la norme DID du W3C
• Propriété des données (via des signatures cryptographiques)
• Object Capabilities (oCaps)
• Modération « descendante » fédérée
• Namespaces pour les données des utilisateurs

Pour le cas du micro-blogging, il y a quelques composants clés :

• Personal Data Servers (PDS)
• Relais ("Big Graph Server")
• Frontend/API/Caching

Les PDS stockent les données d'utilisateurs multiples à la fois et peuvent définir des paramètres par défaut comme les services de modération, les relais en cours d'utilisation et d'autres paramètres en fonction de leurs besoins.

La configuration par défaut (selon le GitHub de BlueSky) utilise la plateforme de modération moderation.bsky.app comme service de modération etbsky.appcomme frontend/appview par défaut. Ces deux éléments sont configurables.

N'importe quel PDS peut demander à être indexé/crawlé par un relais donné. Le relais par défaut est bsky.network - le relais « officiel » de BlueSky.

Un relais agrège les données de tous les PDS qui en font la demande dans un flux continu, un « firehose », qui peut être suivi via WebSocket.

Dans le cas de BlueSky, les clients recherchent des données stockées dans les PDS sous le namespace app.bsky.*, mais il en existe aussi d'autres pour des logiciels comme linkat.blue (blue.linkat.*), whtwnd.com (com.whtwnd.*) ou d'autres logiciels basés sur ATproto.

Ainsi, les données utilisateur, comme les publications ou les profils, ne sont pas fédérées directement entre les serveurs de données. Ces données sont plutôt chargées directement depuis le serveur distant à la demande, soit directement, soit indirectement (via un relais ou un flux).

Pour résumer, le modèle de fédération est le suivant :

• Les données sont stockées dans un PDS - elles peuvent être utilisées directement sur place.
• Le relais agrège les données de tout PDS qui souhaite participer.
• Les clients et/ou AppViews peuvent utiliser les données du relais ou du PDS.
• Les données ne sont pas partagées/dupliquées/fédérées directement entre les PDS.

Donc on peut dire que :

• Les données ne sont pas liées à un logiciel particulier
• C'est un format de données standard pouvant être utilisé par plusieurs AppViews via des namespaces.
• Les namespaces ne se chevauchent pas (le contenu long-form/blog n'est pas fédéré avec le micro-blogging, et vice versa).

Mais que le modèle de fédération d'ATproto n'est PAS :

• Instance à instance
• Centralisé (n'importe qui peut héberger un PDS, comme n'importe qui peut héberger un serveur web)
• Contrôlé algorithmiquement (un PDS a juste des données, un relais envoie ces données dans l'ordre chronologique. Le PDS n'a pas d'algorithme).

Le modèle de modération

Avec ATproto, une approche « descendante » de la modération a été choisie. Traditionnellement, cela signifie qu'il y a une autorité centrale, mais ici, le terme fait plutôt référence à la confiance accordée à n'importe quelle entité pour modérer et/ou étiqueter le contenu.

Dans le contexte de BlueSky, cela vous permet de bloquer des milliers d'utilisateurs à la fois avec des listes de modération partageables, ou d'appliquer des étiquettes aux utilisateurs et au contenu à l'aide d'étiqueteurs et de services de modération.

Comme mentionné précédemment, lors de la création d'un PDS - du moins pour le cas d'utilisation de BlueSky - les utilisateurs inscrits utiliseront par défaut moderation.bsky.app / did:plc:ar7c4by46qjdydhdevvrndac.

Selon l'implémentation du client/appview, vous pouvez également être abonné aux services de modération moderation-de.bsky.app ou moderation-br.bsky.app pour les utilisateurs allemands et brésiliens respectivement. Ce processus semble s'effectuer au moment de l'inscription ou de la première connexion en Allemagne/Brézil, et cela ne se fait pas directement au niveau du PDS.

Les administrateurs de PDS peuvent également définir un autre service de modération/étiqueteur par défaut s'ils le souhaitent, par exemple lorsqu'ils veulent modérer de manière indépendante ou gérer un étiqueteur communautaire.

De plus, les clients/appviews peuvent être programmés pour toujours utiliser certains étiqueteurs et services de modération.

En résumé :

• La modération se fait selon une approche « descendante »
• Les utilisateurs peuvent s'abonner à des listes de modération et des étiqueteurs de contenu
• Les administrateurs de PDS ont le contrôle sur les listes de modération et étiqueteurs par défaut auxquels ils sont abonnés (cela peut être, dans une certaine mesure, imposé)
• Dans certains cas, selon votre région, certains clients peuvent s'abonner à des listes de modération régionales lors de l'inscription/connexion initiale
• Les relais et AppViews sont « neutres » tandis que les étiqueteurs et autres services de modération sont « opinionnés »

Flux et algorithmes

Les Flux algorithmiques, un « filtre » opinionné pour le contenu provenant du « firehose », est l'une des fonctionnalités de BlueSky.

Ils utilisent le terme "Fils d'actualités" dans l'interface utilisateur, et cela permet aux utilisateurs de personnaliser le contenu en fonction des critères qu'ils définissent.

Ce qui rend cela possible, c'est l'ajout d'une couche optionnelle entre le relais et le client/appview, qui peut délivrer n'importe quel nombre et ordre de publications qu'ils jugent approprié.

En dehors du format des données qu'ils sont censés renvoyer, il n'y a aucune restriction sur le fonctionnement d'un flux. Il peut être aussi simple que de filtrer toutes les publications avec un certain hashtag, ou d'exécuter des algorithmes de vision par ordinateur sur les images et les textes alternatifs pour identifier des images de chats. Important !

Avec un flux, la structure serait la suivante :

1. AppView/Client
2. Feed (Flux)
3. Relay (Relais)
4. PDS

Il est important de garder en tête que les flux sont entièrement optionnels et qu'ils n'affectent pas le flux « Following », qui est généré en fonction de votre PDS, Relay et AppView/Client.

L'état actuel de BlueSky

Actuellement, BlueSky est plutôt centralisé.

Ce n'est pas parce que les ingénieurs d'ATproto ou les développeurs de BlueSky sont malveillants, mais parce que leur approche du design du protocole consistait d'abord à créer une plateforme de médias sociaux traditionnelle et évolutive, puis à voir comment elle pouvait être découpée en composants individuels et définir une structure de données cohérente.

Cela, combiné à une fédération tardive, a conduit la plupart des utilisateurs à être sur des PDS détenus par BlueSky PBC.

Cependant, avec l'augmentation récente du nombre de PDS non bsky-PBC apparaissant sur le réseau , j'espère qu'à l'avenir, plus de gens hébergeront leurs propres données ou partageront leurs PDS personnels avec des amis. Ce n'est pas idéal pour la fédération, mais la situation est en train de s'améliorer.

Foire aux questions

Les relais apportent un point de centralisation. C'est le mal incarné !

C'est effectivement un problème. Il pourrait être possible qu'une organisation à but non lucratif, l'ICANN ou d'autres entités pourraient héberger un relais.

Il doit y avoir une incitation à héberger un relais, ce qui peut coûter assez cher pour les individus (~150 $ par mois en juillet 2024, probablement plus maintenant) ou ils doivent être distribués/décentralisés d'une manière ou d'une autre.

Il faut noter que d'autres parties de la « stack complète », comme les étiqueteurs ou (d'autres) AppViews, apportent plus de valeur dans l'ensemble, mais dépendent encore des relais. Une incitation pour héberger un relais pourrait donc être de payer pour recevoir un SLA (Accord de niveau de service) d'un relais existant, ce qui subventionnerait l'utilisation publique du relais. Un peu comme Proton (mail) qui subventionne ses clients gratuits avec les abonnements de ses clients payants.

Ils sont financés par des investisseurs en capital-risque, ils finiront par trahir tout le monde !

Je comprends d'où vient cette idée, mais ATproto a déjà suffisamment mûri pour être utilisé sans que BlueSky PBC existe.

Le projet pourrait mourir demain, et avec peu d'effort, les ~650 PDS non bsky et un relais (qui aurait à gérer beaucoup moins de données à ce moment-là) pourraient être gérés par des bénévoles et des personnes intéressées.

Une fédération plus serrée pourrait également être obtenue de diverses manières, mais répliquer la configuration de BlueSky ne devrait pas être difficile.