Today I coded something I've been dreaming about for many months - a solution to the #ActivityPub scaling problem.
The problem is that if 20 people cast 5 votes and those votes are federated to 500 servers, the instance hosting the community needs to do 20 * 5 * 500 = 50,000 network requests.
The solution is to bundle the activity up into chunks. I describe the solution and how #PieFed does it here https://peertube.wtf/w/v5aWpxjS2P4pJSn62a2AYG (probably only of interest to developers).
Brilliant concept, but doesn't match our more conversational use (every object and audience may be different).
But that isn't to say the idea won't work for us, just the implementation. It could work if your "batch" was an ActivityPub collection of queued activities. Not a paged collection, just a collection with each queued activity embedded as an item. In fact, it could work incredibly well. For our conversation containers, we end up sending two activities to every destination as we don't know which they'll accept. We could instead send both at once. The only thing it doesn't help with is RFC9421 double-knocking - which requires separate HTTP transaction. But if all your activities were signed objects (FEP-8b32) - you wouldn't need to verify the HTTP transaction. Then you could just send collections to servers of everything that's queued for them (maybe restricting to some empirically derived maximum number of requests to be polite) and reduce your delivery loading by orders of magnitude. Win-win for everybody. The spec would be pretty simple - if you receive a collection in the inbox or outbox with full activities as items, verify the sender and then loop through and deliver the items.
Would still be nice to have queueing on the inbound fetch side - but that's a battle for another day.
A space for Bonfire maintainers and contributors to communicate
