Item — HN Reader

ActivityPub and atproto are differently shaped. Pitting them against each other is like asking “why need web when we have email”.

ActivityPub is email-shaped. Servers are inboxes sending messages to each other.

atproto is web-shaped. User repositories host data (like personal sites or git/RSS), while apps aggregate from repositories (like Google Reader).

Different topologies lead to different properties. Eg atproto lets user change hosting with no disruption in app experience. atproto also lets anyone build new apps aggregating over existing data.

ActivityPub doesn’t allow either of those things. It’s literally a bunch of small centralized coupled hosting+app services messaging each other.

1 comments

Calling AP services a bunch of small "centralized" services in this context removes all the meaning from that term. You might as well call any web server centralized while comparing them to clouds.

Proper federation is exactly such bunch of small services messaging each other. On the hand, what ATProto leads to is at most a handful of large-scale providers each running the own portion of the network.

There’s a clear difference in architecture between

1) a layer of app-agnostic hosting providers + a separate independent layer of apps aggregating over data from those (like personal sites with RSS + aggregators like Google Reader)

2) a circle of flat instances where each node couples app+hosting (like many little Twitters)

One doesn’t couple hosting with apps, another one does.

Mastodon/AP model is (2), atproto model is (1). You should be able to see the outcomes from different network shapes.

In atproto, you can build a new app that works with existing data, but in AP you can’t. In atproto you can move hosting with zero effect on your identity or how you show up in apps, in AP you can’t.