From a preliminary ~12h sample of #bluesky / #atprotocol , a small number of accounts receive most interactions. This is an obvious byproduct of the way the default algorithmic feed prioritizes posts.
5% of accounts received 72% of likes, 1% of accounts received 41%
The top 5% of accounts make 48% of posts
37% of accounts receive no interaction
The median account received 1 like.
Just a quick, incomplete look, but ya looks like an engagement farm
#Bluesky 's latest blogpost [1] reveals that the #ATProtocol is a classic bait and switch game, facilitated by the small-world/big-world distinction. [2]
The bait is telling creators that their content is safe (from petty moderators/server shutdown) and that they are not locked into a platform because the AT protocol is federated, so they can self host with a handle under their control. The switch is that the (federated aspect of the) AT Protocol is irrelevant in the big-world.
He wrote a great article back in January entitled “Moderate people, not code” that is good background
> “Whether ActivityPub or ATProto or webmention, the underlying technical protocol a community uses to interact online is a poor way to judge who they are and whether you might like them.”
The #IndieWeb service #Bridgy is ready to handle bridge AT protocol and ActivityPub protocol posts and replies once federation is enabled in production (already working in sandbox test server).
The format will be:
To follow a #Fediverse account from BlueSky / AT protocol: <username>.<server_domain>.ap.brid.gy
To follow a BlueSky / AT protocol user: <username>@atproto.brid.gy
Example: @atp.youronly.one@atproto.brid.gy
This allows users from each side to see new posts and to reply to these threads.
What is more interesting is that, if you have IndieWeb support on your website or blog, you will see comments from BlueSky / AT protocol appear as a comment, thanks to #Webmention. It is already possible to do this with Fediverse / ActivityPub. ^_~
The real sticking point in implementing portable accounts/ nomadic identity in the ActivityPub branch of the #fediverse - like what Zot and AT Protocol offer - is its implications for how moderation works.
"The hard part however, is the social one: we collectively need to agree that the identity resolution layer is infrastructure and not somewhere moderation actions should take place."
Manton from Micro.blog intends to enable the service as an ATProtocol PDS:
The long-term plan for Micro.blog is to fully support AT’s PDS — Personal Data Servers. Any blog hosted on Micro.blog would plug into Bluesky seamlessly, with data portable to other AT Protocol hosting providers.
My read on #bluesky is that they are effectively sucking the air out of the decentralization balloon, whether they intend to or not. On the tech side, the #ATprotocol will prevent much decentralization from ever happening and divert the focus that was on #ActivityPub development. On the culture side, they deter a critical mass from developing here, which we need to overwhelm the influence of our most annoying users and lure in the people most people want to follow and interact with. #fediverse
BlueSkys official #ATProtocol account just highlighted a community developer project to bridge it with #ActivityPub
#BlueSky early on decided not to go with the open #W3C standard in favor of implementating features like account migration. Planning to start federating next year, they've made some decisions I'm skeptical about.
> Le 12 septembre, le dérivé de Twitter construit sur un protocole décentralisé a annoncé avoir atteint le million d’utilisateurs. Afin de voir exactement ce que propose Bluesky, nous l’avons testé via son application mobile.
Sur les commentaires qui sont rigolos. Clochers, guerre, toussa toussa.
@mmasnick this is super helpful. But one question I still can't quite grasp.
In the #ATprotocol server space, do the server admins themselves have the ability to ban users or remove content regardless of and prior to the users choosing their own moderation filters?
I also can't tell if the BlueSky/ATprotocol space allows for admins also have something analogous to #Fediblocking users and content from other ATprotocol servers.
Seit letzter Woche braucht man keinen Invite-Code mehr um sich bei Bluesky anzumelden, die wesentlich spannendere Info steht aber, wie beiläufig erwähnt, im letzten Abschnitt:
This month, we’ll be rolling out an experimental early version of “federation,” or the feature that makes the network so open and customizable. On Bluesky, you’ll have the freedom to choose (and the right to leave) instead of being held to the whims of private companies or black box algorithms. And wherever you go, your friends and relationships can go with you.
Ich bin gespannt wie Bluesky federation umsetzen wird. Auf mich wirkt das ATProtocol immer noch viel zu kompliziert und „overengineered“, aber vielleicht ist das ja auch gerade der Vorteil gegenüber ActivityPub.
Ich hatte vorgestern einen kleinen Plausch mit @deadsuperhero für den Decentered Podcast, in wir unter anderem auch über die Schwierigkeiten bei der Implementierung von ActivityPub sprachen. Da WordPress in vielen verschiedenen Umgebungen laufen muss und sich die Konfiguration des Webservers, die PHP Version, das Caching, die Interferenz mit anderen Plugins und andere spezial Fälle nicht seht gut abschätzen lassen, ist es sehr schwer komplexere Funktionalitäten umzusetzen.
Ein Beispiel: Im Gegensatz zu OStatus, wo die Distribution von neuen Inhalten über PubSubHubbub (jetzt WebSub) geregelt wurde, ist bei ActivityPub der Service selbst dafür verantwortlich. Ein direktes Verteilen der Inhalte, direkt nach dem Veröffentlichen, würde bei großen Follower zahlen, den Prozess unnötig in die Länge ziehen, oder könnte sogar zu einem Fehler oder einem kompletten Abbruch führen. Um dem (so gut es geht) entgegen zu wirken, wird der Prozess asynchron über WP_Cron abgearbeitet. Leider ist aber auch das keineGarantie für einen fehlerfreien Ablauf (Siehe Ende des vorherigen Absatzes).
Lange Rede kurzer Sinn: Abhängig davon wie simpel ein Personal Data Server kurz PDS aufgebaut ist, könnte Bluesky vielleicht doch interessanter sein als ich ursprünglich angenommen habe.
As I’m observing conversations and efforts to build tomorrow’s technology related to #activitypub and #atprotocol, I have concerns regarding how many non-white folx from marginalized and vulnerable communities will show up and for those who do, will they be welcomed?
Because tech development has a long history of the most privileged making decisions that maintain the status quo while inflicting harm on “others”
A great breakdown of Bridgy Fed and the whole situation. I personally am excited for the project, as there are people I want to follow on #Bluesky and I also want them to be able to follow me, without me having to manage two accounts.
I hope you don't let people harrass you @snarfed.org@snarfed.org You're doing some really interesting work! (You also seem to be taking vitriol and feedback very well!) Good luck!
A major difference between the #ActivityPub federation and the #BlueSky#Atproto (#Atprotocol) federation is that under AcitivityPub, used by Mastodon, all servers that need to send or receive data from other servers need to make direct connections to each other. This means many queued jobs and many connections, maybe thousands. This leads to the classic sidekiq queue problems when Mastodon instances have numerous users with numerous follows, and relays.
In contrast, in atproto, the user's PDS, Personal Data Server, doing equivalent work of a Mastodon server, for example, only makes a few connections to the relay server's fire hose to deliver and pick up messages. It never connects to any other PDS directly. Theoretically, a tiny #PDS on atproto can handle a considerable number of users. This seems to be an advantage.
Mastodon admins spend a lot of time and money fighting performance issues, database connection counts, and sidekiq queues because the server has to talk directly to other servers. But the PDS only needs to talk to maybe one, or possibly a few relays to get and send messages.
Here's a diagram of the atproto architecture. It appears quite a simple architecture.
#Prediction: if #Threads follows through with #Fediverse support by using #ActivityPub, and especially if #Wordpress and #Tumblr join the party, #ATProtocol will be all but dead. AP will be the standard for social online, regardless of any benefits of AT. #BlueSky will effectively die with it, unless they switch to AP (unlikely as then they’d just be one instance amongst many). Threads joining the Fediverse would hurt BlueSky (and to some degree #Twitter) a lot more than it would hurt #Mastodon.