-
Notifications
You must be signed in to change notification settings - Fork 1
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
Support for super users #45
Comments
I don't think we should obey nick clusters for super users. Too easy to game. I think the most extensible way to do this would be like the list component. Super user nicks are stored in a data file and there is a privileged command to add and remove users from that list. |
👍 |
How do the first super users get authenticated? Manually editing the data/superusers file before your first run is kinda janky. |
Couple of ideas, not sure if any are good.
|
The first two would work well on a ChanServ registered channel (so on freenode) where you don't automatically become an op by being the first one to connect in a channel. Probably not so good for other ircds or unregistered channels. I really like 3 though, I think that would work well. |
I think we should add some formal support for 'super users' or higher tiered users. This would allow for things like #44. Any ideas for a good way of doing this?
I was thinking a nice way of doing this would be passing a list of approved nicks as command line args and storing them as bot state accessible to any component. I'm unsure how nick clusters would be treated though. Not respecting clusters would be annoying, but respecting them could be a security hole.
The text was updated successfully, but these errors were encountered: