Rizon Features Expansion Discussion

It is the hope of this thread, to allow the Rizon community to suggest new ideas and or modifications to the current structure of irc.rizon.net. It is my desire that any and hopefully all noteworthy suggestions be met with appreciation, open mindedness and meaningful discussion. The only rule I would like to suggest is that only one idea be discussed at a time; allowing for a full discussion on that particular idea. Discussion of that idea will be concluded when a Rizon Developer or Administrator with equal influence or power, states that the particular idea has been received and is being reviewed for possible implementation; with the converse being that the particular idea has been examined and rejected with relevant reason or reasons being stated for the rejection. Once an idea has been closed or concluded, it can only be reopened under the discretion of a Rizon Developer or Administrator. I hope that we all can adhere to this policy and partake in meaningful discussion of the community's ideas.
For ease of reading all ideas (where possible) should follow the format that is to follow.

Title of Idea/Suggestion/Modification: BotServ Modification
Nature of Idea/Suggestion/Modification: Modification of BotServ features and inclusion of new command(s)
Description of Idea/Suggestion/Modification:
BotServ allows users to have a bot on their channel. The current policy of Rizon is that a user can request a custom botname if they have 500 or more users in their channel. However some small channel owners may want use of a bot and also would like the option of having that bot utilize a particular botname; this is where this idea/suggestion/modification could be used.
I would like to suggest to Rizon, to have only One (1) Bot available on BotServ (for example the Rizon Bot). A user (upon having the Rizon Bot join their channel) can then utilize a command to change the nick of the bot. For Example:
->BotServ: Bot Rizon has joined #channel
->User: /msg BotServ botnick #channel RizonServ
->BotServ: Bot Rizon nick has changed to RizonServ
With this method, a question surely would arise: "How do we stop users from choosing nicks that they shouldn't be allowed to use, or for that matter gaining nicks that are already in use?"
It is my belief that the above issue can be easily dealt with. What if, the very process of changing the bot's nickname is akin to BotServ asking NickServ to register the nick, but registering the nick to a channel and not an individual or actual person. Thus the very nick constraints that are placed on users when attempting to register a nick would be placed upon BotServ's attempt to change the bot's nick. An equivalent algorithmic example of this process is described below.

.. Begin
1. BotServ Bot joins the channel
2. User uses the command to change BotServ Bot's nick
3. BotServ asks NickServ if the nick is available for use:

If Available (i.e. Not in use, not registered, or not available for use) GoTo 4
If Unavailable - Tell user nick cannot be used - GoTo End

4. Nick is available for use:

BotServ makes a request to NickServ to make the given nick unavailable for use (as it is now registered to a channel service)

5. BotServ Bot's nick changes to user's custom nick
.. End

I am also of the belief that the same or similar process can be applied for users wishing to change the hostmask of the BotServ bot. The ident of the bot will always be static and CAN NOT be changed by the user (e.g. RizonServices@*.*). The hostmask is subject to the same rules governing VHosts from HostServ.
Example Commands for Idea/Suggestion/Modification:
Rename Command - /msg BotServ BOTNICK <channel> <NewNick>
Hostmask Change Command - /msg BotServ BOTHOST <channel> <NewHost>
( where NewHost is everything after the '@' e.g. BEFORE: RizonServices@Channel.Services.Rizon.Net ---- AFTER: RizonServices@Wow.This.Is.Cool )

------------------

I am eager to have discussion on this idea, as it is my belief that this would be a wonderful and unique addition to an already unique and wonderful Rizon
experience.

------------------

Miikaii <--> Miichiio
#infaxel.net@irc.rizon.net
"Hoping business class features can be given to coach. Enjoy flying Rizon."

Hi there,

1. Number of users required to request custom bot is now 150 or more.
2. Its not possible to make one bot with many nicks, botserv clients are from server point of view another user on another server (in this case on services one). So if there is only one bot, there will also be only one nick. And the reason we have so many to pick from is because there are a lot of big channels with their own custom bots. If you would rename bot as you propose it would rename it network wide on all channels and I doubt all founders on rizon would agree to have one and same bot. Another thing is that there is no point in making custom bots for small channels that are not used much and there is high chance for chan to be dropped.

Regards,
Celestin
Rizon Dev Team

