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.
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.
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.
AP isn't completely stagnant but there's a reason AT is still holding on to and accelerating that early developer excitement AP had. Maybe it's marketing, maybe it's money, maybe it's some technical thing. Maybe it's the community. Whatever it is, people seem to enjoy developing in the Atmosphere in a way I never saw on AP.
Of course VC funding and startup mindsets prefer a protocol that is easier to rugpull.
(as I understand it) the data has to live in a PDS, PDS are keyed by accounts, so you are similarly stymied for collaborative projects? I guess AT Proto is still a real work in progress so maybe that story has improved since the last time I checked it out.
this is the key bit, atproto has this. sidecar services like knot can use service authentication[0] for authenticated requests.
https://dholms.leaflet.pub/3meluqcwky22a
https://dholms.leaflet.pub/3mfrsbcn2gk2a