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
Services Approved Joins #42
Comments
The approach described at https://www.unrealircd.org/docs/Extended_Bans and http://www.irchelp.org/protocol/extban.html that some other ircds use might be interesting to look at. We could have flags that either the server or services could handle, and services could announce what flags it handles in case a server doesn't handle newer flags yet. This would be better than having almost all channel joins sent to services, and some extbans could still be restricted to IRC operators and/or made invisible to users. |
I'm not against adding "extended bans" or improving our match function to support more features but this will not let us what we want to do - modify join conditions on the fly. I don't know why you think almost all channel joins will be sent to services. Considering this feature is disabled by default, and when set to 1 (which is probably what we will use if we'll need it), it will require the channel to also be +r, it will only affect specific channels (we don't use +r so all our channels are -r now). -Kobi. |
Are there any services that still set cmode +r for registered channels? http://docs.dal.net/docs/modes.html#2.17 says However, https://wiki.inspircd.org/2.0/Channel_Modes says |
I don't know but I went ahead and changed it to use a new extended channel flag just in case. -Kobi. |
Pull request #51 has been merged. |
A (server) command that in combination with cmode +r will require channel joins to be approved by services.:
When a user will join these channels, the IRCd will send the request to services. instead of having the user join the channel, services will do a few internal checks (including checking that the user isn't akicked so if a user is akicked, services won't even allow them to join instead of kickban'ing them later) and if everything is good, it will approve the join and send a command back to the IRCd to do the actual join.
When services are down, the join command will function normally.
When services are lagged, the join command will be lagged as well (for these specific channels).
This will let us do a lot of things dynamically without upgrading all servers (just services) like, for example, allowing channel ops or IRC Operators approve or deny specific joins (services can automatically approve or deny the request if it isn't approved/denied within X seconds to be on the safe side).
-Kobi.
The text was updated successfully, but these errors were encountered: