Ratify the reply client tag specification.

[SadieCat]

I don't think there are any objections relating to this and we have enough implementations so lets ratify and ship it!

---

Known implementations

Unchecked means incomplete or an intent to implement has been expressed. The numbers indicate minimum requirements. Any others?

Client (3/1)

• catgirl
• Goguma
• IRCCloud

Server (3/2)

This one is a client-only tag so server implementations are generally less important imo.

• Anope (pseudoclient)
• Matrix2051
• UnrealIRCd (tag whitelisting)

Bots

• BitBot
• Limnoria
• Moon Moon

[jwheare]

The only concern I have is do we want to prohibit multi level replies. I would favour doing so, but if not then we might need another tag to indicate the top level of a reply chain. If we do prohibit them, then react would have to override that rule.

[skizzerz]

Poking to maybe get momentum on this again, as the spec seems fine after such a long time. For the concern about multi-level replies I think leaving that to a client implementation decision is fine. A client that displays breadcrumbs (think something similar to discord's reply feature) isn't really concerned about nesting; you click the reply breadcrumb and it jumps to the message it is a direct reply to. That message may also have a breadcrumb which can be clicked to jump further back, etc. In any case, the messages are all in the order they were sent and the reply UI just provides an easy-to-click link to view context.

If a client wants to do a threaded view where all replies are shallowly nested under the original comment, it could implement its own logic to determine which "thread" to put it under, in that if something is a reply to a message already belonging to the thread, it shoves it into that same thread.

While those suggestions could go into non-normative client implementation considerations, I don't think it warrants changing any of the normative language of the specification. As such, ratifying as-is seems appropriate.