Spoiler Text

[DanielOaks]

So, spoilered text is a thing that's really, really damn common out there. Every forum supports it, Reddit supports it, Mastedon supports it, and even Discord supports it. There's also been a defacto way of doing spoilers in IRC – just having the bg and fg colours be the same – that's been picked up in Textual as show-on-hover.

This issue discusses whether there's a better way to mark spoilered text that fulfils typical requirements of spoilered content:

• Content should be hidden unless the user explicitly opts to see them (such as clicking a button, hovering, or enabling some 'always show spoilers' feature in their client).
• Users should be able to perform some action to see the spoilered content.
• Should work in channels that block colours, since channels like that are somewhat common.
• Hopefully allows clients to show some rich representation of it. For example, instead of just showing the entire line blacked-out, replacing that with an explicit show/hide button as some forums handled it back in the day.
• Should work on existing servers (those that don't support c2c tags, etc), and those that do support c2c tags and the like.

Spoilered text is and has been very common in all sorts of text systems, so I don't think there's much of a case to be made that we can't discuss possible ways to support this more effectively.

---

Same Fg/Bg Colours

So this is one of the ways it's done currently. Basically, you set a block of text to have the same bg and fg colours (14 - dark grey is used for this, because clients sometimes modify or ignore the 00/01 colours, and because like half of IRC has a pure white bg and half has pure black, so it's real easy to miss text that is coloured in this way).

Upsides:

• No external utilities or similar to view it, simply highlighting the text is enough to show it.
• Works on existing servers.

Downsides:

• Does not work in channels that block colours.

---

Rot13 Text Substitution

This is another way that people represent spoilered content today. They manually change the text using a rot13 rotation utility, post it in the channel, and then receiving users need to do the same.

Upsides:

• Not visible to other users in the channel, no matter whether the chan blocks colours or not.
• Works on existing servers.

Downsides:

• Does not support text outside regular latin characters, so unicode goes through entirely as-is.
• Requires that users know that the text is rot13, and requires them to perform the conversion themselves.

---

So, those are the only two methods that currently exist to do this. Are there any new ones people can think of that do fulfill the above requirements whether the receiver does or does not support the method, and would be not-too-difficult for client authors to implement?

Some previous discussion of interest on #32

[RyanSquared]

base64 could work for regular latin characters and only has a 4/3 maximum expansion as I understand it, but is definitely harder for users to de-spoiler.

[prawnsalad]

Why can't the client decide how to hide/show the spoiler text? As long as the boundaries are marked just as with other styling, then the client itself can mask it however it pleases its user.

We shouldn't be protecting users from seeing spoilers if they are watching raw traffic logs

[DanielOaks]

Why can't the client decide how to hide/show the spoiler text? As long as the boundaries are marked just as with other styling, then the client itself can mask it however it pleases its user.

The client can. The primary requirement is "Content should be hidden unless the user explicitly acts...", which should be maintained whether the receiving client does or does not implement whatever proposed method.

We shouldn't be protecting users from seeing spoilers if they are watching raw traffic logs

I don't see this as a requirement for a spoilered text feature either, agreed.

[prawnsalad]

@DanielOaks the majority of discussion I've seen far has all been all about encoding the text in different ways. My comment was regarding this and how the only effect it will have is to mask raw traffic which is pointless. The only thing needed is to mark boundaries for clients to determine whats a spoiler.

edit: previous comment edited making this comment redundant as i typed.

[DanielOaks]

@prawnsalad I believe that encoding the text also has the side-effect of fulfilling the first requirement, i.e. that the spoilered text is hidden whether the client's software supports the spoiler mechanism or not. That's the pressing, and much more difficult issue to solve without employing a method based on that sort of thing.

[RyanSquared]

My comment was regarding this and how the only effect it will have is to mask raw traffic which is pointless.

It will help with clients that do not support the specification. Otherwise you just have the text as-is for clients that don't support the spec.

[prawnsalad]

So then if somebody wants spoiler alert, they should use a client that does so? I wouldn't want my clients to suddenly start getting scrambled text because others decide to make it awkward for me to decode it

[DanielOaks]

If we have a method that doesn't fulfill requirement 1, I don't think it's worth discussing. If the spoilered text is going to be seen and read by all users that don't use a client implementing the method, it's not a workable spoiler method.

[Ascrod]

