What's the trade-off between this and ActivityPub?
I might be being cynical but I think I've seen this story play out before. Did Bluesky genuinely believe that AP wouldn't work for their use-case, or did they want to own the protocol?
A couple of pretty good reasons (except the one about lexicons IMHO), but I don’t think it’s reasonable to believe the maker of a 15th standard was “right” about not using the previous 14s. As far as I understand, all the use cases described in OP’s article can be fulfilled with ActivityPub.
I’d love to see an article showing use cases in both AtProto and ActivityPub and showing why AtProto is the superior choice.
(To me, the hype for AT protocol vs. ActivityPub feels like the hype for DevEnv vs. Nix – I’m slightly upset that the latter isn’t taking off because the former decides to do its own thing and not contribute to the base projects. I’d love to be convinced wrong!)
Wide C2S and ActivityPods support would address most of what led to the creation of AT. Lacking that, they made AT.
The rest is revealed in the developer community. AT and AP followed similar timelines for the first year or so, then diverged.
The main thing I heard from AP devs is that it's hard even before dealing with Mastodon quirks for any meaningful connection to the AP network. AP's early developer energy looks like AT's now, except AT's has been sustained for years and is only growing.
AP hasn't even managed a second conference, and that's where all the big AT stuff started at its first one. For example: Streamplace was new and awkward to use last year. This year, it was the official streaming platform with three simultaneous streams and had integration with the official ticketing system. I can't even list all the AT platforms people used to coordinate, trade info, etc during the conference. None of them had to deal with a clunky API since it's all JSON in a standard format on your PDS through a standard interface.
This is the best question, because my gut is that "feature" that it touts over AP is much more a dangerous bug.
This is "take it with you."
What "take it with you" does in the ATProto way shores up and makes more robust the permanence of what you post. Sounds good, but also potentially harmful in terms of surveillance et al.
The ActivityPub approach is less robust and theres more room for deletion and non-reliability. Which in some ways is bad, but also helps in terms of "plausible deniability."
In other words, if you're Big Brother, you much prefer ATProto.
A system where people derive a mistaken sense of privacy seems more dangerous. AT is getting something in permissioned data that's closer to what people think they get on AP.
On one hand atproto has content-addressed storage and portable identity that AP still lacks (but could have!), on the other hand atproto is far more centralized. The data layer is decentralized but everything on top is effectively centralized. Phrases like "practical decentralization" and "credible exit" are used to describe this design.
I might be being cynical but I think I've seen this story play out before. Did Bluesky genuinely believe that AP wouldn't work for their use-case, or did they want to own the protocol?