my vote would be to drop botserv, as long as you can do .op .deop .kick the rest is just vanity and overhead.

unless someone can provide me with a good reason they need services to be named something other than chanserv when it ops or kicks people....

Firstly, I would like to say thank you Celestin, for your speedy response. Secondly with regards to the amount of users a channel must have to allow a custom botname being defined from 500 to 150; I humbly suggest that the post found here http://www.rizon.net/vbulletin/showthread.php?t=23 by Gemini be edited to reflect this change so as to avoid any future possible confusion by community members.

With respect to your second point, I will be under the assumption that bots defined on BotServ, under the current implementation, are defined statically. What I am proposing, is that a single bot template (a basic class structure so to speak) be statically defined on BotServ. When an instance of that bot template is created (i.e. joins a channel) a dynamic bot is then created based on the template (an object of the template class) that can be manipulated by user. This instance of the bot would be independent of another instance on another channel. In other words, modifications made to bot instance on channel x will have no effect on bot instance on channel y and have no effect to the statically defined single bot template on BotServ. I believe that this method would ensure that only one (1) static bot on BotServ will be able to service dynamically almost every channel on Rizon.
The dynamic manipulation of the instantiated bot on any channel however, will be limited only to the manipulation of bot names/nicks and their associated hostmasks. All other bot behavior would be governed by the template's rules.

As I am not an accomplished programmer and not entirely familiar with the intricacies of developing and maintain an IRC server(s); I will be looking to you (Rizon Developers) to guide myself and others like me who wish to assist in flying Rizon even more comfortable and enjoyable.

------------------

Miikaii <--> Miichiio
#infaxel.net@irc.rizon.net
"Hoping business class features can be given to coach. Enjoy flying Rizon."

I agree with mink, and would actually be in favor of it disappearing myself.

BotServ is not needed for anything besides the "look, we have a kewlz0r bot in our channel!!" factor. People can't gain ops in registered channels just by joining them, so a BotServ bot does not protect your channel. ChanServ can accept a full range of commands via /msg, again making BotServ unneeded.

Quote:

---

Originally Posted by SecretAgent

I agree with mink, and would actually be in favor of it disappearing myself.

BotServ is not needed for anything besides the "look, we have a kewlz0r bot in our channel!!" factor. People can't gain ops in registered channels just by joining them, so a BotServ bot does not protect your channel. ChanServ can accept a full range of commands via /msg, again making BotServ unneeded.

---

Agreed there is no need for botserv when chanserv can take it's place... BotServ introduces additional services clients and causes more stress on services during burst... I would be in favor of deprecating botserv if anything over adding a command to allow more bots.

Quote:

---

Originally Posted by Miichiio

With respect to your second point, I will be under the assumption that bots defined on BotServ, under the current implementation, are defined statically. What I am proposing, is that a single bot template (a basic class structure so to speak) be statically defined on BotServ. When an instance of that bot template is created (i.e. joins a channel) a dynamic bot is then created based on the template (an object of the template class) that can be manipulated by user. This instance of the bot would be independent of another instance on another channel. In other words, modifications made to bot instance on channel x will have no effect on bot instance on channel y and have no effect to the statically defined single bot template on BotServ. I believe that this method would ensure that only one (1) static bot on BotServ will be able to service dynamically almost every channel on Rizon.
The dynamic manipulation of the instantiated bot on any channel however, will be limited only to the manipulation of bot names/nicks and their associated hostmasks. All other bot behavior would be governed by the template's rules.

---

There may only be one client with a particular nickname on the network at any one time, this is for sanity reasons. Any changes to a client's nickname will be propogated across the network to ensure things stay synched. It won't be limited to any one channel.

Basically, from what I gather, you are proposing that a channel be able to create and use it's very own BotServ client exclusively. The sheer amount of services clients alone that this would create makes it rather undesirable. It just uses more of our resources for no actual point

Quote:

---

Originally Posted by SecretAgent

Basically, from what I gather, you are proposing that a channel be able to create and use it's very own BotServ client exclusively. The sheer amount of services clients alone that this would create makes it rather undesirable. It just uses more of our resources for no actual point

---

I understand your point and I do agree with your conclusion. Truthfully I was already fully aware that an implementation such as I have suggested would have the ramifications you alluded to. However I am an advocate of customization and I am still of the belief that such a feature would be a great addition for BotServ; concurrently the process as I have defined may not be the optimum method for this idea as you have shown. With regards to this matter I will continue to think of ways to reinvent this idea.

