Closed pcho closed 2 years ago
I'll leave this issue open in case other people have thoughts, but in general, features like this are out of scope for Ergo. I only work with NUH masks and the like when they are unavoidable legacy features provided by other IRCds. All new feature development has to go through the accounts system.
I think that ChanServ is a service. Therefore, if ChanServ is going to exist within ergo, maybe it should be something that one can turn off if you want to minimize the scope of what ergo does. My point is that, as it is a service; I think simple features like this are certainly within reason.
Furthermore because ChanServ is built in, and as far as I know, not something you can disable; it becomes even more important that simple features like this are allowed to be implemented. I say this because ergo isn't exactly friendly to/built for easily implementing/accepting an alternative ChanServ implementation.
Maybe a plugin system would be a proper solution :)
I say this because ergo isn't exactly friendly to/built for easily implementing/accepting an alternative ChanServ implementation.
I was thinking about something like this as it would be great to have access to database and services by third-party developers for creating add-ons. For example RSS service that could be tied with ChanServe so owners could invite it to channel, add sources, some basic configurations, and that's it.
Same with other stuff like URL titles, YouTube, GitHub (it would be nice to have an advanced GitHub add-on), Zoom or anything other. Each add-on could be published and installed by simple manager govern by Ergo.
I believe it could be a nice feature for business that think about moving to something easier than Slack as Ergo + The Lounge is a great replacement for it.
But found this: https://github.com/ergochat/ergo/issues/234 and don't really think anyone would be interested in building or maintaining it. :-)
Also found this which could be used as a scripting language for Ergo plugins: https://github.com/d5/tengo
Furthermore because ChanServ is built in, and as far as I know, not something you can disable; it becomes even more important that simple features like this are allowed to be implemented.
Chanserv can be disabled by setting channels.registration.enabled
to false
; if there are no registered channels, then all Chanserv actions are no-ops. But in this case, there is no CS AMODE
either.
Ergo does not really attempt to preserve the traditional separation between "IRCd" and "services"; ChanServ is part of the "core functionality" of Ergo that is implemented natively (although it can be disabled, as mentioned above).
It might make sense for Ergo to have a collection of recommended/endorsed bots providing functionality like this that we don't want to bring into the core?
Chanserv can be disabled by setting
channels.registration.enabled
tofalse
;
This indeed changes everything, then. I didn't think of it quite like that. I like your idea then for sure.
I was thinking about something like this as it would be great to have access to database and services by third-party developers for creating add-ons. For example RSS service that could be tied with ChanServe so owners could invite it to channel, add sources, some basic configurations, and that's it.
Same with other stuff like URL titles, YouTube, GitHub (it would be nice to have an advanced GitHub add-on), Zoom or anything other. Each add-on could be published and installed by simple manager govern by Ergo.
Now you're definitely losing me... This is getting into just an IRC bot thing. Far beyond a services issue, likely none of this should be a part of the daemon.
On my instance I have users that do not want to create an account, yet I want them to have persistent status after reboots without using bots or client scripts.
Then with unique user hosts would it be easy to amode them up to &admin status?