Oneric 2b885288fa ap: don't require explicit addressing of personal-inbox owners ... This requirement was originally added together with splicing the inbox owner into the non b* addressing fields to make bcc transports work in https://git.pleroma.social/pleroma/pleroma/-/merge_requests/390. Later on this was relaxed to always allow deliveries devoid of any addressing at all in f6cb963df2 and always allow deliveries from actors the owner is following in 750b369d04 to fix interop issues with Mastodon and Honk respectively. The justification for both the filtering and splicing comes from one sentence in AP spec’s inbox section: > In general, the owner of an inbox is likely > to be able to access all of their inbox contents. While this may provide plausible justification for splicing the owner into cc, it is less clear how this requires or justifies the set of filtering rules employed here. Surveying a few other implementations no similar filtering or splicing appears to be employed. Furthermore, spec-compliant servers will strip bto/bcc _before_ delivery to remote servers, meaning any compliant bcc transport out there will NOT contain any explicit addressing of the inbox owner. Thus the addressing requirement directly opposes the goal of the original patch. Currently the requirement for the owner to be addressed once again is causing interop issues. It turns out to be the root cause of a long-standing (2+ years) bug preventing meaningful federation. Bridgy sends e.g. Follow activities and Accepts for Follows directly to the affected user’s personal inbox while solely addressing the public scope in the to field. Notably follow relations never getting established prevented the "accept if followed" allow rule to ever come into effect. To make matters worse non-addressed messages simply lead to a vague "internal server error" response being sent back which likely slowed down locating the issue. Furthermore additional issues wrt to signatures cropped up after the 500-response issues wa first reported, but they seem to have already been fixed in the meantime, possibly with the signature handling overhaul in Akkoma. Given it repeatedly caused issues, does not appear to align with common practice in the wider fedi ecosystem and apparently contradicts its original intention, simply remove the requirement. This is confirmed to fix bridgy interop. The addressing splicing actually should also add the inbox owner to bto or bcc instead of cc, but for now this is not changed and in practice bto/bcc delivery appears to be basically unused anyway.		2025-06-07 20:27:58 +02:00
..
config	remove default emoji file	2022-08-11 19:05:41 +01:00
credo/check/consistency	giant massive dep upgrade and dialyxir-found error emporium (#371)	2022-12-14 12:38:48 +00:00
fixtures	Prevent key-actor mapping poisoning and key take overs	2025-02-14 22:10:25 +01:00
instance_static	URL encode remote emoji pack names (#362)	2023-01-15 18:14:04 +00:00
mix	mix/database: add keep-followed option for object pruning	2025-05-09 23:02:25 +02:00
pleroma	ap: don't require explicit addressing of personal-inbox owners	2025-06-07 20:27:58 +02:00
support	Fix Content-Type sanitisation for emoji and local uploads	2025-03-10 19:45:26 +01:00
test_helper.exs	add a snapshot test for api prefixes	2025-02-23 16:51:48 +00:00