Good overview by a #Bluesky dev on how the #ATProto network has changed over the last year: from a single server, to a group of different servers, to internal federation with multiple PDSes, and now an externally federated network with independent PDSes, feed servers and moderation services: https://bsky.app/profile/dholms.xyz/post/3ko5bleclzs2o
(The UI shows the first few posts, click on the last one to load more)
Let’s say you’re trying to decide between two Mastodon instances, run by Sandra and Billy.
You agree with some of Sandra’s moderation decisions and priorities, but not all of them. Same with Billy.
Which do you join?
In the #Bluesky/ #ATProto model, you can opt-in to both of their moderation systems, and set custom warning/hide levels for different categories of offenses.
Then if one of them starts getting weird or shady, you just unsubscribe, no need to migrate your account anywhere.
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
It saddens me that the people/developers over on #Nostr have decided to intertwine the fate of their #socialmedia protocol with that of #bitcoin and other #crypto currencies. One day, bitcoin will be banned almost everywhere, including in the US, and its downfall will lead to the fall of Nostr as well. How can they not see thru bitcoin's ponziness?
"If you want to scale, you have to design with scale in mind. #atproto makes several interesting choices in order to distribute the load of running the system more onto the actors that can handle load, and less on those that can’t. This way, applications running on top of atproto can scale up to large userbases without issue.
That’s the hope, at least. Earlier this week, #BlueSky hit five million users, and is far more stable than Twitter was in the early days."
I've seen #ATProto get flak for how the design folds up into relays, but really that architecture has so much to commend it over the way that we're doing it in #ActivityPub today.
It has some notable disadvantages for what people are generally looking for here as well, sure, absolutely. Just let's not all pretend that what it is doing isn't valuable or that the tradeoffs don't make sense.
We see the consequences of AP's design choices in this space every day, but that doesn't make them better.
There's this phenomena of normalizing the thing that you deal with every day. We treat the flaws in AP as "less severe" because we've either already found ways around them (good or bad ways being another discussion) or because we normalize that pain.
In reality: very few engineering decisions are absolute one way or another.
Instead, we need to talk tradeoffs and also talk about what we want out of #ATproto that is hard to achieve in #ActivityPub and see if we can find ways to get there.
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.
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.
Come alcuni sapranno, non me n’è mai fregato granché di #Bluesky, o del suo #ATProtocol… fino a prima di oggi. Perché si, con anche tutta la tecnologia open-source alla base osservabile e utilizzabile da chiunque, sarebbe stato l’ennesimo esercizio di costruzione di una rete centralizzata, che nell’anno del signore 2024 proprio no, se anche non esistesse ActivityPub, preferirei comunque i blog #selfhosted. 🗾️
Tuttavia, #notizia di ieri, è partito un #esperimento di federazione per chiunque voglia provare a self-hostare il #software necessario. Tutto un po’ strano, è una #federazione in qualche modo condizionata, che dipende dal #server centrale e ha dei limiti artificiali, ma è un inizio verso qualcosa di #interessante. Almeno, avendo letto anche l’articolo di blog non-tecnico, questa è la mia impressione, e per la potenzialità di espandere il mio regno del terrore su nuove sponde quasi quasi ci provo. 😈️
Perché — premettendo il fatto che non ho dati oggettivi per dire questa cosa (dovrei raccoglierne e analizzarli, ma questo non è un campo dove sono esperta, quindi mi trovo in difficoltà) — la mia esperienza sul #Fediverso mi suggerisce che aprire la propria #istanza personale (come questo stesso sito, ma penso anche a quando avevo il mio Misskey) significa cadere nella totale irrilevanza, in confronto allo stabilirsi in quelle bene o male grosse. Con #ATProto il focus vuole essere sempre e comunque la connessione ad una sola #comunità globale, quindi la #decentralizzazione per singole persone può non costituire alcun aspetto negativo per la propria discoverability, le proprie note dovrebbero poter essere cagate da qualcuno e non perse nel fiume di #Internet… 😇️
Con #ATProto il focus vuole essere sempre e comunque la connessione ad una sola #comunità globale, quindi la #decentralizzazione per singole persone può non costituire alcun aspetto negativo per la propria discoverability, le proprie note dovrebbero poter essere cagate da qualcuno e non perse nel fiume di #Internet… 😇️
Ma questo avviene perché le PDS vanno comunque a pescare in un unico (per ora) BGS?
The more I look at the BlueSky documentation and try to make sense of their proprietary jargon, the more my head hurts.
It just doesn't make any sense to me how this is different from ActivityPub and how BlueSky doesn't control what federates.
I keep seeing people say it's decentralized, but if they can control who federates with bsky.app then is it really decentralized since that's where the vast majority would be anyways?
What the hell am I missing? Yeah, you have more control as a user, but that doesn't tell me a damn thing or connect their PDS, DID, NSID jargon to anything that makes sense to me. Maybe I'm just too dumb to understand this and that's fine.
Fediverse is where I want to be anyway. I just thought it might be interesting to try it out but if I don't understand it, then it's not really worth it.
#Bluesky introduces distinct features in federated social networking, diverging from Mastodon's model.
Key differences include global conversation access regardless of server, composable moderation tools, over 40,000 algorithmic feeds for a tailored timeline, and seamless account portability. These innovations aim to enhance user experience and engagement across the network. https://bsky.social/about/blog/02-22-2024-open-social-web#pds
Bluesky announces early access federation for self-hosters.
The initiative allows for broader connectivity within the #atproto network, enhancing the flexibility and scalability of personal data hosting. Key features include simplified #PDS setup, rate-limited data routing to maintain network integrity, and promising steps towards account migration capabilities. #Bluesky#OpenNetwork https://docs.bsky.app/blog/self-host-federation
Side note: I wish that people would stop spreading misinformation about #BlueSky and #ATproto
You might not like them for a myriad of reasons and not trust them for a myriad more, you may never want to talk to them, you might hate their goals, but we can have that conversation without spreading misinformation about them.
There are some very normal people on the Fediverse… Honestly, zero regrets about building for #ATProto and not ActivityPub so I don't have to deal with this kind of attacks myself. My sympathies to Ryan.
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.
#ATproto (BlueSky) v #Activitypub (what we use here) will be painted as a fundamental decision to take. That’s simply not true. Both have good and bad points. There will never be a moment where we can definitely say one has won. The world isn’t binary, no matter how much clickbait begs to differ ;)
In the far, far future, protocols might look a lot like #Nostr, where email addresses and phone numbers aren't required, and passwords are replaced by private keys.
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.
@maegul
Right. Portability is a red herring though. Its effectively meaningless - who cares if i can move my website host. Who cares if its technically possible to block google from crawling me if everyone i know can only find me through that. Worse, if they can only find me through something that doesnt tell anyone where it gets its websites from. What benevolent organization has the resources to crawl everything without ulterior motive, and again how would i even know? If we organize a mass movement away from the main relay because its downright dangerous to have everything public, we would also need to make that relay break the protocol to be private access to similarly safe feed generators and app views, host our own PLC resolver - breaking the chain that makes migration possible, even if i still technically hold the git repo with the right hash, they own the means of finding it.
It all seems nice until you think about how any of it would actually play out. It would be cool to be wrong, id love to see a web utopia spring up from a platform billionaires pocket change, it would be such sweet irony. but seeing the same focus on account portability trotted out again and again without answering any of the hard questions keeps demonstrating how shallow this pipe dream really is. Moving accounts on the fedi is too hard, true, but to still think thats the main barrier and the answer being to give me literally only that and my ability to shop for a new algorithmic slop bucket as agency is just demonstrably wrong the second you think twice about it.
App views invert identity, and thats sort of interesting for a minute - instead of me subscribing to a platform, the platform subscribes to me. Except wait wasnt a series of platforms that mine all my data to serve me targeted shit the whole problem in the first place? Why is it compelling to require any indie app view to require me to surrender literally all my data to something they literally and uncritically call the firehose to be viable? Even if the indie app view is beautiful and lovely, it structurally depends on Sidechannel Information Leaks As A Service where now instead of a single platform having to win my trust to harvest my data, to merely exist online i literally must allow literally everyone to harvest it so i can have the privilege of them telling me what to look at.
They talk about how many thousands of algorithms have been created, but take a look at the list of them, it shows you how many people subscribe to them, sorted by popularity, descending. Compare that to the number of accounts on bluesky. Try and find the source code for the most popular feeds. If you can, are they doing anything more interesting than a manually curated list of accounts or posts that contain a hashtag? Try and find an algo that does actual account-level recommendation. Are there any? Youll find a handful of open source ones that have shut down. Try and run one. What happens? Who has the resources to run something like that? For how many accounts? Sample the firehose for a week, including all your feeds. Compare the number of accounts and posts that show up there to the number of accounts active in the firehose. If it really worked, youd expect to see a lot of different algorithms serving a lot of different posts from a lot of different people to a lot of different people. Evaluating how far that is from reality is left as an exercise to the reader.
And thats the network working as designed - saying nothing about the intrinsic impossibility of safety given the identity model.
I find very little of it compelling. I was interested in lexicons until i saw how they are used in practice as a wildly ineffective and repetitive API spec. I was interested in the use of DNS and DIDs for lightweight identity beacons until i saw how almost a year (?) later there are no viable plans to replace PLC with anything but Identity As A Service. I was interested in the PDS as a signed data store until i saw how it was only discoverable and useful by being crawled by a single public relay. Its a hodgepodge of half finished ideas that could be cool if any critical feedback would actually affect the design.
As i always say when i talk about this, id love to be wrong, and if it turns out to be really cool ill happily join. #bluesky#atproto