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's reply and reaction features rely on that ID to link a reaction or reply to the message it targets, so replying to or reacting to a message you sent through ZNC never resolves.

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), and self-sent messages end up without a resolvable ID, so replies/reactions to your own messages fail the same way they do through ZNC.

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.