optionally blur NSFW content in lieu of placeholder image

This MR adds a new configuration setting nsfwUseBlur which uses a client-composited blur of the image or first video frame.

In the case of images, it also adds placeholder text that explains that the content is sensitive. For videos, the play icon is used.

In the event that attachment post-processing is available, such as when running on Mastodon BE or MFC Pleroma, the post-processed image will be used as the basis for the blur composition instead of the raw image or first video frame.

changed the description

why rgba if it's fully opaque?

instead of centering it with calc i'd rather center it using flex

this really should be user-configurable also since filter: blur() can

a) cause performance issues b) not work at all

there should be some logic to handle large_thumb_url, since if it's the same as url or falsy, the entire blur filter nullifies the "preload nsfw images" option since there would be no way to disable preloading, essentially.

Somewhat related to the blurhash thing that we get from mastodon.

so can we do this without css blur? I wouldn't mind replacing nsfw image with a more neutral blurred version (not all sensitive stuff is 18+ etc), while keeping nsfw image as an option since it can create personality for the instance

yeah, see https://blurha.sh/. Mastodon computes those and we could just pass them on, and have an option to generate them ourselves.

nice, finnish tech

even if we use blurred versions we should still add a black bar or placeholder image on top of it since people also use nsfw to hide spoilers, while even blurred image or partially obscured non-blurred one could still give away what content is, spoiling the... whatever it's a spoiler for.

if it's a blur hash then you can't really tell any of the content, but seeing colors could ruin some jokes (everyone would recognize the blurred version of tenshi eating a corndog for example) which I don't think is big enough of a reason to block it, maybe a 50% opacity or something could be enough to hide the colors of the blur.

i mean, it's not big of an improvement for most cases and it kinda ruins one of the cases

it's an improvement over "18+" which is not accurate very often, and the alternative is an altered image or just text like "content hidden". I like how the blur looks in general

idk we can always change the image to be more neutral and there's an issue to allow custom image or just text

which looks pretty boring, the major upside would be how much slicker it looks. there's also the benefit of being able to differentiate tagged images from reach other using the thumbnail, for example you might see a post with no description get repeated on your timeline, you don't know which post it is or if you've seen it already if all hiders look identical.

that's why i have filenames enabled (says he as he posts images like 14123aefe7668fease76544123.jpg from hydrus)

don't know about slick or boring tho, i'd say custom nsfw images some instances do look less boring but that's just stylistic preference.

something like this

would be a good compromise.

ability to manipulate how image is CW'd (i.e. nsfw, very nsfw, spoiler, etc) would be even better

now that i think of it it would allow instances to do something like this too

The combined version seems much too involved. The new game one is cute, but the other one nearly looks like a bug.

That's sorta how steam does spoilers.

looks pretty bad imo, blurring is a more elegant way imo. if we want to draw something extra on top of it, do it with transparencies instead of a big block. maybe even allow admins to set the NSFW image that gets drawn on top of blur which can use the alpha channel in clever ways

problem with blur is that it doesn't work well with spoilers. As you mentioned before anyone would figure it out if it's tenshi eating a corndog even at highest blur setting.

I really feel like only-blur is "form over function" solution.

that's very different to what blurhash is doing, which blurs it much much much more

also no one is saying only blur, you can still have some stuff over it, text or even an image or some semi transparent background colored block with text over it. the form of the blur does serve a function, but it'd be silly to hurt the form by blocking most of it (which could still be an admin decision)

Ok, blurhash is more or less good as long as you don't go into high numbers. Questions are:

1. are we gonna implement blurhash on clientside?
2. if blurhash is serverside how to deal if it's disabled (because i don't want any image processing on server side)
3. if we blur using css how to handle if blurring isn't supported by browser or we simply don't care about that?

1. if we do blurhash, decoding has to be done client-side
2. encoding has to be done serverside, don't think you're gonna be able to avoid any image processing forever without a custom fork
3. heavy blur in css sounds expensive, and requires the image to load first while blur hash data is only a handful of bytes that can be sent with the media object. I don't know if I'd support it at all

in any case it requires more experimentation to properly weight the benefits and drawbacks, like if the decoding is expensive then I think some alternative approach is necessary. maybe benchmarking mastodon's use of them would help

to clarify a bit, a fallback is necessary either way I think, since the hashes are federated, not created for all incoming images

i was talking about encoding, blurha.sh seem to do blurhash on clientside pretty well and we already use canvas so we could do that clientside as well instead of css blur

i would really want to avoid forking pleroma-be over minor and trivial thing as lack of "don't do any image processing on server" option

We are already doing some small, optional image processing on the backend with the exif stripping, and soon with thumbnail generation. Having another option for blurhash generation would be possible. Either way, we can expose the existing blurhashes we have from other servers soon so people can start experimenting with frontend looks.

mentioned in issue #979

mentioned in issue pleroma#2294 (closed)