Always prefer shared inbox

Oneric commented

2025-03-14 19:39:43 +00:00

Owner

The comments regarding spec requirements don't quite match the actual logic and in practice it’s fine to unconditionally prefer sharedInbox. All other surveyed implementations also unconditionally prefer shared inboxes by default.

In fact, delivery to multiple personal inboxes is bound to fail and an utter waste of resources. After the first received document was processed by the remote server, all further copies will just fail to be actually accepted into the database since the AP ID is already known.

This can greatly reduce the amount of deliveries for follower-only posts (and to a lesser degree DMs).

Messages with bcc addressing are not affected by this for now ~~(and it’s marked as WIP because i just noticed they’re handled in a different function and thus need to update the commit message)~~

For reference: there was also some discussion about his on IRC.

Force-pushed with cosmetic changes for elixir-1.18 mix format

The comments regarding spec requirements don't quite match the actual logic and in practice it’s fine to unconditionally prefer sharedInbox. All other surveyed implementations also unconditionally prefer shared inboxes by default. In fact, delivery to multiple personal inboxes is bound to fail and an utter waste of resources. After the first received document was processed by the remote server, all further copies will just fail to be actually accepted into the database since the AP ID is already known. This can greatly reduce the amount of deliveries for follower-only posts (and to a lesser degree DMs). Messages with `bcc` addressing are not affected by this for now ~~(and it’s marked as WIP because i just noticed they’re handled in a different function and thus need to update the commit message)~~ For reference: there was also some discussion about his on IRC. --- Force-pushed with cosmetic changes for elixir-1.18 `mix format`

Oneric added 2 commits 2025-03-14 19:39:44 +00:00

publisher: don't mangle between string and atom 75fda65065

Oban jobs only can have string args and there’s no reason to insist on atoms here.

Plus this used unchecked string_to_atom

federation: always try to use the shared inbox

ci/woodpecker/pr/build-amd64 Pipeline is pending approval

Details

ci/woodpecker/pr/build-arm64 Pipeline is pending approval

Details

ci/woodpecker/pr/docs Pipeline is pending approval

Details

ci/woodpecker/pr/lint Pipeline is pending approval

Details

ci/woodpecker/pr/test/1 Pipeline is pending approval

Details

ci/woodpecker/pr/test/2 Pipeline is pending approval

Details

c15dd623d5

The comments regarding spec requirements are bogus
and all other surveyed implementations also unconditionally
prefer shared inboxes by default.

In fact, delivery to multiple personal inboxes is bound to fail and an
utter waste of resources. After the first received document was
processed by the remote server, all further copies will just fail to be
actually accepted into the database since the AP ID is already known.

In theory spec requires delivery for personal inboxes for bcc/bto
delivery, howeverever this is (a) becuase spec also requires bcc/bto
fields to be stripped before delivery, which Pleroma doesn't, but in
practice makes bcc/bto unusable due to the aforementioned AP ID overlap
issue and (b) because bcc/bto is broken per spec, nobody actually uses
it except Pleroma whichas mentioned before doesn't follow spec here
anyway.
Prior to this commit personal inboxes also weren't actually enforced for
bcc/bto messages which also address public scope (e.g. as a means of a
discrete notif/ping)

Oneric force-pushed shared-inbox from c15dd623d5 to 9495a61f00

2025-03-15 00:34:34 +00:00

Compare

Oneric changed title from ~~WIP: Always prefer shared inbox~~ to Always prefer shared inbox

2025-03-15 00:34:46 +00:00

Oneric force-pushed shared-inbox from 9495a61f00 to a80444041c

2025-05-06 16:17:31 +00:00

Compare

norm commented

2025-05-08 22:33:38 +00:00

Contributor

Seems to work on akko.wtf, though I haven't noticed a significant decrease in PublisherWorker events.

floatingghost commented

2025-05-09 16:53:35 +00:00

Owner

oh so that's why sometimes you get the "AP already used in the DB" error hmmm

oh so _that's_ why sometimes you get the "AP already used in the DB" error hmmm

floatingghost merged commit fffac8bc7c into develop

2025-05-09 16:54:20 +00:00

floatingghost deleted branch shared-inbox

2025-05-09 16:54:20 +00:00

floatingghost referenced this pull request from a commit

2025-05-09 16:54:21 +00:00

Merge pull request 'Always prefer shared inbox' (#881) from Oneric/akkoma:shared-inbox into develop

Oneric commented

2025-05-09 18:34:26 +00:00

Author

Owner

duplicates being delivered appears to be the most common source ime; #886 avoids that and it seem less common for me now.

But it’s also possible to run into this when e.g. a Like and the liked post itself are both delivered near simultaneously, or a like and boost of the same post. The like/annonuce activities will end up dereferncing and trying to insert the object they act on, putting them into a race condition

duplicates being delivered appears to be the most common source ime; #886 avoids that and it seem less common for me now. But it’s also possible to run into this when e.g. a Like and the liked post itself are both delivered near simultaneously, or a like and boost of the same post. The like/annonuce activities will end up dereferncing and trying to insert the object they act on, putting them into a race condition

Rows
Columns

Always prefer shared inbox #881