Open evanp opened 5 days ago
I think the best next step here is to define an endpoint that is only for delivering to all addressees at once. Implementers that don't want to receive a firehose to sharedInbox
can skip it, and implement to the multipleAddresseeInbox
instead.
This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic. Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.
There are some related paths forward here:
sharedInbox
endpoints" behavior. This effectively makes an errata from MAY to SHOULD NOT.sharedInbox
endpoint if a server is not willing or able to handle additional traffic. This is essentially keeping the spec behavior as-is, but giving guidance on dealing with its effects.
inbox
and it "owns" or "manages" its users, where activities sent to this singular inbox
get routed internally to those users based on certain criteria. (Most likely, this would require a mechanism to signal that users are being hosted by a service.)
ActivityPub says in section 7.1.3:
This can have the effect that servers which implement
sharedInbox
endpoints to reduce traffic will get much, much more traffic from public posts of popular servers.The mechanism for allowing delivery of an activity to all addressees on a single server should be separate from the mechanism for receiving all public activities from a remote server. Combining the two takes a network optimization and make it into a firehose; the exact opposite effect than intended.