Echoing state changes

[progval]

There are a couple of IRC features that require servers to keep track of which connection caused a particular state change:

1. PRIVMSG should be sent to other connections within the same session, even if they don't have echo-message. Otherwise if a client shares a session with other clients and sends a message, other clients won't see the message at all
2. If echo-message and labeled-response are enabled, PRIVMSG echoes must have the label sent by the client. This is required by clients that implement local echos in order to deduplicate
3. it would be nice if JOIN/PART/MODE/... echoes could have the label provided by the client

[progval]

Two open questions:

• What should we send along with events? MessageSinks themselves, or keep pending sinks in the connection state and send labels to identify the sinks? (note: labels are only using per-session). Sending connection ids would solve 1, but not 2 or 3; though we might have to add yet another abstraction leakage to MessageSink in order to implement 1.
• Where to put this? I considered some/most EventDetails variants and CommandAction::StateChange, but neither feels right. They also don't cover the whole chain from client to state back to clients.

[spb]

As things stand right now, 1. is solvable just by requiring that multi-connection-capable clients understand echo-message. For 2. and 3. the current behaviour is compliant with the labeled-response spec and I'm not sure how much extra effort it's worth putting in when other server implementations also routinely decide not to label things - clients have to be able to understand unlabelled responses anyway, even when the cap is enabled.

[progval]

when other server implementations also routinely decide not to label things

"routinely" is a strong word. In practice, echoed PRIVMSGs are always labeled, and clients implementing echo-message rely on it.

[progval]

clients have to be able to understand unlabelled responses anyway, even when the cap is enabled.

But even optional labels can improve client behavior. For example, Limnoria's @ircquote allows bot owners to send arbitrary commands, and optionally shows them any labeled response and Gamja uses the label to check it does not accidentally mix up responses to different Promises.

[spb]

"routinely" is a strong word. In practice, echoed PRIVMSGs are always labeled, and clients implementing echo-message rely on it.

If clients are interpreting a spec to mean something that it doesn't require, that's a problem that the spec should be updated to fix. Changing an implementation behaviour to match what's expected but not specified just kicks the problem down the road.

[progval]

https://github.com/ircv3/ircv3-specifications/pull/528

[progval]

Resolved by e467e5bafa23ab0059104a1ab805d2ed845e67bb + ad1e592bad5714e553fce124c92e7eaa9717e45d + 5be1f25bd1e89bcb2f8f5de39ce96b6d0e0487cd