[bug] Detecting public posts is being mishandled #670
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#670
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Your setup
Docker
Extra details
No response
Version
No response
PostgreSQL version
No response
What were you trying to do?
Federate a post to akkoma that is Public. To federate with akkoma, one needs to use "https://www.w3.org/ns/activitystreams#Public" instead of "as:Public" or "Public". My understanding from the Note at https://www.w3.org/TR/activitypub/#public-addressing is that ActivityPub requires all three to valid.
This means that your public post detecting needs to also check for "as:Public" and "Public"
What did you expect to happen?
No response
What actually happened?
No response
Logs
Severity
I cannot use it as easily as I'd like
Have you searched for this issue?
This logic that it can only be one thing is littered everywhere; from elixir code to SQL with the string
https://www.w3.org/ns/activitystreams#Public
; there is a constant which is exported fromConstants.as_public
which then spreads the single-ness check.It feels like, a migration edit would solve postgres classifying; using
RIGHT(field, 6) == "Public"
; while broader than the spec; I think it still allows for a single operation to verify; and should be trivial to express s a shared predicate function which returns a boolean, simplifying the usage everywhere.would simplify to
which could further simplify (taking into account Elixir and Erlang lack of variadic arguments)
so that isPublic then knows, or encodes that it expects a series of things to check and is doing an is/areAny check (default return false, loop over results if one is public then return
true
.imho it makes things more straightforward if there’s only a single representation of public scope internally, thus it would make sense to normalise the other ones when received.
The below can be ignored see next post
should fix the issue for new objects I think, but since I don’t run an actual (federating) instance I can for now only confirm for sure that it builds. If anyone can test this feel free to open a PR with this yourself, but if you prefer you can also let me know you successfully tested the patch and I’ll handle the PR.As for already received objects, this query should be able to fix them and seems to work in simple tests with manually edited objects:
This will have to check all stored objects, so idk if it makes sense to force this onto all admins with a migration, some (many?) prune old remote objects regularly anyway), but it’d presumably be simple to turn this into one.
I realised there are still tests for federation and I can use those to test the change. The first draft from above was placed to late and had some other runtime issues. A fixed up patch, adding a new test and passing
mix test
can be found at: #675This issue is currently preventing implementations running full json-ld (iceshrimp.net, takahe, ...) from federating with akkoma. The compaction step at the end of JSON-LD processing replaces
https://www.w3.org/ns/activitystreams#Public
withas:Public
.