This FEP introduces a server-wide endpoint for delivering activities to multiple inboxes. sharedInbox currently allows for doing this, but it requires the remote server to know how to deliver the activity based on its addressing properties. However, the remote server might not know how to deliver the activity to private recipients, or recipients within a collection. The multibox endpoint removes this knowledge requirement from the receiving server and instead makes the sending server responsible for marking inboxes to explicitly deliver to.
interesting, i hadn’t considered this angle! i was too focused on the bit where it preserves privacy in deliveries to notice that it also has the benefit of allowing multiple delivery.
my only concern is that it might make error signaling more difficult, because you’d need to be more specific about which part of the delivery failed (expressed as combinations of object activities and target inboxes? like “delivering activity 1 failed to inboxes b and c, activity 2 failed to inbox a, and activity 3 also failed inbox a”). but error signaling is still not defined or used anywhere so there’s room to work out something more robust than just sending a single Reject
Incidentally, that right there is the MAIN problem with any sort of “batch” API.
Whenever I hear “oh we need a batch API, for performance reasons” I immediately think 1) they clearly are doing parallelizing wrong, and 2) they have not thought through how hellish error reporting is for batch anything.
Fediverse services don’t provide detailed error reports because activities are processed asynchronously. Usually servers only report http signature verification errors (401), blocks (403), and deleted inboxes (404/410). Multibox would make reporting of deleted inboxes more difficult, but I think this is not a big loss, because shared inbox also lacks this feature.
If an activity is addressed to a collection and that activity is delivered to a remote sharedInbox endpoint, then this introduces a requirement for the remote server to know the contents of the collection
Does it really introduce that requirement though? Lemmy blindly sends activities to communities all the time, not knowing which actors are in the community.
If you deliver this activity to sharedInbox of site2.example, then the remote server needs to know the contents of <https://site1.example/actor/followers>, which it cannot know because the collection might be private to the site1 actor. If it doesn’t have this knowledge, it cannot deliver the activity. Who are the followers? Maybe you can guess based on your local state, but your local state might not be synced with the authoritative representation at site1.
Now let’s use a collection that isn’t the followers collection:
actor: <https://site1.example/some-actor>
type: Create
object:
- type: Note
content: "This post is for a private audience"
to: <https://site1.example/some-collection>
You have no possible way of guessing what this collection contains. How do you process it for further delivery?
The IRI has changed from https://w3id.org/fep/0499#multibox to https://w3id.org/fep/0499/multibox. (I don’t know why I did it the other way around in the first place, but it’s “fixed” now.)
I consider this more or less “done” now, it’s just waiting for implementers before possibly going FINAL.