There is a lot bluesky gets right, and a lot it gets wrong, the same is true with Activitypub.
(Some) strengths of Atproto
Atproto is content-addressed, and portable. This means that posts can exist independantly of their original server.
Instead of giving posts a https uri, which will stop working if a user moves servers or their server disappears, they give them at uris.
For example, this post on bsky.app: https://bsky.app/profile/ponder.ooo/post/3lk4yrmyugc2f
Has the at:// link is: at://did:plc:i4bfh2tyxihe2ksplmtcoopk/app.bsky.feed.post/3lk4yrmyugc2f.
The post does exist over https at https://porcini.us-east.host.bsky.network/xrpc/com.atproto.repo.getRecord?repo=did:plc:i4bfh2tyxihe2ksplmtcoopk&collection=app.bsky.feed.post&rkey=3lk4yrmyugc2f.
Atproto is very easy to build apps on. For example, tangled.sh, frontpage.fyi and flushes.app are all apps built on atproto.
Atproto allows more flexibility in what an app can do, as opposed to lemmy or mastodon’s api.
Atproto is better documented. The ActivityPub spec leaves a lot up to the reader.
Atproto has some really good moderation tools for users. People can make public blocklists of users, and people can subscribe to labellers, people or services which give users/posts a label.
Weaknesses of Atproto
almost everyone is on bluesky’s PDSes. I thought mastodon.social and lemmy.world were bad, but the people on alternate PDSes altogether adds up to only a few thousand.
Its decentralised identifiers are actually completely centralised!
DID:PLC, their DID method, originally stood for placeholder, but they renamed it to Public Ledger of Credentials.
To use it, you have to use plc.directory.
You can use a DID:WEB DID, but if your website linked to it goes down you lose your identity.
(I find it extremely funny that its not actually a requirement for a decentralised identifier to be decentralised. )
Everything on the network has to be public to work.
since relays have to be able to collect all the information on the network for Appviews to be able to make use of that information, anyone can find out who’s blocking someone, or who is on a list, or who’s following who, with no way of hiding that information.
Private accounts and posts are impossible to do on atproto.
Since everything is public, DMs (for now) are centralised. They do seem like they want to change that though.
Strengths of ActivityPub
AP (ActivityPub) is better distributed. While it has large servers (like mastodon.social or lemmy.world (and threads, but we don’t talk about threads)) the majority of users are not on those servers. There is no single point of failure. If bluesky disappeared tomorrow, atproto would still exist, it would just have a negligable amount of users.
One node in the network lets you do everything, as opposed to bluesky which has three parts (You can do stuff without a relay though). This means you can trust a lot less of the network.
ActivityPub scales better than ATProto. Atproto scales quadratically, meaning that having a lot of nodes in the network harms performance.
AP scales horizontally, meaning it works better with a lot of small servers.
ActivityPub can keep stuff private, like blocks and posts.
Though, a lot of implementations can leak posts.
Weaknesses of ActivityPub
The spec leaves so much out. They didn’t propose a way to make sure requests between servers are validated, so mastodon chose HTTP signatures.
They didn’t add any way of looking up handles, so mastodon chose webfinger.
A posts’s id is its https uri, this means thatif a server goes down, stuff can’t be fetched. A user can’t move their followers if their server goes down (you can on ATproto). There is a standard to fix this, FEP-ef61, but it breaks compatibility with a lot of implementations.
Missing information is a problem. Its not really a problem on lemmy, but on mastodon likes and replies from other servers may not make it to your server at all (you can fetch replies in newer versions of mastodon though).
All this aside, I do think the two can coexist. I don’t see anything like lemmy working on atproto. ActivityPub seems closer to social networking, as opposed to social media.
Something like facebook would be impossible to make on atproto, because not everything is made to be public.
I am hoping for a bridge, but good (bridgy is opt-in, making it useless).
For Activitypub, a weakness is that the server has to host all the visible content to the server. So for example if lemmy got really big, and you wanted to host a tiny server but are subscribed to most lemmy comms, your server ends up hosting and fetching a copy of everything posted in these communities, which can add up to A LOT, in terms of network usage, and computational power. (For example see the debacle where an Australian sever (I think aussie.zone) struggled with this and was weeks behind fetching content from lemmy.world since so much content comes from that instance).
This probably would scale pretty terribly if it got anywhere near the size of reddit.
ATProto gives a scalable solution to this (but comes with tradeoffs). Where you can create your own “instance” PDS (Personal Data Server), without hosting all the posts federated to you, since this is hosted by a “relay” which does most of the heavy lifting computationally. So it ends up with a solution that looks more centralised (since there is less incentive to host relays, so fewer relays), but also much more friendly to people who wanna host their own “PDS” and therefore control their data. This is also very helpful with scalability and solves some of the weird federation quirks activitypub has (ie. you can’t see a lemmy community or mastodon account until someone on your instance subscribes or follows it).
Yes, this does help, but atproto as a whole still doesn’t scale well:
In the beginning of our network, we have 26 users, which conveniently for us map to each letter of the English alphabet: [Alice, Bob, Carol, … Zack]. Each user sends one message per day, which is intended to have one recipient. (This may sound unrealistic, but this is fine to do to model our scenario.) To simplify things, we’ll have each user send a message in a ring: Alice sends a message to Bob, Bob sends a message to Carol, and so on, all the way up to Zack, who simply we wrap around and have message Alice. This could be because these messages have specific intended recipients or it could be because Bob is the sole “follower” of Alice’s posts, Carol is the sole “follower” of Bob’s, etc.
Let’s look at what happens in a single day under both systems.
Under message passing, Alice sends her message to Bob. Only Bob need receive the message. So on and so forth.
From an individual self-hosted server, only one message is passed per day: 1. From the fully decentralized network, the total number of messages passed, zooming out, is the number of participants in the network: 26. Under the public-gods-eye-view-shared-heap model, each user must know of all messages to know what may be relevant. Each user must receive all messages.
From an individual self-hosted server, 26 messages must be received.
Zooming out, the number of messages which must be transmitted in the day is 26 * 26: 676, since each user receives each message.
Okay, so what does that mean? How bad is this? With 26 users, this doesn’t sound like so much. Now let’s add 5 users.
Under message passing:
Per server, still 1 message received per user per day. Per the network, it’s 5 extra messages transmitted per day, which makes sense: we’ve added 5 users. Under the public-gods-eye-view-shared-heap model:
Per server: 5 new messages received per user per day.
Per the network, it’s ((31 * 31) - (26 * 26)): 285 new messages per day!
But we aren’t actually running networks of 26 users. We are running networks of millions of users. What would happen if we had a million self-hosted users and five new users were added to the network? Zooming out, once again, the message passing system simply has five new messages sent. Under the public shared heap model, it is 10,000,025 new messages sent! For adding five new self-hosted users! (And that’s even just with our simplified model of only sending one message per day per user!)
Source: https://dustycloud.org/blog/re-re-bluesky-decentralization/
As well as this, if there was a reddit-like atproto AppView, setting up multiple instances of it would still result in the same problems.
But this is assuming private messages no?
When 99% of the public traffic is on posts that will federate to most servers, this model becomes irrelevant.
That’s a good point.
I think by recipient they meant followers in general.
I think in order for both to work towards a better fediverse, there needs to be a “true” sync. Not like the bridge Bluesky is maintaining, we need something to sync both ways. Even if its just a subset with just public posts to begin with.
I know a lot of fediverse software has their own API that extends their own functionality beyond the AP protocol, just to make things more complicated :). But it does help with say bookwyrm needs to know something specific from another bookwyrm instance.
do you mean instances having a native atproto implementation? Wafrn is kinda like that.
Also: Bluesky isn’t maintaining the bridge, its maintained by someone else.
Does PieFed vary much from your Lemmy / AT analysis?
What do you mean? As in, not missing information? In that case, it is the same as lemmy. Though iirc that’s only for stuff in communities.
Hmm.
PieFed is ActivityPub compatible, but has some features that Lemmy doesn’t. I’m just wondering if it has any differences that might go into your strengths and weaknesses assessment as a result. It’s a bit like how kbin / mbin are similar to Lemmy but not quite the same.
Ah, right.
Well, this is just AP in general.
Though, piefed having community moving is great, since communities aren’t trapped on their host server. I don’t think lemmy.world would be as big a problem if they could move communities there.
Very interesting, thanks.
Atproto scales quadratically, […] harms performance AP scales horizontally
Clearly true. But this suggests to me that ATProto might still work well with, say, 5 or 15 "PDS"s. That is still enough IMO to guarantee a high level of pluralism.
In a commercial market, let’s say for telephony or cars or web browsers, we readily accept that there are only a handful of players. Indeed, there’s generally an optimal number, high enough to guarantee competition but low enough that we can keep track of the brands and trust that they won’t go out of business tomorrow.
And nothing is stopping at least one of those few brands from being a “good guy”, akin to Mozilla’s historic role in the web-browser market. It could be run by say, Wikimedia, for example. At least we would know that it would not disappear tomorrow, which is more than can be said for most Lemmy instances.
I agree that there should be enough space for both ATProto and AP to thrive.
I feel like that’s closer to email, which is a shitshow when it comes to decentralisation.
Yes, good parallel, didn’t think of that. Perhaps there’s just a limit on how much you can decentralize without things breaking down for either social or technical reasons.
