Federate user profile background #682
No reviewers
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
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#682
Loading…
Reference in a new issue
No description provided.
Delete branch "Oneric/akkoma:background-federation"
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?
The property existed for ages and was publicly visible via API, but not federate nor shown to others in our own frontend.
Recently Sharkey added support for profile backgrounds and immediately made them federate and be displayed to others. This uses the same AP field as Sharkey here which should make it interoperable both ways out-of-the-box.
Ref.:
Sharkey@4e643976I have no frontend patch (yet), but even so this is still useful as it will start to gather remote background URLs so more stuff is visible once the FE is patched and already immediately should allow Sharkey users to see backgrounds of Akkoma users (albeit I only tested the Sharkey→Akkoma direction in the real world).
Also it turns out there’s an oldfeature request for this, so this will also fix #290
patch looks ok at first glance - but this will absolutely need a new preference to not show other people's backgrounds (and probably amending the MRF simple to strip backgrounds from some instances) to avoid abuse of the field
891b99d6f1to4ff7cc9c95yep, adding a frontend config (once the FE can show it at all) was the plan
oh yeah, good call. I was at first thinking it might make sense to tie this to
media_removaland (depending on a boolean toggle)media_nsfw— but then I noticed avatars and banners already have dedicated config lists each and it’d be weird to only tie backgrounds to something else.Pushed a SimplePolicy extension which basically just copy-pastas the existing avatar and banner logic for
backgroundUrl.(And added Changelog entries to both commits)
EDIT: ofc I forgot
mix formatagain °~° — oh well its applied now4ff7cc9c95to4c223ac5a14c223ac5a1to219d2d8893@ -112,6 +112,8 @@ defmodule Pleroma.Web.ActivityPub.UserView do}|> Map.merge(maybe_make_image(&User.avatar_url/2, "icon", user))|> Map.merge(maybe_make_image(&User.banner_url/2, "image", user))# Yes, the key is named ...Url eventhough it is a whole 'Image' objecthmmm, on closer inspection maybe we can do something about this
we've had situations like this before when dealing with quoteUrl - where we use a more coherent internal key and rewrite when other people throw us weird names like this
i guess you've used this for compatibility, which makes it hard.
i'll let it slide for now since we use a decent database key for it, but something to bear in mind
yeah, if we use a different name in the Activity Pub view, Sharkey instances won’t be able to read backgrounds from Akkoma.
Since afaik Sharkey is the only other implementation, I guess if you want I could ask on the Sharkey tracker whether they’re willing to deal with a property rename and its added work
But also:
iinm unlike most other objects users don’t get their whole AP object shoved into the database, so
user.backgroundalready is the only internal representation andbackgroundUrlis only used when processing/creating AP objects from/for remote instancesCreating and parsing the field with a more sensible name and rewriting its name for both in- and outgoing messages in
transmogrifier.eximho doesn’t make much sense.(force-pushed to rebase and resolve the changelog conflict)
219d2d8893toe99e2407f3yea seems good to me, let's keep an eye on if anyone else implements this, and if they do maybe we can go for standardisation
for now it's ok, thanks!