Been casually poking around the BlueSky/ATProto docs and blogs.
I think I’m now forced to wonder why they **won’t** “win” against mastodon and in turn ActivityPub.
Genuinely interested in what more qualified people have to say on this.
It feels like general criticisms of masto/Fedi have answers in their system and they’re well positioned for growth.
It feels like if they win the hearts of developers and big accnts, and scale well, it could be “over” quite quickly??
@maegul so I haven’t looked myself, but I have heard other people say that when they poked around at the documentation they were horrified by it.
I guess you found it actually okay? What did you like about it?
And to lay my cards on the table, when I poked at the ActivityPub standard that horrified me. It looked completely unable to scale, and I felt like instance operators confirmed that when they started talking about the resource consumption.
I do hope that AT is better.
@mackuba @volkris@qoto.org
Interesting to hear your thoughts!
How much do you think can be built on the protocol by 3rd parties without involving bsky? Also, do you think multiple platform types could work? Like, an independent but federated Reddit substitute but with good interop with bsky itself?!
I’m also unclear on how baked in the BSG thing is to the protocol. Could parts of the network develop without connecting to the centralised services?
@maegul A lot of it is still "you gotta trust us" at the moment, but I've been watching these guys pretty closely for half a year, and I do trust them.
BGS/relay and AppView are the more centralized parts, but the plan is that once federation opens (should be early next year), anyone will be able to set up one too - although they're both pretty resource heavy, so hard to say how many there will be in practice. The code's open source, has been for a while - it's just walled off in configuration.
@maegul They've said that they imagine the number of relays to be "like web search engines now", so multiple independent, but not many.
As for other "apps" - yes, that's the plan, you define a new set of "lexicons" (record types/endponts). Right now the PDSes reject any non-bsky records, but they will accept them in future. Someone was actually already playing with designing a lexicon set for a Reddit-like platform on AT.
So an interesting question to me is how does the experience of running a BGS compare to running a big instance on AP.
Can communities be built around BGSs, which would require that certain policies are implemented at the BGS level?
And how does the onus compare? Like mastodon.social’s resources (pretty hefty) or mid mas.to or mastodon.world or hachyderm.io. Point being that people are out there willing to run their own stuff. That’s a success story of mastodon really.
@maegul I think a lot of such things are a bit up in the air still - it will work out in practice later once these things are actually possible...
It's hard to say which parts will really be "community-forming" here. There definitely isn't something as clear as a Fedi instance. It may well be that BGSes, AppViews and PDSes will just be services you can pick if you care about it, but all forming one shared space in which you can form communities the way it happened on Twitter.
@maegul BGS will definitely have very different usage patterns than a large AP instance - you basically need a big stream in and a bunch of big streams out, but not *that* many, and a lot of disk. But it could be just simpler because there will be less *kinds* of things happening.
Also, it may not be that hard to make alternative implementations that may end up more performant. (People are already playing with their own independent implementations of PDS!)
@mackuba
Oh, the code for their BSG is open! Didn’t know!
So things like BSGs are pretty baked in to the protocol then? As much as I like the idea of centralised services for scale, I thought it’d be nice if the protocol had affordances for going decentralised if you wanted to.
@maegul Yeah, that part is definitely not going away. It should be possible to make independent AppViews and BGSes that scan some part of the network only. AppView decides which BGS(es) it streams data from, and PDS decides which AppView it connects to.
The code is generally in these two monorepos that contain many packages each:
https://github.com/bluesky-social/atproto
https://github.com/bluesky-social/indigo
@mackuba see, this is the kind of thing I really focus on, the scaling of the core, not so much the scaling of userbase and use cases and such.
Without scaleable core infrastructure everyone above it is hamstrung.
You say BGS and AppView are pretty resource heavy, which is reminiscent of some of the growing pains ActivityPub has seen.
All distributed platforms face similar problems of how to transfer and synchronize content between endpoints when every single sender wants to get every single message to every single receiver, a growing list times a growing list times a growing list.
I wasn’t impressed by AP’s solution to this problem, and I wonder if AT has a solution that’s more efficient and effective.
Above you said that there were no missing replies to threads, as a sign that it should scale better, but it worries me that that level of certainty indicates that it will scale worse under the hood with senders struggling to ensure that all content gets to all receivers.
@volkris @maegul Well that's the thing, with the AT architecture there will be much less receivers to send to. In AP, if you have a big account on a small-medium instance, that means your every new post puts jobs in the queue to distribute that post to possibly hundreds or thousands of other servers. For an instance which is not mastodon.social, that could be quite a big burden.
@volkris @maegul In ATProto, PDSes only send each post or like to the small number of BGSes that are listening to everyone. So BGSes and AppViews need a lot of resources, but PDSes need very little. Any new information will be duplicated much fewer times than in AP, where everyone needs to have a local copy of everything.
@volkris @maegul "No missing replies" is because in AP, everyone is browsing the Fedi only from the perspective of their instance, so that instance needs to have a copy of everything - if it doesn't, you're missing replies in threads. In ATProto, your app connects to your PDS which loads most data from the AppView, which has a ~complete view of the network. It's probably a little bit longer roundtrip, but you see what everyone else can see.
Oh, I see, so a little more like the nostr design than AP.
Yeah, I thought the multiple-big-relay design sounded like a good part of the solution to the problem, and I faulted AP for missing aggregation like that.
https://blueskyweb.xyz/blog/5-5-2023-federation-architecture
@volkris @maegul I do like it much more myself (I've been hacking on it since April). It fixes some issues that AP has like the ease of account migration, your identity isn't bound to the instance but instead uses a "distributed ID", the architecture seems like it should scale better, no missing replies in threads etc. It takes different tradeoffs so other people may see some aspects as downsides (no way to control who can access your content, less power given to instance admins etc.).