Content warnings

[jesopo]

I'd like to propose using a message-tag on a PRIVMSG to denote a message with a content warning.

I suggest this works by the PRIVMSG message being ROT13-encoded for backwards compatibility and the message-tag be something like @warning-title=<warning>.

GUI clients could e.g. show a "show" button next to the title which, when pressed, would ROT13-decode the content of the message and show it to the user.

[DanielOaks]

I wonder whether digging into very specific protocol changes is a bit premature. Are there any systems out there today which have interfaces or capabilities that you're thinking of? It feels like the range of protocol support for this could range anywhere from simple spoiler tags (already supported by Textual through \0x0314,14spoiler text here\0x03 (the same foreground and background colour 14 on a section of text) that simply reveals the message on hover/click, to...? I'm not sure what people consider a 'good' content warning system in the area of text comms.

What sort of interfaces are we imagining clients to implement, and users to use? And what sort of systems already exist out there that we can take inspiration from? That will help us work out the needs of the protocol.

[jesopo]

off the top of my head, Mastodon has good support for this

[jesopo]

Also I don't think \x0314,14 is good enough for this - content warnings need to be extremely explicitly accepted. a rollover or a click anywhere on the line is way too much of a risk of unintended display of the message.

[jesopo]

... just realised: rot13 is only useful for the latin alphabet. this would not be acceptable for this usecase.

[DanielOaks]

Let's talk about specific interfaces. How do you envision this being displayed, even if just as a very rough sketch? I can't really see how clients would display or show something like this (or create a content warning line to send), or what a 'warning title' would really mean, so makes it a bit difficult to reason for/against protocol specifics.

[jesopo]

GUI clients could e.g. show a "show" button next to the title which, when pressed, would ROT13-decode the content of the message and show it to the user.

<+jesopo> warning: here be dragons [ show ]

becomes

<+jesopo> warning: here be dragons [ hide ] pineapple on pizza is very good

("here be dragons" being the warning title)

[DanielOaks]

So, the main part of this is that: We want a way to mark a specific section of text inside a message as a 'spoiler' and replace it with a show/hide button. Something like that makes sense to me, outside the existing method explored by Textual.

Let's just not include the text in the message at all and put that in the c2c tag. If you want a specific format like above with the title, that can just be the message body, e.g.:

@+spoiler=23,was\sthe\sbest\sever\sI\sloved\sit :dan!user@host PRIVMSG #ircv3 :The new Spiderman movie [spoiler], yeah

Something like on getting the +spoiler tag, clients: parse out the index of the spoiler (this is very specifically a character in the message where the text "[spoiler]" appears that should be replaced with the message tag text), and parse out the text itself, then do the appropriate show/hide link, and when users click show then show the spoilered text.

[DanielOaks]

The thing is, ^ could possibly fall back to using Textual's colour method on servers that don't support message-tags, with the client displaying an appropriate warning to the user

[jesopo]

that means clients not supporting message tags won't be able to even manually decode the "hidden" text.

[Ascrod]

I think it would make more sense here to have the tag's value be the spoiler/warning label, and the message be the content. To @jesopo's point, this would allow clients that don't support the tag to still show the message.

[jesopo]

Here's an example of how Mastodon does it

[jesopo]

I think it would make more sense here to have the tag's value be the spoiler/warning label, and the message be the content. To @jesopo's point, this would allow clients that don't support the tag to still show the message.

but i would prefer it fails safe, not fails in a way that immediately puts potentially upsetting material in people's faces just because they don't support message-tags. moreover, people sending a content warned message should feel confident this wont happen.

[Herringway]

would the title be mandatory?

[DanielOaks]

So, if we are going with the text encoding idea, we can't do ROT13. What other method is well-specified, has lots of webpages where regular end-users can copy/paste the text into to reverse it, and supports the whole UTF-8 spectrum? With message breaking across multiple lines: We should advise sending clients to encode each part separately, so that users don't get a word/byte split across a boundary that they can't decode.

[Ascrod]

but i would prefer it fails safe, not fails in a way that puts potentially very bad things in people's faces just because they don't support message-tags

IMHO people should use clients that support spoilers/warnings if they don't want them to be shown by default. Another option might be to have the server modify the message for users whose clients don't support message tags, but that's still iffy because the server won't necessarily know who supports warnings and who doesn't.

[jesopo]

So, if we are going with the text encoding idea, we can't do ROT13. What other method is well-specified, has lots of webpages where regular end-users can copy/paste the text into to reverse it, and supports the whole UTF-8 spectrum? With message breaking across multiple lines: We should advise sending clients to encode each part separately, so that users don't get a word/byte split across a boundary that they can't decode.

something like https://github.com/rottytooth/rot8000 potentially

[jesopo]

but i would prefer it fails safe, not fails in a way that puts potentially very bad things in people's faces just because they don't support message-tags

IMHO people should use clients that support spoilers/warnings if they don't want them to be shown by default. Another option might be to have the server modify the message for users whose clients don't support message tags, but that's still iffy because the server won't necessarily know who supports warnings and who doesn't.

again, i want people sending content warned messages to be able to be confident they're not going to cause issues with someone seeing it automatically

[DanielOaks]

While I'm not passing judgement on the particular project, using something like rot8000 means that everybody who implements it is going to need to rewrite their own library for it from scratch. We should use something that's already widely-used out there instead, maybe something like base64 or some other method that's widely-supported and has lots of support/libs already?

[jesopo]

:+1: for base64, only concern is how much longer that makes the string - I don't have a very good grasp of how base64 works

[DanielOaks]

On the fg/bg colour hack that exists already:

So, using some special c2c tags method involving rotating/encoding text in some way that should be undone by the client: Cool. But will only work on servers that support C2C tags, so won't work on existing networks. The fg/bg hack seems like a decent fallback for the feature when on networks that don't support c2c tags, is this wrong? or should we do the fg/bg hack along with rotating the text, or something else?

[DanielOaks]

On the fg/bg colour hack: "\x0314,14 fallback won't work for +c chans", which sorta violates our desire for spoilered text to not be readable by default. Interesting.

[trobotham]

On the fg/bg colour hack: "\x0314,14 fallback won't work for +c chans", which sorta violates our desire for spoilered text to not be readable by default. Interesting.

not sure that I like that idea anyways, modifying messages like that kind of sucks, I personally feel that they should be displayed as normal by default if you are using a non-supporting client but that is just me.

[prawnsalad]

Spoiler text comes under the realm of text styling, as it is entirely up to the client UI to decide how it should be shown. Button to reveal? Click the text to reveal? Highlight the text to reveal?

If this is being discussed, it should also include the more generalised bold/italic/underline/etc styling in the same spec.

[DanielOaks]

Replacing this issue with #33 – the requirement of a 'title' and proposed UI decisions in here has sorta overtaken the discussion of how such a feature could be implemented – that feature lays out much more simply the requirements of a feature that would hide 'spoilered' content