@fediversereport Thank you for sharing. It is exciting to see what is happening! I think your point at the end is really worth considering: is #Bluesky and the #ATProto interested in multiple apps or is it merely a vehicle for microblogging? I don't have technical background, but I suspect that the decentralization for BSKY is more for show than practice. Critique #ActivityPub all we like but I do think the commitment to platform diversity is there and is practiced.
So #atproto has those feeds that subscribe to the bluesky firehose of posts and then ignore any post that doesnt match the filter, anyone know if there's an easy way to subscribe to #activitypub relays and send specific posts to my mastodon instance, because I can't afford to subscribe to and store every post on a relay, but if I filter it out to only include hashtags I follow that's much more manageable
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.
The whole idea of BlueSky supporting nomadic identities but the rest of the ActivityPub (plus other stuff) Fediverse being unable to do so is such an oversold idea.
A new service using ActivityPub behind the scenes (and not the AT Protocol) can absolutely support nomadic identities, even if the service doesn't treat a whole website as the actor.
It will still use did:plc, same as AT Protocol (BlueSky), but once done so, an application that understands how to work with did:plc can dereference an actor based on the DID.
That said, an existing service will simply not be compatible with this idea, without changing how it operates.
“Blacksky is providing a platform to amplify, protect, and moderate Black content so users can safely build community online.
“The mission and purpose of the project is to de-center whiteness as the default and to provide a space for Black folk to discuss the Black everyday in a way that feels affirming.”
Activitypub or Atproto ... one item that both Mastodon have in common with Bluesky is amount of "spam" links and accounts boosting those "spammy" accounts
Several "award winning art / photo" profiles I saw had 5 or more links including their pinned post
Win goes to Bluesky since they seem to have better control of that ... for now
An important distinction is slowly being uncovered about the definition of the term "fediverse." Who is it that gets to decide what this place is? How are we being represented? These are not easy questions to answer and if we don't do a better job describing ourselves, then the job will get done for us by people who don't understand the underlying values we hold. #fediverse#meta#threads
@liaizon Personally, and the way the term was used, since it was first coined, was any software with #OStatus support (later #ActivityPub).
When there were discussions of having a new name, I ran suggestion threads and polls about it, and one suggestion/choice was mycelial, mycelium. I like it so I started using it myself.
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
I occasionally log in here to keep it alive because this is historical and memorable for me. During this time, and before Mastodon was released, I was running my own Fediverse instance powered by #Hubzilla.
Back then, the protocol of the fediverse was #OStatus, work on #ActivityPub was still about to be started (IIRC).
Today, we have another federated protocol: #ATproto which is powering the #BlueSky network. (Or, is it ATproto network and BlueSky PDS?)
(PS. Max chars in Aleph.Land is 1024; and using the #GlitchSoc fork since it came out.)
#Bluesky just opened up support for hosting your own server. So I spent a few hours setting one up.
It was pretty painful. The documentation is incomplete, and there's still a manual approval process that is opaque.
It's also not what I expected. It's not like Mastodon where you wind up with your own fully-hosted instance with its own URL. Instead you still access your server via the main web app at bsky.app. The DB is self-hosted but not the UI.
From what I've read when they first went public about it, it was because of #portability which don't exist in the #ActivityPub protocol. When I informed them about the #NomadicIdentity powering #Hubzilla (and #Streams today), they said they weren't aware of it (at least from what I can recall), so they'll look into it.
The second reason is moderation. Which, if we only look at AP protocol it's pretty much basic, if any. But if they were only aware of Hubzilla's #Zot protocol before they started their project, they probably would've used it since moderation and permissions are awesome in Zot (far better than what #Bluesky / #ATproto currently have today).
And well, they already started their own project and set up their goals, so they pushed for it.
At least that's how I understood it. Not necessarily accurate.
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.
Regarding #Bluesky opening signups, one person on HN comments:
> The account portability is probably the biggest problem with the #fediverse right now.
And while that may be true from an end-user perspective, imho it is not the biggest problem. The fact that for a new dev building an #ActivityPub app is like a Viking trying to discover America is problematic. While #ATProto has the Holland-America line where you can check in for the ride.
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.
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.