Open Mikaela opened 3 years ago
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
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 :)
...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?
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.
Would work quite well with something like
msgtype="m.relay"
and putting impersonated name to extension ofm.room.message
similarly to file url and others. With having a power level setting form.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 🙃
Would work quite well with something like
msgtype="m.relay"
and putting impersonated name to extension ofm.room.message
similarly to file url and others. With having a power level setting form.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.
matrix-org/matrix-spec-proposals#4144
Suggestion
Ergo IRCd (previously known as Oragono) has implemented IRCv3 draft RELAYMSG (https://github.com/ircv3/ircv3-specifications/pull/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
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