With regards to the complete abandonment of BotServ however, I cannot be in total agreement with that conclusion. Simply BotServ still holds or carries with it a certain level of necessity and functionality currently not provided by ChanServ (such as flood control; kicks for excessive repeats, bolds etc.). If users are aware of this and if they are utilizing this functionality is a different matter.
What I can agree on, is if all BotServ's functionality is integrated within ChanServ (including flood control etc.) that would increase ChanServ's functionality and flexibility exponentially, whilst reducing the overhead costs associated with the separate BotServ.

------------------

Miikaii <--> Miichiio
#infaxel.net@irc.rizon.net
"Hoping business class features can be given to coach. Enjoy flying Rizon."

Just to clarify, botserv bots are not static in config file, they are dynamic. Just ability to modify botserv list is limited to services administrators. They are already templated and thats why they can be added fast as soon as your channel meets required user count.

Quote:

---

Originally Posted by NiTeMaRe

BotServ introduces additional services clients and causes more stress on services during burst...

---

Uhh not really, those are services clients introduced by services to rest of the network, and its only one line to do so (UID) so its not making any impact on services from burst, because its services that burst it to network not network to services ;)

Not entirely, it must also use SJOIN to introduce those clients to channels during a netburst, but that isn't all that burdensome.

The biggest issue is that BotServ requires channel traffic to go through services, for little gain IMO. This wouldn't change if we were to incorporate BotServ features, such as badword lists, into ChanServ. However, it would be one service, making it more practical from both a development and end-user standpoint.

Services act as server and as such they get channel traffic anyways, it just depends what they do with it

Quote:

---

Originally Posted by Celestin

Services act as server and as such they get channel traffic anyways, it just depends what they do with it

---

Not necessarily.

Services would not receive channel traffic (e.g. messages) if it did not hold clients in those channels. Of course, since it is linked as a server, it would still receive JOINs and TMODEs, which is why it's not necessary for ChanServ to be in channels, as I'm sure you're aware.

That is the real "overhead" BotServ introduces compared to ChanServ, which is what I was getting at, though I don't see it as a huge issue, as it would remain if ChanServ were to integrate some of the functionality BotServ currently provides.

Quote:

---

Originally Posted by Miichiio

I understand your point and I do agree with your conclusion. Truthfully I was already fully aware that an implementation such as I have suggested would have the ramifications you alluded to. However I am an advocate of customization and I am still of the belief that such a feature would be a great addition for BotServ; concurrently the process as I have defined may not be the optimum method for this idea as you have shown. With regards to this matter I will continue to think of ways to reinvent this idea.

With regards to the complete abandonment of BotServ however, I cannot be in total agreement with that conclusion. Simply BotServ still holds or carries with it a certain level of necessity and functionality currently not provided by ChanServ (such as flood control; kicks for excessive repeats, bolds etc.). If users are aware of this and if they are utilizing this functionality is a different matter.
What I can agree on, is if all BotServ's functionality is integrated within ChanServ (including flood control etc.) that would increase ChanServ's functionality and flexibility exponentially, whilst reducing the overhead costs associated with the separate BotServ.

------------------

Miikaii <--> Miichiio
#infaxel.net@irc.rizon.net
"Hoping business class features can be given to coach. Enjoy flying Rizon."

---

to clarify all of botserv's functionality would be transferred to chanserv of course.

Esteemed representative of semi-aquatic and carnivorous mammals (Mink):

I am extremely distraught by your consideration of terminating the BotServ services. Should these reveries materialize, my beloved FaceBot [^_^] will be forever silenced, leaving me with a single faithful cohort (Abba-Zaba, in case you were wondering) to brave the perilous nodes which fabricate the Rizon Chat Network. I am, however, willing to oblige your merciful regard: A package containing a delicious imported panettone and several autographed 4x6 portraits of myself will soon arrive at your place of residence. Similar arrangements may continue to exist over the years should you find it to your amusement. I hope this short message and gesture of kindness will find a place in your heart and mind this holiday season.

Amicalement.

Kiwiclx, Rizon's resident fruitbirdthing and former Rizon staff overseeing the splittiest of hubs