Username spoofing for lightweight chat platform bridging

[jlu5]

Context: I've been working on IRC relay stuff for several years now, and I'm considering a different way to transparently link chat platforms together. Similar to how Discord and Slack allow username spoofing via webhooks, I wonder if it'd be useful to add some sort of username spoofing for trusted clients on IRC.

Compared to traditional relay bots which don't blend in at all, or more complicated bots that mirror users on the C2S ([1], [2]) or S2S level, this method could allow for lightweight bridging between different platforms. Specifically, it removes the need for for bridge bots to keep track of remote platforms' state (which can be expensive and isn't even allowed by all bot APIs), and exposing them onto IRC (dealing with disconnections, nick conflicts, and a plethora of other issues).

I imagine this command to have a simple syntax that gets translated to PRIVMSG or NOTICE by the receiving server. A new user being spoofed need not actually be created by the IRCd, and the message can be forwarded as if it were from an external client not in the channel:

RELAYMSG <nick> <ident> <host> <channel> :<message>

Ideally there should be some security checks too, such as:

• A WEBIRC-like password login before any RELAYMSG is accepted
• Requiring that the RELAYMSG mask match a certain hostmask (e.g. */discord!*@*)
• Disallowing RELAYMSG if the target nick exists or is reserved

Of course, there are some downsides to this approach too:

• Sending PMs from IRC to remote is less straightforward (though on the receiving it's often already quite cumbersome)
• Moderation is more limited. For this proposal I'm more interested in bridging IRC with other platforms instead of relaying between IRC channels. In these cases, kicks and bans can't always be relayed in the first place: for example, Discord only has per-server kicks and not per-channel ones.

Related discussions:

• IRC puppeting 42wim/matterbridge#667
• Puppeting 42wim/matterbridge#788

[jwheare]

This is probably best implemented as a message tag, e.g. display-name. That’s how we’re currently doing it for our Slack gateway (https://blog.irccloud.com/slack-integration/), as draft/displayname in our case, but subject to change pending a proper spec proposal.

[jwheare]

There’s a similar metadata key proposal but that’s better suited to persistent users rather than bridged ones. ircv3/ircv3-specifications#336

[jlu5]

@jwheare Just to clarify, I assume you mean a single gateway/relay client that alternates its display name tag for each message?

Unfortunately, I don't have the luxury of everyone using a uniform client, so for now I'm trying to find an approach that requires changing as few things as possible. (Might work on a PoC soon[tm])

[jwheare]

Yeah you’d send the tag with each message and clients would need to display them in such a way that made it clear they were spoofed.

[jwheare]

Any solution would need to have custom client support to work properly really.

[jlu5]

I suppose a "relaymsg" capability would just signal the availability of that command for bots, etc. that want to use it. The end result would be messages sent from whatever custom source set by the caller, so it wouldn't require custom client changes for anyone else.

As a side note, I just realized this is conceptually similar to what m_rpg does in inspircd-contrib.

[DanielOaks]

+1 on using a draft/displayname tag. feels like a cleaner approach in general, even if it requires more client support.

if you're spoofing nicks, other users will try to pm those spoofed nicks, so you'll need a way to introduce/remove relaymsg 'clients' and keep track of them, etc. introducing just the ability to send messages with relaymsg without reserving the spoofed nicks and capturing the privmsgs/dms to those nicks feels like a way to let IRC users accidentally send private messages to the wrong people. I guess something like relaymsg could be useful but feels like with the necessary extensions to prevent privacy issues, it'd complicate things to the point where just using an s2s link to relay the info (ala pylink) seems like the easier route there.