Appserviceless/homeserverless ghosts/puppets (IRCv3 RELAYMSG)

[Mikaela]

Suggestion

Ergo IRCd (previously known as Oragono) has implemented IRCv3 draft RELAYMSG (ircv3/ircv3-specifications#417) which allows relaybots (think of bridges without 1:1 PM ability) to send messages from other protocols like they were native to IRC. In Matrix this is possible with appservices/bridges, but that requires running a homeserver which may be too much of treshold from running a simple bot (that doesn't even require a domain).

I would like Matrix to offer something similar and I hope that in the future matrix-appservice-irc could recognise it, other bridges without PM ability would use it too and thus send relaymsg'd Matrix messages to IRC as relaymsg's thus causing less load and not taking connection slots benefiting both bridge operators and IRC networks that don't want users of other networks into theirs.

---

Example of RELAYMSG on IRC

2021-148 18:28:05 EEST <M1kaela/T> /ping
2021-148 18:28:05 EEST <@R-66Y> pong

Here M1kaela is a Telegram user, / is the separator that the IRC network uses for RELAYMSG (and forbids from real nicknames to combat abuse), R-66Y is a IRC bot (with no idea what is Telegram) and T4 would be the relaybot (matterbridge), but as it's using RELAYMSG it's not visible (to plain sight). The other combat towards abuse is that to use RELAYMSG, the sending bot must have op status on the channel (or be configured as oper in IRCd config).

This is stateless so M1kaela does not appear in IRC user/names list and the nickname cannot be autocompeted, but it's still pretter and prettier than having to see <T4> <M1kaela/Telegram> /ping which practically no bot would recognise on IRC side.

Ergo IRCd integrated documentation on the command

2021-148 18:33:41 EEST -- RELAYMSG :RELAYMSG <channel> <spoofed nick> :<message>
2021-148 18:33:41 EEST -- RELAYMSG :
2021-148 18:33:41 EEST -- RELAYMSG :This command lets channel operators relay messages to their
2021-148 18:33:41 EEST -- RELAYMSG :channel from other messaging systems using relay bots. The
2021-148 18:33:41 EEST -- RELAYMSG :spoofed nickname MUST contain a forwardslash.
2021-148 18:33:41 EEST -- RELAYMSG :
2021-148 18:33:41 EEST -- RELAYMSG :For example:
2021-148 18:33:41 EEST -- RELAYMSG :    RELAYMSG #ircv3 Mallory/D :Welp, we linked Discord...
2021-148 18:33:41 EEST -- RELAYMSG :End of /HELPOP

[Sorunome]

This could also have lots of advantages for roll-playing or other activities, ones where you typically have to change your name frequently for a single message, but don't want to clutter the timeline with m.room.member events as that would a) pollute the room state and b) pollute the timeline. Think: discord webhooks or thelike

[MTRNord]

As this was discussed in a non-public room, I got some security concerns regarding impersonating:

I was informed that IRC requires the equivalent of at least being mod. This imho is needed. But I also think this should not allow existing users in the room to get impersonated if you have elevated permission.

Arguably, there should be a warning anyway for this.

Apart from that, I think this is a good thing to have :)

[Mikaela]

...The other combat towards abuse is that to use RELAYMSG, the sending bot must have op status on the channel (or be configured as oper in IRCd config).

To clarify, IRC op roughly equals PL50 in Matrix and matrix-appservice-irc even performs that mapping, so I didn't realize my original phrasing is blocking this?

[kate-shine]

Would work quite well with something like msgtype="m.relay" and putting impersonated name to extension of m.room.message similarly to file url and others. With having a power level setting for m.relay, clients could easily see if that user has a right to impersonate or not.

[kate-shine]

Would work quite well with something like msgtype="m.relay" and putting impersonated name to extension of m.room.message similarly to file url and others. With having a power level setting for m.relay, clients could easily see if that user has a right to impersonate or not.

Actually no, that would prevent us from relaying other msgtypes 🙃

[MTRNord]

Would work quite well with something like msgtype="m.relay" and putting impersonated name to extension of m.room.message similarly to file url and others. With having a power level setting for m.relay, clients could easily see if that user has a right to impersonate or not.

Actually no, that would prevent us from relaying other msgtypes 🙃

The overall idea still sounds sane. And the issue solves itself when we get extensible events where you can have multiple event types in a message.

[tulir]

matrix-org/matrix-spec-proposals#4144