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

[edk0]

I think requiring the obfuscation to apply to the whole message (with any descriptive text sent in another message) would simplify this a lot.

[jwheare]

@jq1106 as discussed, control codes can get stripped or blocked entirely by channel modes. The encoding is also "used as it currently is"

And also, as discussed, mixing color codes would have to be done carefully, or discouraged entirely for this to work. That doesn't mean the solution doesn't help for most situations.

[justjanne]

Alternatively, the range specified by the tag could simply ignore control characters. So that if you have text\x03text\x03SPOILERCONTENT, we’d define the spoilercontent as starting at character 8 (0-indexed)

[DanielOaks]

current idea being tossed around: just going all-or-nothing using tags. maybe something like:

:someone PRIVMSG #chan :Yo so here's some spoilerz:
@+spoiler :someone PRIVMSG #chan :b2ggZ29zaCBJJ20gc3R1Y2sgaW4gYW4gZW5kbGVzcyBjeWNsZSBvZiBwcm9wb3NpbmcgSVJDdjMgc3BlY2lmaWNhdGlvbnM=

@justjanne issue is what the server and client defines as 'stripping' may differ. e.g. especially when stripping colour numbers at the end – servers may ignore colour codes 16-98, clients might or might not, etc

[DanielOaks]

interesting thing about the above method: may be possible to allow the same thing to work over servers that don't support tags. if the server supports tags then receiving clients can just look for the +spoiler tag as an indicator. if c2c tags aren't supported, client just looks for any message which can intelligibly be decoded using base64.

or am I totally off-the-mark with this and b64 is one of those encodings where you can 'decode' literally anything and it'll turn out successfully?

[DanielOaks]

Rolling back 'round to the initial issue: may even be worth keeping the existing fg+bg method named 'spoiler' and having something like a full-message encoded thing that's called 'sensitive text (b64 encoded)', or some other two terms that better convey the significance of the two, cuz I know the lighter-weight fg+bg method does work nicely for a lot of what I'm after, but the proper encoded version should be there for those who need it? just throwing out ideas willy-nilly, don't mind me too much

[csmith]

What about some simple ASCII markup containing base64?

:someone PRIVMSG #chan :Has anyone seen Soylent Green? [spoiler:U295bGV0IGdyZWVuIGlzIHBlb3BsZQ==]

It's relatively straight-forward to parse, hides by default, doesn't need control characters, is sort-of obvious if users see it in a client that doesn't understand it.

I don't hugely like having "spoiler" in English user-visible, but that's no worse than looking at bbcode or HTML etc.

[trobotham]

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

This is still problematic as it leaves non-supporting clients in the dark as to what is happening conversation-wise however, I would be more for this then modifying the users message (ie: adding color tags, obfuscating text, etc). Boundary markers would be most ideal as it would allow non-ircv3 support clients to handle how they would like IMO.

[GIJack]

We could standardize the mIRC colors as part of the spec. We can probably add a new char for "spoiler" like bold or color tags. Only issue on legacy clients it wouldn't work.

[ribosomerocker]

Maybe make the server intercept all "spoiler" messages, send a message with [spoiler], then store the spoiler message somewhere, for users to essentially "read" the spoiler they're going to have to send the UNSPOIL with the message ID, then the message gets sent to the user that unspoiled it. Might not be the most storage-efficient method, but I think it might be just good enough that it doesn't cause too many issues.

[GIJack]

I like it, add another code for spoiler.. Should be easy enough

[ribosomerocker]

Something I realise that doesn't cover is partially spoiled messages, but I think we would have to make do with just that, or maybe when the message is intercepted by the server, it would take the spoiled part, replace it with [spoiler], then store the message with the spoiled content unchanged, but it does modify the user's message, well, somewhat, which is what I see some people previously disliked.

[progval]

IMO, fg=bg is a no-brainer because it is already in widespread use, documented, and more or less supported by all implementations.

The only objection to it I have seen so far is that it is blocked by channel mode +c, but:

1. it may be seen as a feature to block spoiler tags along with all other formatting tags (as +c also blocks bold, etc. in at least some implementations)
2. if someone wants to allow spoiler tags but not other formattings anyway, then it is easier to change servers to allow this particular syntax, than to implement whatever brand-new spoiler syntax we may come up with. As pointed out previously, there is precedent in servers whitelisting CTCP-action.