The best proposal I've seen between the discussion on IRC and in the related issue that fills these requirements is using base64 to encode the message. It's a bit more of a pain for non-compliant users to decode than colored text, but if you have a decoding website/app/plugin handy, it's not so bad. The biggest issue would be some line length finagling that the sender's client would have to take care of.

[prawnsalad]

Just a reminder to everyone, IRCv3 specs are to be backwards compatible. If we start encoding text so that it's unreadable on older clients, it goes against everything else we do under IRCv3.

[DanielOaks]

not entirely tounge-in-cheek suggestion: base64 encoding for the text with a c2c tag like +spoiler that indicates the sent text is encoded, with a fallback to something like CTCP SPOILER for other nets? :P

[RyanSquared]

Sure, but having something that flat out doesn't work with older clients is also not backwards compatible.

[RyanSquared]

@DanielOaks that creates a reliance on the server supporting the spec as well, doesn't it?

[kythyria]

Suggest clients use colours as a fallback in channels that are -c, otherwise base64?

[RyanSquared]

I see a couple of issues with that @kythyria

• nonstandardized channel mode
• users not knowing why messages change for different channels

[DanielOaks]

@RyanSquared normally it wouldn't, but given that some servers do block unknown CTCP types then yeah, that probably wouldn't be a good solution either.

[DanielOaks]

just a reminder to everyone, -ideas issues are for discussing all sorts of proposals – ones that implementers will go after, ones that implementers won't, crazy whacky out-there ones, etc. it's clear that there is some discussion to be had around this feature (including discord very recently introducing the same thing on their side), which is why this issue exists. if some people don't think this issue is worth looking at implementing, this issue would also likely be a good place to note that (even if just as a thumbs-down on the initial comment in this issue).

[kythyria]

@RyanSquared Nonstandard I'll grant. Probably there's no agreement over whether it's +c or +C or +W or something you can only find/set by saying the magic words to chanserv.

But if you're the sender you won't see the fallback, you'll see spoilered text. If your client doesn't support spoiler tags you'll be seeing different things in different channels anyway.

[trobotham]

The server should not be obfuscating and/or modifying text sent in messages for non-ircv3 clients in any way IMO. This goes along with what @prawnsalad regarding backwards compatibility.

[DanielOaks]

Another point brought up: If some software system did do the text-modification/base64/etc, that may be a way to bypass spam filtering, which wouldn't be good.

[RyanSquared]

One idea that was brought up on IRC was to have a @+spoiler tag, then the server checks whether or not the color combo \003XX,XX where XX is a single, matching on both sides color code (as spoilers are implemented nowadays) and override +c for those specific events.

This means that servers have to be aware of incoming spoilers but it won't affect the spoiler and will actually reduce modification of the outgoing text, as well as being backwards compatible for clients that already use this system and users that are used to it.

[DanielOaks]

Overriding +c wholesale for that sounds a bit dodgy – the server would likely need to detect that case, override it with a specific replacement colour (to stop people from still being able to spam whatever colour they want), and leave the rest of the text that just uses regular colour/formatting codes alone. Workable, but def adds some additional complexity to the server-side around needing a proper formatting/colour code parser.

[Herringway]

there's precedent for that - servers with CTCP blocking modes tend to allow ACTION through, despite it being a CTCP

[eskimo]

Has anyone with the current \u0314,14 way implemented had any complaints from users?

[DanielOaks]

For what it's worth, my current thoughts on a spoiler text feature around ^ is that the same fg+bg colours method is probably the best way to go and the best we're going to get widely-adopted across the clients out there. Not working on +c channels (some servers just drop the line entirely, some just strip colour codes out) is really unfortunate, though.

[eskimo]

The best part about the current way is even clients without direct support, you can just manually highlight the text and be able to read it.

[mbax]

Not working on +c channels (some servers just drop the line entirely, some just strip colour codes out) is really unfortunate, though.

As a chan op in a channel where I wouldn't want annoying spoiler text, +c blocking that sounds perfect. +c is the mode for just wanting boring old text without any fanciness to it, and spoilers are fancy!

I like the idea of maintaining coloring (unless +c is detected, then not sending with color) and a client-only spoiler tag indicating where in the message the spoiler lies.

[DanielOaks]

+c blocking it is fine, it's more the servers that strip the colours and pass the text through as-is that make it undesirable, depending on exactly what sort of content is spoilered

[RyanSquared]

@mbax that's actually a clever idea because it could also solve the issue of +c blocking "old"/"fallback" spoilers.

[eskimo]

