Daniel Oaks

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...

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`...

@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....

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.

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...

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...

+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...

note for others: this could also be interpreted as 'consistency'. having these sort of things done in a consistent manner in the protocol also allows text-based clients to create nice,...

So on the `resume` spec, my original intention was to say _"just leave the old connection open and then `RESUME` on the new connection before breaking the old one"_, as...