Sidekiq seems to be the culprit from what I've seen and read from people who've run into this issue. It gets overloaded fast if you don't have enough processing power in front of the queue. Lighter implementations apparently do something different, or are more efficient in handling their queues without whatever overhead Sidekiq adds.

One example of the chattiness is a flow where more than one person is following the same individual on another server. every single one of the people following that individual will fetch the same message from that users inbox. This means that if 10 users are following me from the same server I will not get 1 fetch, I'll get 10 fetches for the same single unchanged message. This is built into the protocol. That's a lot of throughput for something that could be much much less chatty.

Now on my single instance it's not too bad because 1. I follow maybe 40 people and 2. I have like max 10 followers. For an instance with people with high follower counts across multiple other instances it could get to be a problem fast.

Isn't that "more than once instance" rather than "more than one user"?

I think the weirdness is with Bluesky all that cost is still there but it's now handled by a small group of massive megacorps which is a real tangible benefit to self-hosters but you could have that on top of AP by running your service off what would essentially be a massive global cache of AP content which is what the indexer is.

Yes, I edited my comment too be more clear and. I shouldn't have referred to it as fetch because it's actually push.

I should note that as a protocol I suspect that ATProto is less chatty which does translate to reduced costs. It adds features on top that some may or may not want which increase costs in other ways but only for the people who want to utilize those features. It's not exactly an Apples to Apples comparison.

> This is built into the protocol.

I haven't implemented AP from scratch so I may be missing technical details precluding this, but it sounds like it may at least partially be covered by https://www.w3.org/TR/activitypub/#shared-inbox-delivery

... in which case it may be an implementation issue?

Mind you, there is liberal use of "MAY" there which I find is always a problem with specs: that would likely lead to mandatory chattiness of outgoing requests if you're federated with a lot of instances without shared inbox support, but should at least solve for incoming.

In theory it would help. In practice since a server can't rely on this it probably devolves to just ignoring that feature.

There can be an interrogation endpoint/message of supported versions/extensions to the base protocol, that's a very normal thing. If it supports bundled delivery, send a single bundle if not send them all individually.

Yep, And I'm sure there are some instances that do exactly that. But in a distributed protocol you only get the benefit if both sides of a given interaction support the optimization. For something in the spec that is optional you can't rely on it and you aren't forced to implement it so it's not irrational to just ignore it. Which typically means you only get occasional marginal benefit.

i mean it depends. The vast majority of fedi traffic is mastodon. Add it to mastodon it makes an impression and a real difference. At first mastodon to mastodon comms, but others will take notice, it will find it's way into libraries then it's smooth sailing.

> Which typically means you only get occasional marginal benefit.

Which is why most browser-server communitcation is still limited by HTTP/1.0.

Except it isn't. That's not how this works out when there are benefits to all participants to implement these optimizations.

Instead of baselessly speculating, you could find out that nearly every server uses shared inbox.

I'm not to into the weeds of activitypub yet but in my head it seems like you could add some things to the protocol to optimize this.

1. server with the sender constructs a map by receiving server that contains a list of all users on that server who should receive the message.

2. sending server iterates the map. If the receiving server has multiple recipients do a check to see if the receiving server supports this kind of 'bundled' delivery.

  2a. If so send the message once with a list of receivers.

  2b. receiving service processes the one message and delivers it to all the users.

3. If not sending server sends it in the traditional way, multiple pushes.