Fix Pleroma’s unlisted posts

Oneric commented

2025-03-18 00:30:41 +00:00

Member

Two versions to pick from: either specifically tailored towards Pleroma’s unlisted posts or generally copying fields from the object as the one source of truth.
The latter should™ be safe and all good in theory and is what already effectively happens for fetched objects.

If you never encountered this: Pleroma’s unlisted posts (sometimes? not sure if its just from their reply MRF and/xor deliberate unlisted posts) end up being treated as followers-only in the API — except for those who are actually addressed due to a desync between object and Create activity addressing fields. (We use activity fields for access perm checks, but if access is granted apparently then object fields for assessing the visibility level...)
See the Pleroma issue linked in commit description which has been open for half a year

I actually basically never see this on my own instance (since when posts get fetched to fill threads rather than actively delivered to the inbox, only the Create addressing fields never show up at all), so I can't confirm it works in practice, but it seems straightforward enough

Two versions to pick from: either specifically tailored towards Pleroma’s unlisted posts or generally copying fields from the object as the one source of truth. The latter should™ be safe and all good in theory and is what already effectively happens for fetched objects. If you never encountered this: Pleroma’s unlisted posts (sometimes? not sure if its just from their reply MRF and/xor deliberate unlisted posts) end up being treated as followers-only in the API — except for those who are actually addressed due to a desync between object and Create activity addressing fields. *(We use activity fields for access perm checks, but if access is granted apparently then object fields for assessing the visibility level...)* See the Pleroma issue linked in commit description which has been open for half a year I actually basically never see this on my own instance *(since when posts get fetched to fill threads rather than actively delivered to the inbox, only the Create addressing fields never show up at all)*, so I can't confirm it works in practice, but it seems straightforward enough

Oneric added 2 commits 2025-03-18 00:30:42 +00:00

federation/in: fix activity addressing of Pleroma unlisted cdf576b951

While the object itself has the expected adressing for an
"unlisted" post, we always use the Create activity’s
adressing fields for permission checks.

To avoid unintended effects on legacy objects
we will continue to use the activity for access perm checks,
but fix its addressing fields based on its object data.

Ref: https://git.pleroma.social/pleroma/pleroma/-/issues/3323

federation/in: always copy object addressing into its Create activity

ci/woodpecker/pr/lint Pipeline was successful

Details

ci/woodpecker/pr/test/2 Pipeline was successful

Details

ci/woodpecker/pr/test/1 Pipeline was successful

Details

ci/woodpecker/pr/build-arm64 Pipeline was successful

Details

ci/woodpecker/pr/build-amd64 Pipeline was successful

Details

ci/woodpecker/pr/docs Pipeline was successful

Details

0abe01be2e

Since we later only consider the Create activity for
access permission checks, but the semantically more
sensible set of fields are the object’s.

Changing the check itself to use the object may have unintended
consequences on already existing legacy posts as the old code
which processed it when it arrived may have never considered
effects on the objects addressing fields.

Oneric commented

2025-03-21 15:29:55 +00:00

Author

Member

Alright, I can confirm now it isn’t just the reply MRF, though the symptoms differ for top-level posts.
For the latter the post will still be visible as per object addressing to all relevant partys via MastoAPI, but since the Create activity doesn't address public scope it gets omitted from search results etc. This too should be fixed by this patch

I haven’t looked into how exactly this difference comes to be, but faintly remember something about the activity_visibility database function traversing parent posts (via Create activities), so it seems likely this is a inconsistence between access checks for top-lvel and reply posts

Either way, while this means eventually fixing legacy posts via db migration will be harder, existing code seemingly already assuming the addressing always matches just serves as a further argument to copy object addressing to the Create activity upon receipt

Alright, I can confirm now it isn’t just the reply MRF, though the symptoms differ for top-level posts. For the latter the post will still be visible as per object addressing to all relevant partys via MastoAPI, but since the Create activity doesn't address public scope it gets omitted from search results etc. This too should be fixed by this patch I haven’t looked into how exactly this difference comes to be, but faintly remember something about the activity_visibility database function traversing parent posts (via `Create` activities), so it seems likely this is a inconsistence between access checks for top-lvel and reply posts Either way, while this means eventually fixing legacy posts via db migration will be harder, existing code seemingly already assuming the addressing always matches just serves as a further argument to copy object addressing to the Create activity upon receipt

norm referenced this pull request from a commit

2025-03-23 19:11:40 +00:00

Merge remote-tracking branch 'oneric/pleroma_unlisted' into akko.wtf

floatingghost commented

2025-03-31 10:39:41 +00:00

Owner

yea this seems sensible, i think it's safe to copy from object upwards... like it wouldn't make sense for the addressed user set to be disjoint between the create and the object would it? hm

i thiiiink this is ok

yea this seems sensible, i _think_ it's safe to copy from object upwards... like it wouldn't make sense for the addressed user set to be disjoint between the create and the object would it? hm i thiiiink this is ok

Oneric commented

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

Author

Member

since that’s already happening for the same kind of post if it’s fetched instead of received, this should be safe for anything new, yeah

My only concern here and the reason this modifies incoming posts instead of changing our (apparently multiple?) access checks to always use the object is about stuff already saved in the database. Who knows what ancient Pleroma from N years ago did to those addressing fields...

Btw, since this is now being tested on akko.wtf I can confirm it works as intended in the real world

since that’s already happening for the same kind of post if it’s fetched instead of received, this should be safe for anything new, yeah My only concern here and the reason this modifies incoming posts instead of changing our (apparently multiple?) access checks to always use the object is about stuff already saved in the database. Who knows what ancient Pleroma from N years ago did to those addressing fields... Btw, since this is now being tested on akko.wtf I can confirm it works as intended in the real world

ci/woodpecker/pr/lint Pipeline was successful

Details

ci/woodpecker/pr/test/2 Pipeline was successful

Details

ci/woodpecker/pr/test/1 Pipeline was successful

Details

ci/woodpecker/pr/build-arm64 Pipeline was successful

Details

ci/woodpecker/pr/build-amd64 Pipeline was successful

Details

ci/woodpecker/pr/docs Pipeline was successful

Details

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u pleroma_unlisted:Oneric-pleroma_unlisted

git checkout Oneric-pleroma_unlisted

Rows
Columns

Fix Pleroma’s unlisted posts #885

Checkout