search

matrix-org / matrix-appservice-irc

Node.js IRC bridge for Matrix
Apache License 2.0
467 stars 152 forks source link

Implement /sajoin and /sapart commands #502

Open Ekleog opened 7 years ago

Ekleog commented 7 years ago

Hello,

I was recently thinking about putting a (private) matrix bridge behind a weechat IRC relay, so that I could use the matrix clients to connect to it (being ircop, I don't believe the matrix bridge is feature-ready for everything yet, hence the need to keep a weechat somewhere to which I could directly connect).

Unfortunately, it looks like the bridge doesn't support (yet?) sajoin and sapart, the two commands used by the bridge to propagate channel joins from the master weechat to the clients of the bridge (I think).

I believe implementing /sajoin as an invite from the bridge to the user and /sapart as a kick from the bridge to the user would quite map the purpose, yet using only matrix-based permissions... wouldn't it?

Cheers, Leo

Mikaela commented 7 years ago

I believe that matrix-appservice-irc isn't attempting to replace an IRC client and I think supporting network operator commands (sa = server administrator, isn't it?) would be very out of scope for it, so I am closing this issue.

In case we are talking about different things, sajoin/sapart are generally used by IRCds to force different user to join/part IRC channels

Ekleog commented 7 years ago

I'm not saying it should allow ircops to issue sajoin/sapart commands (that'd be very out of scope indeed), but allow the irc side to receive sajoin/sapart's.

This would also eg. avoid the current behavior that if a bridged user is /sapart'd from a room they will still think they're in there (yet not seeing any message) until they send a message again (at which point they'll re-join).

Actually, after some more testing this is even worse than I thought: currently, if I perform the following operations:

Then:

I guess I spent too much time on the background and not enough on the proposal: that'd be just summed up by “map incoming /sajoin to incoming /invite and incoming /sapart to incoming /kick,” as the meaning is almost the same (except /sajoin on IRC actually makes one join immediately instead of merely inviting, but I'm pretty sure there is no matrix action that'd map to it, and there should not be given the federation)

Mikaela commented 7 years ago

I think sajoin/sapart appear as normal JOINs/PARTs, but I am unsure if supporting them would be in scope.

Matrix-appservice-irc doesn't support !cmd join and I think sapart would be fixed with https://github.com/matrix-org/matrix-appservice-irc/issues/460 .

@Kegsay What is your opinion on this issue?

Ekleog commented 7 years ago

sapart looks similar to #460, though wireshark reports :iamtesting!iamtesting@my.censored.ip PART #thisisatest incoming from the server, that is a part response as though a part request had been sent.

In a similar way, sajoin is just the server sending a JOIN response without the client having sent the JOIN request:

:iamtesting!iamtesting@my.censored.ip JOIN :#thisisatest
:irc.server 353 iamtesting = #thisisatest :iamtesting @someotherpeople
:irc.server 366 iamtesting #thisisatest :End of /NAMES list.

As such I don't think it would be very hard to support at least sapart (that said I don't know anything about the code base). Handling sajoin may be a bit trickier, though (as it would have to get transformed into an invite to map the matrix side).

kegsay commented 7 years ago

If they are represented at a protocol level as JOIN and PART then the bridge should already handle this provided membership list syncing is enabled.

Mikaela commented 7 years ago

They are, but coming from server rather than the client.

Ekleog commented 7 years ago

In a normal join, the packet exchange is:

CLIENT->SERVER: JOIN REQUEST
SERVER->CLIENT: JOIN RESPONSE
CLIENT->SERVER: ACK (TCP-level)

In a sajoin, this exchange just forgets about the first packet, and the server directly sends the JOIN RESPONSE.

This is similar with parts and sapart's.

Yet, testing shows that the bridge doesn't correctly sync the membership list. Maybe because it doesn't expect the JOIN RESPONSE to come unsolicited, and thus drops it? I haven't tried to check the bridge logs yet, waiting to check whether it'd be in scope or not before putting too much effort in there.

Ekleog commented 7 years ago

Hmm... Would it be possible to re-open this issue, at least until whether it's in-scope or out-of-scope is determined? As not having it implemented means the membership lists may not be in sync even if the parameter is set in the config I'd think it is in-scope, but for the time being it looks like it's being just forgotten due to being closed.

Mikaela commented 3 years ago

It looks like I am hitting this as an user with a tie-in to https://github.com/matrix-org/matrix-appservice-irc/issues/27#issuecomment-877643707.