Add +reply client tag support

[skizzerz]

We validate that the reply looks like a valid message id as generated by tag_message_id and that the reply is going to the same target that could have generated the message id. Since tag values do not currently go through spamfilter, this is an easy-ish way to ensure that it cannot be used as a backchannel for spam.

[notklea]

That the reply is going to the same target that could have generated the message id

I suppose target is either a channel, or a user for the rest of this comment.

I don't think it'd be the best, since you could have a reply from a message be sent to another message, or is that prohibited by spec, if not, it wouldn't make sense to block or drop the reply information if for example a bot that doesn't need voice nor op in a bot log trails channel sends replies to commands ran on other channels.

[skizzerz]

if for example a bot that doesn't need voice nor op in a bot log trails channel sends replies to commands ran on other channels.

This is not a use case I care to entertain. The purpose of +reply is for clients to be able to accurately display breadcrumbs in their clients, and I would be fairly surprised (as an end user) if I clicked on a reply breadcrumb only to jump to a completely different channel or to be told the original message doesn't exist because it's from a channel or PM I'm not on.

[notklea]

This is not a use case I care to entertain.

I guess if that's the case, okay.

The purpose of +reply is for clients to be able to accurately display breadcrumbs in their clients

The specification says "This specification defines a client-only message tag to indicate replies to other messages" (emphasis mine), not stating if between channels or not, just to other messages.

I would be fairly surprised (as an end user) if I clicked on a reply breadcrumb only to jump to a completely different channel

Indeed, the implementation tool on clients may be higher if they have to also include the channel the reply was sent to, so you don't get confused.

or to be told the original message doesn't exist because it's from a channel or PM I'm not on.

I wonder, how do you know it's not a message from the same room before you were there, since that's something likely to happen, and the spec in itself says the reply identifier is opaque, so you can't really know where a message came from, if you just interpret the specification, and don't also interpret the behavior of certain servers.

In case it's a reply in a channel or PM you're not on, your client wouldn't be able to show a preview, and could act as if it wasn't a reply, or rightfully say something like reply to unknown message.

[JustAnotherArchivist]

I would be fairly surprised (as an end user) if I clicked on a reply breadcrumb only to [...] be told the original message doesn't exist because it's from a channel or PM I'm not on.

This is a case you have to handle as a client anyway though even with your same-target restriction: it could be a reply to an older message from when you weren't yet in the channel (and which isn't included in chathistory, if applicable in the future) or a reply to a message that's only delivered later, e.g. on lag between servers.

For cross-target replies, sure, simply jumping to another channel would be poor UX (at least by default), but that's not the only UI option. Personally, I'd probably just prompt the user with 'this is a reply to a message in [target], do you want to go there?'-type message. Either way, unless there's an agreement among ircd devs to not support cross-target replies (in which case it should probably go into the spec), again, it's something the clients will need to consider anyway in the implementation design.