I wish there was some indication of it being a spoiler though, like it's own formatting char surrounding the whole spoiler this way the client can override the colors if they want. For theme clashing issues.

[RyanSquared]

That would be the point of the tag mbax mentioned; that way, you can do whatever you want with the text.

[eskimo]

Ahhh that wasn't there when I first read his comment. But yeah. The colors are just a fallback for clients that don't support it directly.

[mbax]

Example spoiler-laden message roughly using color and tag:

@+spoiler=15-23 :mbax!meow@kitteh.org PRIVMSG #ircv3 :Rosebud is the \x0301,01sled\x0F! Shocking!

In this example I include the color stuffs as part of the spoiler because that is its only purpose. Could be better leaving the color not part of it to allow for resetting colors to whatever it was previous (maybe someone really likes sending only red messages, and so immediately goes back to red rather than resetting.

[eskimo]

Repeating a good point on irc for archive here: in the event of a channel stripping color the range would be off for what should be a spoiler or not in the above example string.

[justjanne]

@prawnsalad

The whole point is to provide a way for people in certain communities to discuss sensitive issues. We're talking about rape, assault, and other stuff where just reading it might bring up horrible memories for some people in the channel.

No user should accidentally read such content which might cause serious psychological damage to them just because their client is outdated.

Currently these communities used rot13 (also in modified versions for latin-1 extended) or similar encodings combined with color codes.

Many of these communities have long switched over to other chat platforms due to such functionality being available there.

It is important to consider the implications of this — we need to ensure that whatever fallback a user on an older client sees is safe. As we can't rely on color codes being supported, as clients or servers may strip them by default, we have to build something else.

You don't want a normal user to join a channel, and immediately see a graphic description of rape by a user who is trying to share her experience and pain. Seeing that description might even bring back painful memories for the new user.

Suggesting that users on older clients should be forced to see such content, without even a proper indicator of the content warning, is reckless.

This, btw, is the one single feature where even Discord decided, while rolling it out, to hide the text inside a content warning as encoded text for older versions of their client. Where even they broke backwards compatibility.

[kythyria]

This, btw, is the one single feature where even Discord decided, while rolling it out, to hide the text inside a content warning as encoded text for older versions of their client. Where even they broke backwards compatibility.

Then they must have since rolled that back, because now it's cleartext on the wire again. A client that doesn't understand the spoiler tags would just show it unspoiled. And IIRC it never was scrambled--if you had the preceding version of the client you'd see cleartext too.

[jesopo]

what if we just TAGMSG the whole thing to entirely prevent non-IRCv3 users seeing it at all

[jwheare]

If people are already using encoded text in places where colour stripping is an issue, I don’t see anything controversial with defining a tag that indicates the range of encoded text, and maybe optionally an encoding method (or just fallback to base64) and allows clients to display it in a nice way that allows easy manual decoding.

Clients could also handle grey on grey in a similar way for channels that don’t have colour stripping.

Detecting whether a channel is removing colours isn’t really solvable automatically due to differing implementations, so which method to use can be left as a user preference.

Worth noting that the automatic decode range method would actively not work if colour codes were used in a channel that stripped them, but that can just be another caveat that users can be warned of and learn.

[jwheare]

So, e.g.

@+encoded-range=0-12;+encoding=base64 PRIVMSG #chan :U3BvaWxlcg== says “Spoiler”

[jwheare]

The concerns about bypassing spam filters are somewhat mitigated by the fact the spam text would be hidden by default, but also, there’s nothing stopping servers from parsing the tags and decoding the messages before filtering.

[prawnsalad]

@justjanne if somebody wants a feature of IRC then they should use a client that supports the feature. Encoding text on the wire effects 100% of all IRC users if they want the feature or not. This is not backwards compatible. I'm all for the feature and agree that we should have it standardised, but not at the expense of degrading other users IRC experience.

A message tag that specifies the boundaries, or a new style character code, would all be better suited as not to force it on everybody. As I mentioned in the last thread, it would even suit being broadened to have style boundaries so that text style + spoilers are handled in the same way.

[rakiru]

@justjanne if somebody wants a feature of IRC then they should use a client that supports the feature. Encoding text on the wire effects 100% of all IRC users if they want the feature or not. This is not backwards compatible. I'm all for the feature and agree that we should have it standardised, but not at the expense of degrading other users IRC experience.

The suggestion for encoding didn't come out of nowhere. It is a practice that is already fairly common for deliberately obfuscating text to ensure people don't accidentally read it, not only in IRC, but anywhere that lacks a builtin method to do it. Turning that into a spec doesn't mean obfuscating text that wasn't previously - it means clients can automatically deobfuscate such text. It would be purely an enhancement and standardisation of existing behaviour, allowing for an improved UX in any supporting client, and no change for those that don't.

A message tag that specifies the boundaries, or a new style character code, would all be better suited as not to force it on everybody.

The entire point of spoilers/content-warnings is to not force that content on everybody. "Backwards compatible" in this context means that the feature doesn't fail horribly for old/non-supporting clients, which is exactly what looking like a regular message is. If anything, standardising this feature would allow you to completely disable it and render them as if they were regular messages, which isn't something you can do right now without the spec.

As I mentioned in the last thread, it would even suit being broadened to have style boundaries so that text style + spoilers are handled in the same way.

Spoilers/content-warnings are not in the same category as things like bold text or colour codes, and it trivialises the well explained (and apparently largely disregarded in this thread) need for such a (already used but unstandardised) feature.

---

Let me reiterate to ensure my point gets across: The entire point of standardising this feature is that it works in a backwards compatible way, never forcing hidden content on someone who has not opted into it. If that goal is not met, people will continue to use the old methods, requiring manual decoding instead of allowing the client to present it nicely.

[kythyria]

Spoilers/content-warnings are not in the same category as things like bold text or colour codes

In what way are they not? They also affect the presentation of text. Are you saying that, for instance, bbcode should not include a [spoiler] tag, but instead some entirely different system be used to identify the offending text? That if a mechanism is devised for annotating arbitrary ranges of an IRC message so as to attach machine-readable information spoilers MUST NOT be part of that if it is also used for styling?

[DanielOaks]

Are you saying that, for instance, bbcode should not include a [spoiler] tag, but instead some entirely different system be used to identify the offending text?

There's a reason why surrounding text in a [spoiler] tag totally prevents it from being displayed, where other formatting tags in bbcode just make the text a bit thicker, make it italic, or do other similar modifications while still leaving the text readable. The systems aren't compatible at all – in a forum you literally can't have tags that only work for some users, on IRC an unsupported 'formatting character' means that the text isn't modified at all. Works for formatting, doesn't work for sensitive spoilered content.

[kythyria]

Then combine it with the proposal to use base64. Doesn't change that you still have to label which bit of the message is the spoiler, and a mechanism to do that will look an awful lot like a specialisation of a formatting mechanism.

Come to think of it, if you're base64ing this stuff anyway, whether the machine-readable marking is there doesn't affect the concealment. You only need the marking to make the reveal gesture work. Which is as optional as any other presentational formatting.

[DanielOaks]

Hmm. What if: define some unused character as the 'spoiler character', that acts as an on/off toggle for spoilered, base64'd content. Would keep working regardless of formatting characters being stripped out. e.g. something like:

if \5 is now the 'spoiler char':
the new spider man was \5Z3JlYXQgYW5kIEkgbG92ZWQgaXQgYSBsb3Q=\5
sensitive content here: \5PGRpc2N1c3Npb24gYWJvdXQgYSBzcG9pbGVyIGZlYXR1cmU+\5

indicates to clients where to start and stop the decoding, done as a first step before regular formatting is processed?

[jwheare]

Stripping is often implemented as just brute force disallowing control codes below a certain value. And I'm not in favour of defining new control codes. Tags are the way forward for progressive enhancement.

[DanielOaks]

I'd be totally up for using tags so long as they won't get affected by control code stripping (e.g. 'spoiler starts at char 7 of the message' oh no colours were stripped out so what was char 7 is now code 3, awesome), and that the whole 'can't be used on nets that don't support c2c tags' isn't a deal-breaker.

[jwheare]

I wouldn't say it's a deal breaker. We can't get 100% adoption, it's an enhancement that software can choose to support if it wants to have nice things. If not, people can keep doing what they're doing and manually decode.

Re: control code offsetting. Yes it's something that you'd have to be careful not to mix if stripping is going on. Perhaps even something clients could hint at when sending spoiler text.

[eskimo]

IMO encoding text is a completely different thing, this is a spoiler we're talking about... Also, to @jwheare - a tag that defines a range of text will be wrong if the color is stripped for any reason, and now if you need to debase64 this newly bad range you're gonna have a message that doesn't end up right.

It should really be used as it currently is, with the addition of a control char so clients know that it's a spoiler and not just part of ascii art.