From 1e0d4ce77522e2fceb36610e2bdc3bfe600a948c Mon Sep 17 00:00:00 2001 From: trwnh Date: Tue, 1 Oct 2024 16:13:21 +0000 Subject: [PATCH] Add FEP-0499 for multibox, fix some examples in 888d (#399) still can't create a FEP topic on socialhub in the FEP category Reviewed-on: https://codeberg.org/fediverse/fep/pulls/399 Co-authored-by: trwnh Co-committed-by: trwnh --- fep/0499/context.jsonld | 8 ++ fep/0499/fep-0499.md | 142 +++++++++++++++++++++++++++++++++ fep/888d/exampleA/exampleA.rdf | 31 ++++++- fep/888d/exampleB/exampleB.rdf | 13 +++ 4 files changed, 190 insertions(+), 4 deletions(-) create mode 100644 fep/0499/context.jsonld create mode 100644 fep/0499/fep-0499.md diff --git a/fep/0499/context.jsonld b/fep/0499/context.jsonld new file mode 100644 index 0000000..911bfcc --- /dev/null +++ b/fep/0499/context.jsonld @@ -0,0 +1,8 @@ +{ + "@context": { + "multibox": { + "@id": "https://w3id.org/fep/0499#multibox", + "@type": "@id" + } + } +} \ No newline at end of file diff --git a/fep/0499/fep-0499.md b/fep/0499/fep-0499.md new file mode 100644 index 0000000..f2f1ce4 --- /dev/null +++ b/fep/0499/fep-0499.md @@ -0,0 +1,142 @@ +--- +slug: "0499" +authors: a +status: DRAFT +dateReceived: 2024-09-30 +discussionsTo: https://socialhub.activitypub.rocks/t/fep-0499-delivering-to-multiple-inboxes-with-a-multibox-endpoint/4586 +--- +# FEP-0499: Delivering to multiple inboxes with a multibox endpoint + + +## 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. + +## Motivation + +(This section is non-normative.) + +sharedInbox allows servers to reduce network traffic when delivering Public activities to multiple recipients, but it doesn't work when delivering to collections of actors, or when delivering to private audiences using bto or bcc. 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 (or at least the local subset of its contents). In the common case of delivering activities addressing followers collections to a sharedInbox endpoint, then the remote server must first recognize that this collection id is specifically a followers collection, and then guess which local actors are following that activity's actor. This is prone to issues and can also have disastrous outcomes when follower state drifts out of sync. + +We can eliminate the dependency on shared follower state and allow for delivery of non-Public activities by introducing a new endpoint that likewise allows delivering to multiple inboxes, but without requiring the remote server to know anything. + +## Prior art + +(This section is non-normative.) + +There are various advantages described in the original [multibox][multibox] proposal: + +> Shared Inbox provides the ability for server to server communication traffic to be reduced from R requests, where R is the number of recipients, to a single HTTP request. This is a desirable property as it reduces the amount of HTTP round trips for both the sender and receiver. Unfortunately the design of Shared Inboxes as described in the ActivityPub specification makes it very easy for a spammer to abuse the system by not requiring explicit delivery recipients. We propose an alternative to Shared Inbox called MultiBox that keeps the desirable properties of Shared Inbox while protecting against scenarios in which the sender uses Shared Inbox to "spam" a server. +> +> Like Shared Inbox, MultiBox consists of a single HTTP endpoint for multiple Actors. Unlike Shared Inbox, in a MultiBox request, each recipient is explicitly listed by Inbox, requiring both the knowledge of the Actor and a corresponding Inbox for that actor. This information is transmitted through the use of an HTTP header Audience where each Inbox is listed using comma separated values. +> +> This has two advantages over Shared Inbox. Used on its own, it eliminates the vulnerability mentioned previously whereby recipients to a message do not need to be listed. If this proposal is adopted alongside the Object-Capabilities Based Inbox proposal (4.5), the advantages multiply as we also gain the ability to appropriately filter incoming messages according to the criteria set out by the specific Inboxes, as well as letting us know the origin of each Inbox. +> +> For the sender, the additional computing resources required to send a MultiBox request are minimal, but doing so would make mass-messages expensive for senders wishing to abuse the system. +> +> One open question on this proposal is that if we use the HTTP header Audience to store the list of recipients, this may result in a limitation. HTTP header sizes are not explicitly capped at the protocol level but implementations often cap them at different lengths- 4Kb for the Nginx web server or 8Kb for Apache. +> +> This would limit the number of per message recipients, though this limitation would rarely be reached. An alternative to this proposal would be a new MultiBox object encapsulating the Audience field and the ~Activity. + +## Proposal + +(This section is non-normative.) + +This FEP uses the "alternative" approach of putting inboxes in the body of the POST request, instead of using an HTTP header. Whereas headers are limited to possibly as low as 4Kb by default, the limit on POST request bodies is usually much higher; Nginx by default uses a 1MB limit for POST requests. This is the difference between 4000 characters versus 1 million characters. + +## Specification + +Actors MAY have a `multibox` endpoint which is available for efficient delivery of activities to multiple inboxes on the same domain. + +A server MAY reduce the number of delivery requests by identifying all recipients which share the same `multibox` who would otherwise be delivered to individually, and deliver an activity of the following form to their shared `multibox` endpoint: + +- The type MUST be `Add`. +- The `object` MUST be the activity being delivered. +- The `target` MUST be all inboxes being delivered to. + +Upon receipt of such an activity, the receiving server MUST add the activity in `object` into all local inboxes specified in `target`, although it MAY filter delivery to certain inboxes according to implementation-specific rules (for example, spam filtering). + +### Examples + +(This section is non-normative.) + +Discovering the multibox endpoint: + +```json +{ + "@context": [ + "https://www.w3.org/ns/activitystreams", + "https://w3id.org/fep/0499" + ], + "id": "https://remote.example/actors/af4c8205cd81", + "type": "Person", + "name": "Alice P. Hacker", + "inbox": "https://remote.example/inboxes/fbb433c8e6c4", + "endpoints": { + "multibox": "https://remote.example/multibox" + } +} +``` + +Alternatively, without a context declaration: + +```json +{ + "@context": "https://www.w3.org/ns/activitystreams", + "id": "https://remote.example/actors/af4c8205cd81", + "type": "Person", + "name": "Alice P. Hacker", + "inbox": "https://remote.example/inboxes/fbb433c8e6c4", + "endpoints": { + "https://w3id.org/fep/0499#multibox": {"id": "https://remote.example/multibox"} + } +} +``` + +Delivering to the multibox endpoint: + +```http +POST /multibox HTTP/1.1 +Host: remote.example +Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams" + +{ + "@context": "https://www.w3.org/ns/activitystreams", + "type": "Add", + "object": "https://example.com/some-activity", + "target": [ + "https://remote.example/inboxes/fbb433c8e6c4", + "https://remote.example/inboxes/d21f509146e5", + "https://remote.example/inboxes/68a7453f79e4", + "https://remote.example/inboxes/655216a0be07", + "https://remote.example/inboxes/84907eff485d", + ] +} +``` + +## Terms defined + +
+

multibox

+
+
URI
+
https://w3id.org/fep/0499#multibox +
+
Comment
+
An optional endpoint used for wide delivery of activities to multiple inboxes.
+
+
+ +## References + +- Christine Lemmer Webber, Jessica Tallon, [ActivityPub][ActivityPub], 2018 +- Christine Lemmer Webber, [Rebooting the Web of Trust 9: Keeping Unwanted Messages off the Fediverse > Proposed Suggestions > MultiBox][multibox], 2020 + +[ActivityPub]: https://www.w3.org/TR/activitypub/ +[multibox]: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/ap-unwanted-messages.md#multibox + +## Copyright + +CC0 1.0 Universal (CC0 1.0) Public Domain Dedication + +To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work. diff --git a/fep/888d/exampleA/exampleA.rdf b/fep/888d/exampleA/exampleA.rdf index 4c7928c..6b12409 100644 --- a/fep/888d/exampleA/exampleA.rdf +++ b/fep/888d/exampleA/exampleA.rdf @@ -3,11 +3,34 @@ xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> - - exampleB - A property that links to another node on the graph (for example, another object) + + exampleA + A property with some literal value (string, boolean, integer) - + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/fep/888d/exampleB/exampleB.rdf b/fep/888d/exampleB/exampleB.rdf index e69de29..4c7928c 100644 --- a/fep/888d/exampleB/exampleB.rdf +++ b/fep/888d/exampleB/exampleB.rdf @@ -0,0 +1,13 @@ + + + + + exampleB + A property that links to another node on the graph (for example, another object) + + + + + \ No newline at end of file