You might be having a bad day, but at least you didnt spend like a decade developing a social media protocol that was structurally incapable of DMs so you needed to make a whole second E2EE protocol
Bluesky enthusiasts are stating that Bluesky has ”plans” to make ATProto universal and transfer it to W3C or the like. Well, there is no evidence that Bluesky wants to give up control or the protocol is going to be widely adopted after 5 years of development so forgive me being sceptical. The story is a bit different with ActivityPub.
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.
(I don't know what's the status of the "10 users" limit, at least the Bridgy PDS got it lifted, but even if it's not announced yet I think it's also going away / or will be relaxed soon)
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
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?
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.
"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."
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… 😇️
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.
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.
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.