XSF Discussion - 2019-10-26

we dont have an extension yet, that marks a messages as NSFW or?

and with messages i mean a message that transports media

could be as easy as <nsfw/>

lovetox in Movim the Pubsub atom item that have the nsfw category are seen as a specific category

yeah i thought more of stuff like MUCs

people tell me they dont want to join MUCs at work, because people could post NSFW content

that’s always a risk, isn’t it?

is this about text content or other content?

Mostly other content I guess, text content is only an issue when fairly close and focused

lovetox: https://xmpp.org/extensions/xep-0382.html seems relevant

its mostly about pictures obviously

lovetox: does gajim auto-download content in public channels? If not there wouldn't really be an issue anyways because people could just not download content at work

nsfw content is not limited to public channels

and of course there would be an issue

or do you know if a link is nsfw content before you click it?

relying on senders to annotate correctly is going to fail

yeah probably

so not solveable i guess

so instead of providing a false sense of security by having it work in some cases, I suggest to have an easy "do not show inline media" switch

either you show no picture

or all

which should also affect media in the backlog

and bonus points for allowing to couple that switch to a certain presence state

(e.g. a "At work" presence :))

yeah sure :D

(or, also very relevant, an "On mobile data" presence :))

or i open a feature request at prosody, they should install some picture AI scanning

and add the nsfw tag

make an external http upload component that does that and returns some classifiers in headers that you can get with HTTP HEAD

no need to drag prosody devs into it :P

there was also that thing with the tiny thumbnail embedded in a header

Relevant: https://modules.prosody.im/mod_muc_media_metadata.html

I was going to add blurhash support to share.php

Til about blurhash. That's pretty cool

Indeed.

https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-multi > If the service does not allow multiple subscriptions for the same entity and it receives an additional subscription request, the service MUST return the current subscription state (as if the subscription was just approved). What is 'current' in this context? The subscriptions state of the first subscription, or the subscription state as updated by the last?