FEP-0499: Delivering to multiple inboxes with a multibox endpoint

fep/fep/0499/fep-0499.md at main - fediverse/fep - Codeberg.org currently in PR #399 - Add FEP-0499 for multibox, fix some examples in 888d - fediverse/fep - Codeberg.org

Summary

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.

2 Likes

To clarify, you can reference the activity by id or embed it inline. This FEP doesn’t affect that.

Added an example to clarify this #405 - [0499] Add example for embedded activity delivery - fediverse/fep - Codeberg.org

Nice FEP, I may implement it at some point.

You can also send activities in batches by making object an array.

1 Like

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

2 Likes

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.

I don’t understand the motivation for this FEP.

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.

Yes, here’s a basic example:

actor: <https://site1.example/some-actor>
type: Create
object:
  - type: Note
    content: "Hello followers"
to: <https://site1.example/some-actor/followers>

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?

1 Like