search

matrix-org / matrix-appservice-irc

Node.js IRC bridge for Matrix
Apache License 2.0
464 stars 151 forks source link

Web IRC support #153

Open mweinelt opened 8 years ago

mweinelt commented 8 years ago

Please implement the Web IRC protocol. It enables opers to properly react towards abusive behaviour, without needing to ban the entire appservice.

https://kiwiirc.com/docs/webirc

kegsay commented 7 years ago

Not sure this will work for us. WebIRC assumes that the real user is connecting to the intermediary, which then goes through to the IRCd. This is not true in Matrix. We get HTTP requests from the HS, not the user. This means the bridge doesn't know the IP address of the client.

itsrachelfish commented 5 years ago

Would it be possible for the homeserver specify X_FORWARDED_FOR HTTP headers? If this isn't currently an option in synapse, maybe it could at least be created as a feature request?

Mikaela commented 5 years ago

I don't think this is possible as the bridge works more like a bouncer (or IRCCloud) than a webchat and there is no limit on how many clients or IPs the user may be using.

What if I sent every second message from PC and the other on my phone? Would my ghost need to reconnect to IRC all the time? What if I was suddenly quiet enough time for my IP to change and there was still a connection active with my old IP?

Alternatively I guess the Synapse IP could be sent no, it can also be dynamic and I am not sure the appservice knows that either and I don't know how it handles multiple IPs (IPv4/IPv6) aed what if the one it used went down?

My solution would be banning just the user@host or realname as the users cannot change either that I know of.

turt2live commented 5 years ago

no, it can also be dynamic and I am not sure the appservice knows that either and I don't know how it handles multiple IPs (IPv4/IPv6) aed what if the one it used went down?

There's also the problem of the appservice transactions likely containing multiple user's messages, therefore the IP is relatively irrelevant. Similarly, synapse may not be aware of a remote user's IP.

Mikaela commented 5 years ago

Suggestion from Finnish Matrix Room: use webirc to get users hotmask nick!localpart@homeserver.example.net

I think it may be a good use and there are projects doing a bit similar like I2P.

Mikaela commented 5 years ago

How difficult/timeconsuming would this be to implement or would it be better to skip/close this in favour of S2S protocol (https://github.com/matrix-org/matrix-appservice-irc/issues/329)?

kegsay commented 5 years ago

S2S would probably be a better solution if I'm honest. Both options would be time consuming to implement, but S2S has other benefits so would probably be preferable.

rubinlinux commented 4 years ago

We solved a similar problem on AfterNET with regards to ZNC bouncers, where we don't necessarily know the users IP. So we 'make one up' in reserved space by hashing their username. That way the same user always gets the same IP and if they abuse, any glines/klines set on that IP wont affect everyone from the same bouncer. That way on the IRC side bans and things all 'just work' as expected.

mweinelt commented 4 years ago

FWIW: If you're setup can ban based on Gecos/Realname, that's where the matrix id is visible.

On Charybdis for example: /mode #example +b $r:user@example.com.

Mikaela commented 3 years ago

At Ergo IRCd there are thoughts of a separate command for communicating bridge identifiers across https://github.com/ergochat/ergo/issues/1724#issuecomment-873842622, which I think could possibly replace WEBIRC for this use case (if it also got widely implemented) and resolve the worry on real name being depended upon for managing abuse https://github.com/matrix-org/matrix-appservice-irc/issues/723.

prdes commented 3 years ago

yeah dropped in here to link the Ergo comments but it was already addressed above. It would indeed be nice to have proper standardized way of handling puppet based bridges.