Unresolved issues with message redaction

[jwheare]

This is a follow up from #524 which is being merged due to the unsustainable length of review comments and the fact that they're scattered everywhere, hidden and impossible to make sense of. There are a couple of things to clarify here, ideally they can be resolved before we update the website.

• REDACT should be included in chathistory responses, regardless of event-playback. Clarify this and also maybe mention it in the chathistory spec too.
• Resolve issue around chathistory message limits, and differentiating between those included in chathistory vs those sent in real time https://github.com/ircv3/ircv3-specifications/pull/524/files#r1213533699
• Clear up the intention of this line, I'm still not sure why it implies that servers want to keep track of channel membership when determining whether to send REDACTs in chathistory. If a message is redacted while a client is not present in a channel, servers may send the `REDACT` command in a `chathistory` batch when it re-joins the channel.

Non-blocking

• The canonical way to remove a reaction should be an unreact tag, not a delete, feels wrong to spec it here first. It's not really great that clients will have to handle two paths for this but perhaps unavoidable.
• A method to communicate the redaction window to clients: channel mode, isupport?

[spb]

* Clear up the intention of this line, I'm still not sure why it implies that servers want to keep track of channel membership when determining whether to send REDACTs in chathistory.
  `` If a message is redacted while a client is not present in a channel, servers may send the `REDACT` command in a `chathistory` batch when it re-joins the channel. ``

I suspect this is because the chathistory spec says:

If the client has not negotiated the draft/event-playback capability, the server MUST NOT send any lines other than PRIVMSG and NOTICE in the reply batch

...and this spec is extending chathistory to permit REDACT as well. I would be inclined to suggest that chathistory should probably be changed to introduce a concept of 'history-safe messages' (or equivalent bikesheddable name) and allow other specs to define their message types as history-safe or not.

[progval]

Clear up the intention of this line, I'm still not sure why it implies that servers want to keep track of channel membership when determining whether to send REDACTs in chathistory. If a message is redacted while a client is not present in a channel, servers may send the `REDACT` command in a `chathistory` batch when it re-joins the channel.

I thought I had cleared that up already.

Client sees a message, disconnects. Someone REDACTs the message. Client reconnects, server sends the REDACT so that the client can hide the message as if the REDACT was received live.

[jwheare]

Unclear if you're talking about chathistory batch or chathistory request. But either way that's just normal behaviour. For a request, you get all messages you request, presumably since the last time you were in the channel. For the on join batch, there is already a built in lossiness to it. I don't get why redactions have to be treated specially here.

[progval]

I did mean the on-join batch. And that's a suggestion to server authors in a non-normative section, they don't have to do it.

[jwheare]

Just change it to: Servers MAY send `REDACT` commands in [`chathistory` batches](https://ircv3.net/specs/batches/chathistory) sent to clients on joining a channel (link in the footer if you wish)

I believe the original question about this was here https://github.com/ircv3/ircv3-specifications/pull/524#issuecomment-1564789080 but I really don't think we need to specify or imply any special casing for REDACT that isn't already the case with PRIVMSG etc. If just raises more questions and puts a stumbling point on implementors when reading this part of the spec.

[progval]

Sold