Known Limitations

ZNC and message replies/reactions

ZNC never negotiates echo-message (or anything like it) with the upstream IRC server — its server-facing capability list omits it entirely, regardless of what the network supports. Both echo-message and the legacy znc.in/self-message cap it offers to clients are implemented as a purely local echo: ZNC replays the message you just sent back to your attached clients itself, with no round trip to the server and no server-assigned message ID ever generated.

Relay assigns a local-only fallback ID to the self-echo, so replies, reactions, and thread views for your own messages continue to work inside Relay. The synthetic ID is not visible to the IRC network, however, so other IRC clients cannot use it to resolve a reply or reaction.

Not fixable from the network side

This is a structural property of how ZNC implements self-echo, not a configuration issue.

soju and message replies/reactions

soju, unlike ZNC, does negotiate real upstream echo-message — but only when the IRC network it's bouncing to also advertises labeled-response, which soju needs in order to reliably match the server's echo back to the message that caused it.

If the network doesn't support labeled-response, soju falls back to fabricating the echo locally (the same way ZNC always does). Relay can still assign a local-only ID so replies, reactions, and threads work inside Relay, but other IRC clients cannot resolve that synthetic ID.

This case is fixable

Enabling labeled-response on the IRC server (a standard IRCv3 capability — available as a module on InspIRCd, for example) lets soju negotiate genuine echo-message and pass through real, server-assigned message IDs, restoring replies/reactions to messages you send through soju.