Le protocole AT de Bluesky est décentralisé : plusieurs réseaux sociaux, chacun avec ses propres systèmes de conservation et de modération, interagissent avec d'autres réseaux sociaux via un standard ouvert.

 

Bluesky souhaite corriger certains défauts de twitter / X sur la modération, en permettant à l'utilisateur plus de contrôle sur le contenu qui lui est affiché ou non, en fonction de ses préférences.

 

Bluesky est actuellement sur invitation, si vous êtes intéressé, il y a unsujet dédié : Sujet pour ceux qui cherchent un code Bluesky

La création du compte depuis l'application Android :

 

 

---

Attention : Bluesky fonctionne bien et à une communauté technophile francophone importante (j'ai été surpris), mais des communautés sont très peu présentes aujourd'hui sur Bluesky.

Le réseau BLuesky n'est pas terminé. Il manque les messages privés. Les développeurs travaillent dessus, ce seront des messages chiffrés de bout en bout et non en clair sur les serveurs comme sur X / Twitter.

L'interface est également uniquement en anglais pour le moment.

Le vocabulaire change un peu avec Bluesky :
- skeets ou posts : les tweets (terme qui doit changer pour X)
- skytos : les utilisateurs
- skyline : la timeline principale

---

Le Protocole AT entraine plus de transparence

Tout est public sur Bluesky à part l'adresse e-mail, la date de naissance, les IP utilisées, les mutes, qui vous a envoyé votre invitation et à qui vous avez donné vos invitations.

Attention : N’importe qui peut télécharger une archive de votre compte et donc avoir accès à tous vos posts et interaction depuis le début, en une seule requête (il faut des outils pour parcourir l’archive, mais c'est possible). Dans les données publiques, il y a chacune de vos interactions : vos messages, mais aussi les likes, unlike, follow, unfollow,... avec la date et l’heure de l’action.
Bluesky n'a pas encore de messages privés, c'est en cours de développement, ceux-ci seront chiffrés de bout en bout, donc hautement sécurisés comme avec l'application Signal ou Telegram.

Bien dissocier les blocages et les mute :

- Un blocage est symétrique : le comportement est le même quel que soit le compte qui a initié un blocage en premier.
- Un mute va simplement "filtrer" les auteurs que tu n'as pas envie de lire.
Il est possible de créer des listes dans lesquelles positionner ces profils à muter et ensuite il est possibl de partager sa mute liste. Les mute lists permettent de créer une collaboration entre personnes partageant les même craintes ou les mêmes types de harceleur pour leur permettre de se partager des listes de personnes dont on n'a pas envie par défaut de lire les commentaires.


Source : mrhackio - le 16 mai 2023

---

Contrairement à d'autres plateformes centralisées, les blocages sur Bluesky sont des données publiques et dénombrables, car tous les serveurs du réseau doivent savoir qu'ils existent afin de respecter la demande de l'utilisateur.

Sur de nombreuses plateformes de médias sociaux, les blocages entre deux comptes présentent généralement les caractéristiques suivantes :
- Symétrique : le comportement est le même quel que soit le compte qui a initié un blocage en premier
- Muet mutuel : aucun des comptes ne peut lire le contenu (public ou privé) de l'autre compte lorsqu'il est connecté.
- Blocage des interactions mutuelles : les interactions directes entre les deux comptes ne sont pas autorisées. Cela inclut les mentions directes entraînant une notification, les réponses aux publications, les messages directs (DM) et les suivis (qui entraînent normalement des notifications).

Lorsque le contenu est public, comme c'est le cas sur Bluesky, les blogs ou les sites Web, les personnes bloquées peuvent toujours accéder facilement au contenu en se déconnectant simplement ou en ouvrant un onglet de navigateur incognito. Les publications peuvent toujours être capturées et partagées sur le réseau ou hors réseau. Le harcèlement peut continuer à se produire même sans mentions ou réponses directes (« sous-tweets », publication de captures d’écran, etc.).

Sur la plupart des services existants, la personne bloquée peut détecter qu'elle a été bloquée, même si cela n'est pas immédiatement évident. Par exemple, s'ils parviennent à accéder au profil du bloqueur, ils peuvent voir un écran indiquant qu'ils ont été bloqués, ou l'absence du profil est une indication suffisante qu'ils ont été bloqués. La plupart des applications sociales fournissent à chaque utilisateur une liste des comptes qu'il a bloqués.

Vous pouvez en savoir plus sur les comportements de blocage sur d’autres plateformes :
- Twitter: https://help.twitter.com/en/using-twitter/blocking-and-unblocking-accounts
- Mastodon: https://docs.joinmastodon.org/user/moderating/#block
- Instagram: https://help.instagram.com/447613741984126

Comment les blocage sont-ils actuellement implémentés dans Bluesky ?

Les blocages empêchent l’interaction. Les comptes bloqués ne pourront pas vous aimer, vous répondre, vous mentionner ou vous suivre, et s'ils accèdent directement à votre profil, ils verront qu'ils ont été bloqués. Comme les autres réseaux sociaux publics, s’ils se déconnectent de leur compte ou utilisent un autre compte, ils pourront consulter votre contenu. (Cela est également standard sur les réseaux sociaux centralisés.)

Actuellement, sur Bluesky, vous pouvez afficher une liste de vos comptes bloqués, et bien que la liste des personnes qui vous ont bloqué n'apparaisse pas dans l'application, les développeurs familiers avec l'API pourraient explorer le réseau pour analyser ces informations. Cette section abordera les contraintes techniques qui rendent les blocages publics.

Les serveurs et les clients indexeront les enregistrements de blocage et empêcheront les actions qui auraient violé les comportements prévus : les publications n'apparaîtront pas dans les flux et les fils de réponse ; les récupérations de profil seront vides ou annotées avec un état de blocage ; la création de messages de réponse, de messages de citation, d'intégrations et de mentions est bloquée ; toutes les notifications impliquant l'autre compte sont également supprimées.

L'un des principes fondamentaux du protocole AT, sur lequel Bluesky est construit, est que les titulaires de compte ont un contrôle total sur leurs propres données. Cela signifie que même si les clients et serveurs conformes au protocole empêchent les comptes bloqués de créer des réponses ou d'autres enregistrements non autorisés dans le référentiel de données de chaque utilisateur, il est techniquement possible de contourner ces restrictions si un client refuse de se conformer au protocole. Le fait d'être bloqué n'entraîne pas non plus de modification du référentiel du bloqué, et toutes les anciennes réponses ou mentions restent en place, intactes. Par exemple, dans l'application destinée aux utilisateurs, si quelqu'un répond à votre message et que vous le bloquez, ses réponses vous seront désormais masquées. Si vous décidez ultérieurement de les débloquer, leurs réponses à ce message apparaîtront à nouveau, car les réponses elles-mêmes n'ont pas été supprimées.

Bien que les blocages ne suppriment pas le contenu des référentiels des autres utilisateurs, les données ne sont pas affichées car les blocages sont principalement appliqués par d'autres nœuds et services : serveurs de données personnelles (PDS), vues d'application et clients. Un effet secondaire qui ressort de cette architecture est que les relations de suivi ne sont pas modifiées en raison d'un blocage, et les « blocs logiciels » (blocage/déblocage rapide) ne fonctionnent pas comme un mécanisme pour supprimer un suiveur. Bien qu'une relation de suivi puisse toujours exister dans le graphique, le blocage empêche toute visualisation ou diffusion réelle du contenu. Dans le cadre de travaux futurs, nous pouvons également garantir que les détails tels que le nombre de « j’aime » et les comptes « abonnés » sont mis à jour lorsque le statut du blocage change.

Comment les blocages fonctionneront-ils avec la fédération ouverte ?

Bluesky est un réseau social public construit sur un protocole pour prendre en charge les conversations publiques. À l'instar des blogs et des sites Web, vous n'avez pas besoin d'un compte Bluesky pour voir le contenu publié sur l'application. Afin de prendre en charge la fédération ouverte dans laquelle de nombreux serveurs, clients et App Views collaborent pour présenter le contenu aux utilisateurs, le référentiel de données de chaque compte, qui contient des informations telles que les suivis et les blocages, doit être public. Tous les serveurs du réseau doivent être capables de lire les données. Les serveurs doivent savoir quels comptes vous avez bloqués afin de pouvoir faire respecter cette relation.

Une fois la fédération lancée, il y aura de nombreux serveurs de données personnelles (PDS), clients et vues d'applications. On s'attend à ce que pratiquement tous les comptes utilisent des clients et des serveurs qui respectent le comportement de blocage.

C’est ce besoin de coordination entre plusieurs parties qui nécessite que les blocages soient publics. Le comportement « Muet » peut être entièrement implémenté dans une application client car il n'a d'impact que sur la vue du titulaire du compte local. Les blocages nécessitent une coordination et une mise en œuvre par d'autres parties, car les points de vue et les actions de plusieurs parties (éventuellement antagonistes) sont impliqués.

En théorie, un acteur malveillant pourrait créer son propre client ou interface malveillant qui ignorerait certains comportements bloquants, puisque le contenu est publié sur un réseau public. Mais il ne sera pas possible d'afficher du contenu ou des notifications à la personne qui a créé le blocage, car ce comportement est contrôlé par son propre PDS et son propre client. Il est techniquement possible pour un client malveillant de créer des réponses et des mentions, mais elles seraient invisibles ou du moins auraient un faible impact sur le compte du destinataire pour les mêmes raisons. Les logiciels conformes au protocole de l'écosystème garderont ce contenu invisible pour les autres comptes du réseau. Si une fraction importante des comptes choisissait d’utiliser une infrastructure malveillante non conforme, nous considérerions cela comme un échec de l’ensemble de l’écosystème.

N'oubliez pas que des contournements intelligents des comportements de blocage sont déjà possibles sur la plupart des réseaux (centralisés ou non), et ce sont les frictions supplémentaires qui comptent.

Source : Pourquoi les blocages sur Bluesky sont-ils publics ? sur https://atproto.com traduit par vivien

J'y suis depuis le 28 juillet. C'est le vide quand même. A part des photos de chats et des blagues anti-twitter.

Le problème de ces "réseaux sociaux" c'est la fragmentation si y'a pas un dominant unique comme Facebook l'est devenu (et Twitter pour sa spécialité).

En plus y'a l'effet de mode et l'effet de 'clan'/'posture' des "early adopters" qui joue en ce moment mais c'est toujours du court terme ,ce type de public se lasse vite et passe a autre chose rapidement. Ils sont rarement les vrais utilisateurs qui ont le vrai besoin et font réussir un produit.

Des projets décentralisés existent depuis longtemps notamment https://diasporafoundation.org/ par exemple ou Mastodon mais ne décollent pas car il y a un problème de scaling,  de financement et de neutralité (avec Twitter ou Facebook on sait qui est derriere pour les aspects légaux, censures, etc, en décentralisé total c'est plus problématique).

L'email est décentralisé car il a été inventé avant l'arrivé du 'privé' dans l'Internet (qu'on situe au début des années 1990s). Depuis il est difficile d'avoir un standard de communication qui s'impose.
Pour preuve la suite logique de l'email aurait été la messagerie instantané et la visio: y'a pas de standard  (ou ceux comme XMPP qui existent ne sont pas adoptés a grande échelle): de Microsoft Teams je ne peux call quelqu'un sur Whatapps ou Google Meet ou envoyer un message instantané. Alors que machin@chose.com peut joindre n'importe quel autre email dans le monde quelque soit l'implémentation derriere. Je peux même auto-hébergé mon propre serveur.

La raison c'est principalement l'économie privée de marché. Personne ne veut être interopérable et partagé son gâteau sauf sous la contrainte. Y'a peu de gain a l'être. SMTP existait et surtout était largement utilisé avant l'arrivé des boites privées dans Internet et c'est ce qui a permis de démocratiser Internet. Imaginez si les abonnés Free ne pouvaient qu'envoyer des email qu'aux autres abonnés Free (aka facon AOL)  ?

Je ne vois pas ce qui changerait avec ce protocole AT. Au pire Twitter ou Facebook ou un autre GAFAM va l'utiliser dans son produit et pratiquer la méthode EEE. Pourquoi ce protocole réussirait pour concurrencer Twitter la ou XMPP n'a jamais réussi pour la messagerie instantané ?

Sur le papier c'est bien , mais pour "scaler" a la planète entière ca ne marchera pas tant que des intérêts privés seront derriere. Par nature la compétition capitaliste c'est de tuer l'autre pas d'apporter de la valeur ajouté a l'autre.

Au départ ca semble marcher parce que geeks peuvent mettre leur propre serveurs et compétences pour démarrer le truc mais qui prendra le relai pour héberger mr tout le monde ?

Idéalement ca devrait être les FAI comme ils l'ont fait avec l'email mais y'a belle lurette qu'ils ne font plus rien les FAI. On se demande pourquoi d'ailleurs...Ils se plaignent souvent de ne rien avoir du gâteau des GAFAMs mais ils n'innovent en rien.

Meme si j'espère une décentralisation forte un jour, ca reste utopiste de nos jours. A moins d'une intervention des régulateurs.

Ou alors une fondation comme c'est le cas pour Wikipédia. C'est le pari de Mastodon. Donc quitte a choisir une alternative a Twitter (si on a une bonne raison autre que de suivre la mode ou une idéologie) le mieux pour le moment ca reste Mastodon plutôt que Bluesky (qui sur le papier est une 'no benefit' mais ils peuvent très bien faire ce qu'OpenAI  a fait...).

in before l'arrivée sur ce sujet de vous savez qui.