Repository navigation
irc: fix RELAYMSG nick missing required separator - #2259
Closed
johnnyxmas wants to merge 2 commits into
Closed
johnnyxmas wants to merge 2 commits into
johnnyxmas wants to merge 2 commits into
Conversation
…yed message to be rejected
doSend() sanitized the nick for RELAYMSG but never appended a
separator/protocol suffix (e.g. "alice/discord"). Servers that enforce
draft/relaymsg's separator requirement (e.g. Ergo with relaymsg.separators
configured) reject every such RELAYMSG with ERR_INVALID_NICK, so no message
from any bridged platform ever reaches IRC when relaymsg.separators is set -
this reproduces 100% regardless of which user is speaking.
Also fixes a related issue: modifyUsername() in gateway.go unconditionally
applies the destination's RemoteNickFormat template (e.g. "{NICK}: ") to
Username before it reaches the IRC bridge. For RELAYMSG destinations this
punctuation gets baked into the nick before sanitizeNick runs, producing
mangled/truncated nicks (e.g. "alice: " -> "alice--" after sanitizing).
RELAYMSG doesn't need a text-prefix format at all - the nick itself is the
sender identity - so skip RemoteNickFormat templating for IRC+UseRelayMsg
destinations while still honoring StripNick/ReplaceNicks.
Reproduced against a live Ergo instance with relaymsg.separators=["/"]:
every Discord/Slack -> IRC message failed with
"FAIL RELAYMSG INVALID_NICK :Relayed nicknames MUST contain a relaymsg
separator from this set: /" until this fix.
Same lint cleanup as applied on the fork's master - no functional changes. Verified with golangci-lint v2.12.2 locally (0 issues).
Author
6 of 7 tasks
Author
|
Correction: my previous close comment was based on comparing against my own fork's master, not this repo's master — the fix has NOT actually landed upstream. Reopening; this PR is still valid and needed. |
Author
|
Maintainer has been inactive on this repo since August 2024 (over two years), so I'm maintaining these fixes on my own fork (johnnyxmas/matterbridge) instead of waiting on upstream review. Closing this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
doSend()sanitizes the outgoing RELAYMSG nick but never appends a separator/protocol suffix (e.g.alice/discord). Servers that enforce draft/relaymsg's separator requirement (e.g. Ergo, whenrelaymsg.separatorsis configured) reject every such RELAYMSG withERR_INVALID_NICK, so no message from any bridged platform reaches IRC when the target network enforces this — reproducible 100% of the time, regardless of which user is speaking.Also fixes a related bug:
modifyUsername()ingateway/gateway.gounconditionally applies the destination bridge'sRemoteNickFormattemplate (e.g."{NICK}: ") toUsernamebefore it reaches the IRC bridge. For RELAYMSG destinations this bakes stray punctuation into the nick beforesanitizeNickruns (e.g."alice: "→"alice--"after sanitizing), producing a mangled/truncated nick even once the separator is fixed. RELAYMSG doesn't need a text-prefix format at all — the nick itself is the sender identity — so this skipsRemoteNickFormattemplating specifically for IRC destinations withUseRelayMsgenabled, while still honoringStripNick/ReplaceNicks.Reproduction
Reproduced against a live Ergo instance with
relaymsg.separators: ["/"]configured. Every Discord/Slack → IRC message failed identically:Confirmed via debug logging (
DebugLevel=2) that this is what matterbridge actually sends — not a config issue on the Ergo side. IRC → other platforms, and Discord ↔ Slack, were unaffected; only the RELAYMSG-based* → IRCpath was broken.Fix
relayMsgNick(nick, protocol, maxNickLen string/int)helper: sanitizes the nick, then appends/<protocol>. Truncates the base name (not the suffix) against the server's advertisedNICKLENwhen known, on a UTF-8 rune boundary, so long names can't silently truncate the required suffix back into the same failure.gateway.modifyUsername(): skipRemoteNickFormattemplating for IRC+UseRelayMsgdestinations, since RELAYMSG doesn't use a text-prefix format.sanitizeNick/relayMsgNickcovering the basic case, truncation + suffix preservation, UTF-8 rune-boundary safety, and the degenerate case where the suffix alone exceedsmaxNickLen.Test plan
go build ./...go test ./...(full suite, no failures)go vet ./bridge/irc/... ./gateway/...gofmt -lclean on touched filesbridge/irc/irc_test.gopassINVALID_NICK; the fix produces valid nicks likealice/discordthat Ergo accepts🤖 Generated with Claude Code