ircv3
Spoiler Text
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
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.
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
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.
@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.
@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.
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.
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
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.
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.
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.
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
Sure, but having something that flat out doesn't work with older clients is also not backwards compatible.
@DanielOaks that creates a reliance on the server supporting the spec as well, doesn't it?
Suggest clients use colours as a fallback in channels that are -c, otherwise base64?
I see a couple of issues with that @kythyria
- nonstandardized channel mode
- users not knowing why messages change for different channels
@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.
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).
@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.
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.
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.
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.
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.
there's precedent for that - servers with CTCP blocking modes tend to allow ACTION through, despite it being a CTCP
Has anyone with the current \u0314,14 way implemented had any complaints from users?
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.
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.
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.
+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
@mbax that's actually a clever idea because it could also solve the issue of +c blocking "old"/"fallback" spoilers.
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.