i wonder if diagrams like these might help draw the distinction between ActivityPub (and how Mastodon uses it) and AT Protocol (and how it’s used by Bluesky and atproto apps)?
with AP, instance = application + hosting. data gets sent between instances.
with AT, data flows *from* hosting *to* apps
with AP, instance = application + hosting. data gets sent between instances.
with AT, data flows *from* hosting *to* apps
1 / 2
Comments
In AT, since there's no data format standardization, an app can keep obfuscating its data and break portability.
how do apps "learn about" hosts? is it (also) similar to how search engines "learn about" websites?
however this is an optimization & you can run your own
figure out how much it actually would take for someone else to stand one up
i know the team has published some figures before...
I'm taking that to mean that the relay is proactively seeking out a new PDS that has not announced itself?
How does that work?
… considering that self-hosting is already possible.
if there is no cooperation required between the previous and the next host when moving accounts, it means you might have end up having duplicates, right?
in this case, is there a winner or two accounts? what about handles then?
AT for the connection between data and app, AP for the connection between instances of that app...
The ActivityPub model (or […]
also you didn’t label which was which!
So there is no barrier to someone else forking and making an alternative front-end as well as data storage?
i love diagrams so much, we need to use them more ong
- why there is no notion of “instances” in atproto
- why atproto lets you move hosting without any cooperation with previous host
- why getting your post viral doesn’t cause a surge of traffic to “your instance” with atproto
on the right picture, there’s just one Bluesky app. there are no Bluesky "instances". but people can build their own apps
this is possible because all data is signed — so every app can verify that you have actually written the posts the app received and they weren’t tampered with in transit
comparing atproto with AP verbally is hard because AP couples hosting and apps
and then the apps are downstream from your identity & data
atproto decentralizes Hosting. and it lets teams come and bootstrap new Products from an existing social content graph
It's like having a Discord guild. Guilds have access to the same baseline userbase of Discord (these are PDSs), but only a tiny fraction of them ever actually join your guild, you have to invite them.
I’ve wondered about this. Wouldn’t a viral post still send a ton of traffic to your PDS (updates to various collections)? Albeit originating from the app.
an atproto instance is maximally defined by a relay(f.k.a. BGS) and minimally defined by a PDS, where state + rules are engaged.
bsky is one instance defined by its own relay and PDS
another instance just needs its own relay and/or PDS
their notion of an instance is monolithic indeed.
OTOH, an ATProto instance is more modular, extendable from the small world(PDS) to big world(relay)
i'm not sure why bsky's appview does that besides maybe redundancy but it's settled into one state view EOD for end-user.
bluesky-the-company's PDS's influence the state view of bluesky-the-product
this is probably half the reason Mastodon didn't catch on? there was not much going on there, and I didn't care enough to start over. 😌
I'm not sure what it was based on. 😅 In fairness, Mastodon® got big enough to be mistaken as a network, even #Wikipedia labeled it incorrectly (and inadvertently contributing to the confusion).
However, ActivityPub being two specs in a trenchcoat, people built apps the way they knew how to: as monolithic codebases
it’s worth noting that for AT it’s also possible to make consuming data cheaper and more scoped, e.g. see jetstream
Well, obviously yes, but I'm looking for something super quick to read for people who can't distinguish X from Threads from Bluesky. What would you change?
https://mathewlowry.medium.com/ai4communities-bluesky-newsletter-331a25909cc5