ActivityPub's PublicInbox is used to route all messages. This works for "small-world networking" where you're in a tight-knit community exchanging messages with known or friend-of-friend actors, but doesn't work well for "big-world networking" with folks you don't know and don't necessarily want to share all or even most of your messages with (a pretty big pain point right now in the Fediverse.)

ATProtocol claims to differentiate between these cases by introducing the concept of indexers which can apply different algorithms to order feeds, but it's unclear to me how exactly that will work.

This is not right. First of all, what do you mean by "PublicInbox"? Are you referring to the optional sharedInbox attribute, which allows delivering a payload to a whole server at once instead of iterating over the personal inbox of every actor on the server? Or are you referring to the inbox in general? The inbox is just a mechanism to deliver a payload from point A to point B. It is in fact used to receive messages from folks you don't know, but there is no obligation to share all or even most of your messages with anyone in particular. You can deliver posts to your followers, but you don't have to, protocol-wise, and you can choose, person by person, who to deliver to. The concept of indexers doesn't seem foreign to ActivityPub either. PeerTube runs sepia.search, which is exactly that kind of indexer that powers search for their video platform.

Sorry, yeah I meant "sharedInbox" vs "PublicInbox". My understanding is that the AP client (assuming you aren't using C2S ActivityPub) sends messages to your AP server which then either sends messages to the sharedInbox of the destination AP instance or directly to the inbox at that other AP instance. I realize the visibility of each message is up to the discretion of each AP implementation but as practiced now, messages are often seen by multiple parties before getting to the final destination.

As far as indexers are concerned, I realize it's entirely possible to use indexers with AP. It's wholly unclear to me how AT Protocol is using indexers or scoping any of their objects so I'm not sure it's worth belaboring the point.

So they can be the center of it and control it, of course.

How could one "control" a federation protocol though?

Consider how worried people are about Google Chrome's browser market share, and how Google is increasingly able to dictate details of the web unilaterally. The Web is made of standardized protocols, but Google has significant control over it.

Consider the state of email, a standardized protocol, where Gmail is dominant, and anything that can't deliver to Gmail is practically irrelevant, no matter whether it follows the protocol.

Now consider Bluesky. If Twitter supports the AT protocol early, it would be by far the largest implementation, meaning that Twitter practically controls it. It would be like Gmail for email, except there are no other options to begin with. If Twitter does not support AT protocol early, then AT protocol will be irrelevant, and other networks like the ActivityPub Fediverse will continue to outpace it.

By being the gatekeeper of its evolution of course.

that's an interesting question, I think spam is part of how... for a proper answer I would look at how SMTP has evolved over time.

SMTP started without proper authentication so anyone could spoof anyone's address. Most of those extensions try to fix this. But ActivityPub, for example, has authentication built-in from the beginning in the form of HTTP signatures.

There are some technical differences like AT storing all content in a Merkle tree so it's easier to replicate, check integrity, etc. It's not clear to me how valuable these features will be. Perhaps the biggest difference is that they've introduced a username->server indirection layer.

How would you ever handle deleting posts or removing content if there's a Merkle tree that gets invalidated for every deleted post you send?

The root gets updated with each update, and the diff gets exchanged as part of the sync protocol. Deleting and purging is no different than other federated protocols in that regard.

Rewriting the user's entire database on each delete sounds like it might become a problem. Especially as some users like to automatically delete old posts on a regular basis.

It’s literally the dumbest idea ever.

Why use a merkle tree if you need to give users the ability to remove stuff?

Just store it in some other struct and have each message signed by the user. Let them add and remove messages at will.

ActivityPub isn’t a great protocol and ties your identity to your homeserver.

ActivityPub, the protocol, doesn't actually tie your identity to your homeserver. Webfinger (which is the protocol responsible for the username@domain addresses) is not part of it. In fact, even Webfinger doesn't actually "tie" your identity to your homeserver -- the fact that your identity is "tied" is an implementation detail in Mastodon and other currently popular fediverse software.

That’s a de-facto standard, so it’s safe to say that, given that all major AP implementations do so, your identity is tied to your homeserver.

The tyranny of the installed base is real. What you choose to ship basically defines what everyone else can do with AP in practice.

I think it’s a shame that Mastodon got a million fuzzy blinky UI features before the (still missing) BYOdomain support, given that everyone in that space links permanent identity to user+domain.

I don’t see that changing. Do you? It seems everyone has settled on this, just like email, and that the solution is to just use a domain that you control for your identity (just like email).

"Fuzzy blinky UI features" is what people actually care about though. You can have all the theoretical bells and whistles in the protocol but if you don't have a flagship application that people can use for their everyday needs, nobody is going to care. The fact of the matter is that "porting your account" is just a much less frequent need than literally anything else that people will come across in their day to day use, and the fact that you can move to another account in the fediverse without losing your followers is good enough for most. Of course it would be nice if the old and new accounts were verbatim, not even identifiably different copies, but we're talking about synchronizing (potentially, and likely on average) multiple gigabytes of data across small hobbyist servers that also still have to serve requests from other users. Not to mention the abuseability of being able to import gigabytes of pre-recorded content like that, a spammer's boon. Worth mentioning that the account portability approach described in ATP is just "upload your backup to the other server" which in practice is going to suffer from the exact problems I am describing.