Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web IRC support #153

Open
mweinelt opened this issue Sep 4, 2016 · 11 comments
Open

Web IRC support #153

mweinelt opened this issue Sep 4, 2016 · 11 comments
Labels
T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements.

Comments

@mweinelt
Copy link
Contributor

mweinelt commented Sep 4, 2016

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
Copy link
Member

kegsay commented Sep 26, 2016

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
Copy link

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
Copy link
Contributor

Mikaela commented Oct 6, 2018

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
Copy link
Member

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
Copy link
Contributor

Mikaela commented Dec 22, 2018

Suggestion from Finnish Matrix Room: use webirc to get users hotmask nick![email protected]

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

@Mikaela
Copy link
Contributor

Mikaela commented May 11, 2019

How difficult/timeconsuming would this be to implement or would it be better to skip/close this in favour of S2S protocol (#329)?

@kegsay
Copy link
Member

kegsay commented May 13, 2019

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
Copy link

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
Copy link
Contributor Author

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:[email protected].

@Mikaela
Copy link
Contributor

Mikaela commented Jul 10, 2021

At Ergo IRCd there are thoughts of a separate command for communicating bridge identifiers across ergochat/ergo#1724 (comment), 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 #723.

@prdes
Copy link

prdes commented Jul 14, 2021

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.

@justinbot justinbot added T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements. and removed feature-req labels May 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements.
Projects
None yet
Development

No branches or pull requests

8 participants