The paper figure is a lot cuter, but by linearizing it and presenting it as two parallel tracks they have obscured the most salient feature of the network: the big relay in the middle. Beyond "centralization bad," that pins down most of the undesirable and dangerous features of the protocol, and makes it seem like theres a lot more choice than there is.
Since the design purposefully hides the architecture: you dont know where your feed generators are drawing from, or those used by your friends. So you cant know what the effect of choosing a different relay would be, aka the main relay is always indispensable. Importantly the relays subscribe to you, you dont push to the relay, and since you arent really supposed to operate your own data store, you can be dropped from the network without knowing - the relay serves as an unaccountable point of moderation.
Its this part for me that tells the whole story: #atproto was designed for a new kind of advertising market, and when their VC money and puttering domain registration revenue streams dry up, control over the main firehose relay is a big gaping profit vector waiting to be capitalized on.
Checking in on whether #bluesky / #atproto has become any more like a communication medium, and... nope. almost unchanged since i looked at it last in June. Bluesky is a spectator platform where a small number of accounts receive most of the visibility and smaller accounts are effectively invisible. The introduction of new feed algorithms (to the degree that happened, there aren't really many that I can find in wide use) did not change that. This is a non-normative analysis: in some cases, it is good to have a medium that promotes some very small number of posts and accounts, eg. to surface singular events, etc.
From a 25h sample of the firehose...
600k posts, 2.4m likes, 250k boosts, 350k follows
40% of posts receive 0 likes, 70% receive <= 1
accounts in the 99th percentile of likes received 44% of likes, accounts in the 95th percentile received 74%
40% of posts were from accounts within the top 95th percentile of accounts by likes received.
the maximum number of likes for a post by an account not in the top 95% is 32.
The first plot below shows the cumulative sum of likes received on the y axis against each account in the sample on the x axis - this includes accounts that didnt' post during the sample (but would still have posts that could be liked, so this also shows the extreme recency bias). The second plot is a hockeystick showing the number of likes (not cumulative sum) received on the y axis per post on the x axis.
For background, the default algorithm only cares about likes, boosts don't matter, which is why i am calculating things by likes here - they are the primary algorithmic signal.
These are the same calculations that I did back in June, but this time i'm leaving the firehose open to do a longer sample to be able to parse momentary virality from persistent effects.
Actively pushing against others to adopt your protocol is how you ensure that your protocol won't "win." I'm a firm believer that a decentralized protocol will be the future of social networks/feeds as we know them. I don't know if it is going to be #ActivityPub or #ATProto or something else. But I believe a decentralized protocol will be the future. But the winner will be the one that centralized-acting services adopt. That's a good thing for everyone. It means users have data portability. 🧵
For this weekend's coding project, I built a tiny single-user Bluesky→ActivityPub one-way bridge I named “Pinhole”. If there's someone on Bluesky whose posts you want in your Mastodon feed, you can download and run it yourself: :fietkau_software: https://fietkau.software/pinhole
Caveats: 1. I intentionally built it anti-scalable: you can use it to follow one Bluesky account from one fedi account, and that's it. 2. You need experience with web servers.
So OK I keep trying to like #atproto / #bsky, lexicons specifically but they make it so hard. like... let's see, OK we're going to reinvent RDF and JSON-Schema such that
there is some concept of a "namespace authority" rooted in DNS ownership of a domain name that is supposed to maintain a set of lexicons and do things like make sure there are no duplicates (eg. lexicon IDs are case sensitive but you are not allowed to have IDs that differ only in case, which a ns authority has to ensure)
but there is no means of using the domain to retrieve a schema, so eg. it is explicitly not spec'd to require com.example.myLexicon be at myLexicon.example.com - so the whole goofy Javabrained reverse-domain name thing as the ID is pointless
Accordingly, lexicons have to be sourced ad-hoc and by convention, and the convention is bonkers!!!! According to their reference implementations, the way you are supposed to use lexicons is to autogenerate their json schema definitions and version them locally everywhere they are used. I can't express how baffling this is to me - like the atproto monorepo has a top level lexicons directory, and then their Makefile then goes through several of the subpackages calling each of their (separate) code generation scripts, resulting in local, vendored copies of each of the lexicons - and by copies of the lexicons i mean both generated code AND typescript interfaces AND an entire copy of the whole schema.
This is presumably because there are REFERENCES between lexicons EVEN WITHOUT those lexicons having a meaningful notion of location or dereferenceability - how would you know what 'app.bsky.feed.defs' is referring to unless you packaged and built all lexicons together? the method for resolving references literally requires them to all be locally present at runtime as far as i can tell, idk the lexicon code is unreadable to me.
There is no means of versioning, so "Once a schema is published, it can never change its constraints" and the only means of changing is to change its freaking name, so com.example.myLexicon.FinalFinalv2 is explicitly encouraged. The reference implementations repeatedly violate this, though, so whatever.
Again, there is no actual mechanism of "publishing" a schema, though, so it's completely unclear what that's supposed to mean - how do people know the schema has changed names since they just have it hardcoded in their clients?
and the entire spec documentation is just a bunch of harebrained ideas that amount to, as far as i can tell, just literally being JSON-Schema just different? And they compare it to RDF but there's literally nothing to compare there except for the absence of an explanation as to why they didn't just use JSON-LD. I literally cannot tell how this is supposed to work as an interoperability/extensibility layer if there is no means of resolving terms or lexicons and all definitions have to be known in advance.
Both Rachel and Peter suggest that some moderation functionality could/should become part of the protocol stack. #AtProto does composable moderation and that is really cool. Peter hopes that #ActivityPub may learn from it and evolve in this direction.
Welcome to a new short series on Bluesky and how the network works. Bluesky recently releasedmore information on their plans for third party moderation services. While writing about their plans, I realised that to properly explain how it works, I first needed to explain how the network is designed to function.
Most people understand the fediverse in terms of separate instances. Every instance can be a social network in itself, and by connecting with other instances form a larger network, the fediverse. This makes it easier to understand where content moderation happens: every instances has their own content moderation, own moderators and their own rules.
The Bluesky network and the AT Protocol function differently. There are different types of servers; servers for data storage, servers for data aggregation, etc. As such, content moderation happens in different places on the network. To properly explain how it works, the benefits and tradeoffs, as well as the unknowns, I am publishing a short series on Bluesky, how the network functions, and how and where content moderation happens.
In this first episode: the parts that make up the network and allow it to work.
The basic components
The Bluesky network consists of the following parts:
A Personal Data Server (PDS) that hosts all account data. It contains information about your accounts, and is where all your personal data is stored.
A Relay looks for all the PDS’s in the network, takes in all their data, and merges it together to outputs one big stream that is used by other parts of the network. The Relay puts out the data in a machine-readable format, which is often called a firehose.
AppView takes the data from the Relay, and processes it so that it is more meaningful for apps. Examples of the processing that AppView does: counting the amount of likes that a post gets, collecting all replies to a post and organising them into a thread. It also generates your “following” feed, by creating a reverse-chronologically ordered feed of posts made by the accounts that you follow.
An app, whether that is the official Bluesky mobile app or a third party website like deck.blue. The app takes the data from AppView and presents it in a nice format for people read on their preferred device.
With these four components we can imagine a basic social network:
If you open the official Bluesky app on your phone and look at the “following feed”, the data flows as follows:
All PDS’s => Relay => AppView => App.
If you then create a post and hit send, data goes from your app directly back to the PDS where your account is hosted.
Custom feeds and moderation
There are four more components to the Bluesky network: feed generators, labellers, the moderation service, and the Identity Directory.
A feed generator creates the custom feeds, using some form of algorithm. These custom feeds can be anything from a feed with the posts with the most likes in the last 24 hours, a feed of posts that contain specific terms, or anything else.
A feed generator takes data from a Relay, performs the calculations to take the raw data into a custom feed, and sends it to the AppView. The AppView then performs some final steps and sends it to your app so you can see the custom feed.
Labellers. Labelling services perform moderation activities by applying labels to a post. People can determine how they want to handle labelled content. An example of a label can be ‘Sexually Suggestive’, and people can determine if they want their app to either show, hide or warn about posts that contain the label.
A Labelling service takes data from the AppView, processes it, and then sends it back to the AppView
The moderation system, called Ozone, that allows moderators to take moderation action, such as taking down posts or accounts. This tool has the least amount of information on it, and it is not visible Federation Architecture documentation. The update this week by the Bluesky organisation shows that the system is called Ozone, and that they are in the process of making it open-source and available for others to use.
The tool at least allows moderators to alter data in the PDS, as that is where account data lives.
Every account on the Bluesky network has a unique identifier, called a DID. A DID is a unique string of random numbers and letters, and cannot change. Every account also has a handle, which is your username. New accounts start with youraccountname.bsky.social as a handle. The network also allows you to change your handle to a domain name that you own, which allows for easy verification. The information about which DID corresponds to which handle is stored in the DID PLC Directory.
Now we have all the components that together make up the Bluesky network. In the next part, I’ll take a look at decentralisation and federation, explaining for every part how it will play a role in decentralisation and federation.
Thanks to Kuba Suder for feedback on a first draft.
The #Mastodon software setting of #Spoutible is now a dropdown menu. Currently only for mastodon.social and mastodon.online.
Maybe it's temporary but if it's not, they'll have to add at least a hundred reputable and popular servers. Also, it's Mastodon software only. There are far more software, older and/or better than Mastodon which will probably not get support, at least as far as the approach I am seeing.
"ActivityPub and ATProto break #siloing in different ways. #ActivityPub is built around URLs and can "socialise" more or less anything on the Web, which is great, but they don't touch the underlying substrate—either you run your own server or you…are at the mercy of an admin. #ATProto, on its side, provides a good initial foundation for an extensible #PDS designed around user agency and credible exit.
…you can be guaranteed to be able to take your content elsewhere." https://berjon.com/ap-at/
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.
Yesterday, I set up a #Bluesky#PDS (Personal Data Server). The domain is: blue-ocean.social.
If you visit it, you won't see much other than it saying it's a Bluesky PDS. It has no UI.
Before I go on, PLEASE do not respond about why Bluesky is a POS, evil, the best, the worst, better or worse than something else. This is a technical post for people interested in the technical aspects of Bluesky hosting/federation. I, personally, do not use Bluesky. I prefer Mastodon, for my own reasons. Please don't go off-topic.
#Bluesky just released the first piece of its federated infrastructure that uses their #atproto (#ATProtocal) network, which is similar to ActivityPub in what it wants to achieve.
This first independent Bluesky component is meant for people who do not want their data hosted on a corporate-owned server. Unlike Mastodon where data is kept inside a complete social media platform, in Bluesky the data sits in what they call a PDS (Personal Data Server). It does nothing more than serve as a repository of user data and for keeping account information about the person who owns the data on the PDS. It can do nothing more.
You can create a PDS just for yourself, your family, your friends. You can use someone else's PDS if you just prefer to keep your data on a non-commercialized volunteer-run server, exactly as it is done with Mastodon.
This PDS holds everything that the hosted account posts. All the other PDS servers, and Bluesky corporate servers talk to me. I am part of their network. My Bluesky ID is jerry.blue-ocean.social because the ID contains the PDS server name. However, internally, you are also given a DID, a unique identifier that stays with you, like your cell phone number, and shared across all the servers.
If you move your data to a different PDS, you provide the DID, and regardless of your new handle, the system knows you as the same person you were before.
While my account (identity) and my data are solely managed on my new PDS, I still need to use a separate Bluesky app to log in because this is just a data server, a repository similar to GitHub, where my data gets checked in and where my identity is stored.
I used https://bsky.app to log in with my username (jerry.blue-ocean.social) and password but could have used any Bluesky app to log in.
Setting up the PDS was quick and easy. I have it hosted at Digital Ocean on a 2GB/2CPU 60GB droplet for $18/month. Memory use is at 35% and CPU is typically at .3%.
The installation script installs Docker containers. It set up everything quickly. For now, you have to join the admin DISCORD server and give them the domain name for them to enable on the network. In the future, this won't be necessary. They just want to be in touch with early adopting Admins.
The only thing they left out of both the documentation and the set-up script is how to set up the SMTP server. This is important. The PDS is the only server that communicates with users whose identity it's responsible for, so the server needs to be able to send emails. For example, when you confirm your email address in the app, it is the PDS that sends the confirmation number.
Bluesky promises that it fixes some Mastodon issues, like moving to another instance without losing your data should your PDS go down, or the admin kicks you off, but to me, it promises a lot more than it really delivers for this.
Here is an extraordinary blog post about Bluesky that includes how they implement this promise, along with trade-offs about using Bluesky vs. Mastodon: https://lrhodes.net/social/bluesky-portability (@lrhodes)
This PDS release is the first beta, and it comes with restrictions. No PDS can have more than 10 accounts, for now, and is limited to 1,500 events/hour, and 10,000 events/day.
I have 9 more accounts available on the PDS. If anyone wants to use Bluesky without having your data hosted on the corporate PDS, and you plan to actually try using and playing with Bluesky, I'm happy to give you an invitation code. In theory, in the future, you can migrate to any other PDS if you like. So this can be your temporary, or forever home.
Remember, this is beta, and so no guarantee that something bad won't happen, and then you'll lose your data. They make this clear that this is beta software and that people can lose their accounts.
I would like to eventually be able to store data in an S3 bucket and move the database to another server, especially when the 10 account limit lifts. There will be downtime at times while I struggle to upgrade the server and maintain it. Something else to know if you want an account on this PDS.
Admin functions are currently limited to updating to a new version, creating and deleting accounts, password resets, generating invite codes, and a couple of other things. All functions are managed through CLI (command line interface).
If you know of anyone worth following on Bluesky, do tell.
While I don't want to get into #ATProto until some questions on governance are answered (and I'd rather something like AP), there is a lot to like here and a lot of things I think we'd be extremely foolish not to use as concepts as we look to the future of #ActivityPub.
Going into some of the specific things I like a lot here that are simply not possible* in AP today…
(* yes yes it is possible to conceive of how to do it in AP in a completely non-interoperable way, you're very smart)
Not every fediverse user want to connect to Bluesky but for those that do, you can look into using Friendica. The next release will allow you to use your Bluesky account from within Friendica. Interact with Mastodon / Msskey / Pixelfed etc and Bluesky users together on one platform
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.