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. 🧵
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.
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.
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)
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.
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.
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.
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.
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 swear, sometimes when I see what people write about #Bluesky / #ATProto on Mastodon, I feel like I'm watching the Polish state TV controlled by PiS, if you know what I mean… Completely parallel reality, independent facts, split timeline.
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.
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
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.
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… 😇️
I've released an update to my "Skythread" Bluesky thread reader - it's now available without authentication, so you can share thread links with people who don't have an account. I've moved it from GitHub pages to my own server now: https://blue.mackuba.eu/skythread/
Also as a bonus: it now has a dark mode 🌚 (beta, will need some tweaks)
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?
Serious question. Is it a complicated process to get the desktop emoji picker to play nice with dark mode? It seems Mastodon and Bluesky both have this problem
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.