MSTR - an Administration Extension

[darkKlor]

Building on the whole REG command, a few people said they'd like to see an extension for other administration tasks. So, I made this attached document. The REG command in it may be trying to do a bit too much, and the BAN command doesn't look very clean (and it's missing the pretty railroad diagrams), but it's a start.

Also, there's nothing about CTR in there. See the DSHub manual (http://sourceforge.net/project/showfile ... _id=239994), and this page: http://www.adcportal.com/forums/viewtop ... 95&start=0

Comment comment

[blastbeat]

the whole thing looks quite complex for such trivial thing like kick/ban. it also looks not very flexibel. whats about a "vip" user class or "svip" user class or "whatever hubowner xy wants" user class?

[Toast]

imho it should be a bit like aquila/dshub with granting system for management not specified classes. EM and CID an DE VE I4/6 etc are all good to use in a ban system preferably a full ban command that takes care of all of those variables ex. !fullban <nick>

I've never been a fan of VIP or SVIP/KVIP shit that stuff is just for hubowners with lazy ops. also banning share sizes seems unnecessary

[Pretorian]

• Is the idea that ADMSTR means that you support BAN, KCK, RDR, REG and PRM? That's a lot...
• Ban, kick and redirect are for some reason three commands. The hub is basically going to send a QUI in the end to the user, so the best thing would be to combine them all and add everything as an extension of QUI. (Granted, not everything will end up as a QUI, but for the most part...) Or, at least combine kick and ban since it's basically the same thing except different time.
• CT user classes in BAN cannot be -1 or 0 because you are allowed to combine values. Try and combine 0 with something and we'll see how you do. Normal user is no CT flag at all.
• It's probably simpler to use separate NItest1 NItest2 etc. That way you aren't trapped if someone uses ',' in their name... Etc etc.
• I don't understand why you're so keen on using "strings" when a simple integer will suffice. (ME, TY, TG flag for example.)
• There's no way to specify the QUI parameter DI as far as I saw...
• Personally, I got _really_ confused in the REG description, but maybe that's just me... Messages like "A message of type IF may include ME, PT and NT flags" are, unless you know everything by heart, very difficult to remember. Plus, why not have e.g. the ME parameter be RT for RequiredType? AP for Account Portability. Etc etc.
  (I basically gave up at REG since I got so confused/bored.)

[darkKlor]

Thanks for all the comments!

CT user classes in BAN cannot be -1 or 0 because you are allowed to combine values.

I've always assumed 0 is a normal user. I thought it was odd that the spec had nothing explicit though. And yes -1 does pose a bit of a problem, though I would suggest that somebody who is a 'limited user' is not going to be an operator or anything. In any case, it made far more sense to me to put a limited user at the lower end of the spectrum, not at 64 or 128 above hub owner, and ullner seems to think 64 is used but not in the spec... okay.

CT does not offer much flexibility in setting the user level, yet it seems to be intended for that task. As blastbeat said, what about a VIP or "whatever hubowner xy wants" class. Well, I know my hub allows 256 user classes, but the way I do it is that each user is assigned a RoleId, with Role 0 being the hub. It's not linear like YnHub or other systems either, because each Role is a child of another role, and a user can only be kicked etc by a user with a higher level in the hierachy. Thus you can have Operator as a child of Hub Owner, with Moderator and SuperVIP as children of Operator. A SuperVIP might have fewer powers than a moderator e.g. no kick, but a Moderator cannot kick a SuperVIP because they're both an equal distance from the common parent, Operator. An Operator could kick both a Moderator and a SuperVIP. Anyway, that's just the way I do it. Everything has to be slotted into the CT flag when I send it to other users though.

Or, at least combine kick and ban since it's basically the same thing except different time.

There were a couple questions on why BAN and KCK are two commands. Well, because they do totally different things! The BAN message is aimed at preventing users from using certain values that are reported by the INF message, so you cannot call yourself something offensive, or have something offensive in your description. It can also be used for banning certain clients, and setting minimum and maximum share sizes (yes I see no reason in banning specific share sizes, I had ranges in mind. It probably should also include a CT parameter, come to the of it, so that you can apply the bans to different user levels (or somehow say all levels too). That would allow for things like a minimum share size for registered users, but no minimum for operators. The maximum share size would usually be -1 i.e. infinity I think, but I wanted to allow flexibility.

The KCK message is for kick/ban/drop of users. I read this post by Poy http://dcpp.wordpress.com/2009/06/15/dc ... osyncrasy/, but varyied it slightly. From the table at the bottom of his post, I used the 'rest of the world' terms, except for the last row, where I used 'drop'. So, Permanent ban=ban, temporary ban=kick, drop=drop.

In regards to QUI, yes there is overlap there for KCK and RDR. The BAN message is mostly unrelated to QUI, unless an existing user has one of those values, in which case they will be dropped. KCK adds the ability to select the way in which a kick/ban should be implemented by the hub, RDR allows all users to be redirected with one command (if you had 500 users and needed to move them all, do you want your client to pump out 500 different QUI messages?). I guess my main reason for two new messages is that their name is indicative of what they should be used for! The QUI command name suggests it relates to users quitting, but it actually takes care of users involuntarily quitting, and never being able to return, or going off to another hub. But yes, there is an argument for extending QUI. I guess the main thing is that clients should actually make use of it! Like, I'm hub owner in a hub and Apex isn't giving me the option to kick or redirect anybody, I have to type !kick somebody.

It's probably simpler to use separate NItest1 NItest2 etc

Good point with the comma's. I wanted to allow multiple values at once and be reasonably easy to parse on the hub side. I guess it isn't much difference though. I just saw that INF SU was a comma-delimited list and I was like yeah that sounds good.

I don't understand why you're so keen on using "strings" when a simple integer will suffice.

Fair call. I guess it's meant to just make it easier to read than having to refer to a table in the protocol when you wanna decrypt a message. Like, hmmm what does REG TY3 mean? But yeah it should only be developers reading the raw protocol shouldn't it.

RE: REG. Yes, it's huge, too huge. Just from the ridiculous number of railroad diagrams, there's too much indirection. In one document I managed to create commands that both do very similiar things, and do everyyyyyyyyyyyything

At least people bothered commenting though. I see ullner was going a bit nuts in DCDev (at least it read that way), but I think if nobody actually types up proposals that people can comment on then nothing will happen. ADC started drafting over 6 years ago, and has been official for 18 months, and still we have the case where the clients don't use all of it (kick not in the menu options etc) and the hubs can... leave a bit to be desired for a hub owner/operator who just wants life to be easy. I don't care that ullner sounded like he had a hernia, but I do think that proposals should be ENCOURAGED. After all, they are just proposals. Nobody is saying you have to go and write code for all this crap until it gets to the point that everyone can agree on it. Even then, it's an extension. You have the freedom not to support extensions

[Pietry]

but I do think that proposals should be ENCOURAGED

I totally agree. Good work darkklor

BTW did you ever look about the extended commands I implemented in DSHub?
Something like
!kick share<1000
or
!kick rg=1
!kick SU!ADCS
!kick ni>30
and so forth
I think the end result of this commands are quite obvious
also using regular expressions
!kick \[RO\].*
for example.

[darkKlor]

BTW did you ever look about the extended commands I implemented in DSHub?

Oooo I did not!

So it's like [field][comparison operator][value]. Not too difficult to parse I guess, although having just looked at your code file and it's 1000 lines, maybe it is I like the idea, but I think the code required to implement that needs to be a little shorter for others to consider it. It's at http://bazaar.launchpad.net/~vcs-import ... jvymr1zr-5 for those playing at home. I kinda think that a function longer than 50 lines is too hard to handle, so it should be broken into sub-functions Also, I'm surprised you didn't use a regular expression for the actual parsing.

But back to the point... that would certainly be something that would give the KCK message more meat!

[darkKlor]

@Pietry:
This code should parse a parameter with a two letter field name, an =, < or > symbol, and a value e.g. NI<sup, SS>30. It assumes a seperate function GetFieldValue(user, fieldname). It's not brilliant, or as complete as the DSHub command, but I think overall the code would be much shorter

Code: Select all

            Regex kickRegex = new Regex("(?<field>[a-zA-Z]{2})(?<operator>(?<equal>=)|(?<lessthan><)|(?<greaterthan>>))(?<value>[a-zA-Z0-9]+)");
            Match regexMatch = kickRegex.Match(inputParameter);
            if (regexMatch.Success)
            {
                foreach (string user in hubUsers)
                {
                    string fieldValue = GetFieldValue(user, regexMatch.Groups["field"].Value);
                    int compareResult = string.Compare(fieldValue, regexMatch.Groups["value"].Value,
                        System.Globalization.CultureInfo.CurrentCulture, System.Globalization.CompareOptions.IgnoreCase);

                    bool caseMatched = false;
                    if (!string.IsNullOrEmpty(regexMatch.Groups["lessthan"].Value))
                    {
                        if (compareResult < 0)
                        {
                            // is less than
                            caseMatched = true;
                        }
                    }
                    if (!string.IsNullOrEmpty(regexMatch.Groups["greaterthan"].Value))
                    {
                        if (compareResult > 0)
                        {
                            // is greater than
                            caseMatched = true;
                        }
                    }
                    if (!string.IsNullOrEmpty(regexMatch.Groups["equal"].Value))
                    {
                        if (compareResult == 0)
                        {
                            // is equal to
                            caseMatched = true;
                        }
                    }

                    if (caseMatched)
                    {
                        // call or queue kick function
                    }
                }
            }

[Pretorian]

Psst. I'm ullner...

I've always assumed 0 is a normal user. I thought it was odd that the spec had nothing explicit though. And yes -1 does pose a bit of a problem, though I would suggest that somebody who is a 'limited user' is not going to be an operator or anything. In any case, it made far more sense to me to put a limited user at the lower end of the spectrum, not at 64 or 128 above hub owner, and ullner seems to think 64 is used but not in the spec... okay.

Using <param><number> does not mean simply <param> (in this case 0). That goes for all flags in the protocol. However, as the CT is specfified as it is, well, there's not much you can do about 0 or negative values. Also, I wasn't entirely sure about CT64. There's a fair chance that it's not reserved by any other developer. I haven't given any proof that it's actually reserved (hoping that someone else remembered or found out), so go nuts.

CT does not offer much flexibility in setting the user level, yet it seems to be intended for that task. As blastbeat said, what about a VIP or "whatever hubowner xy wants" class. Well, I know my hub allows 256 user classes, but the way I do it is that each user is assigned a RoleId, with Role 0 being the hub. It's not linear like YnHub or other systems either, because each Role is a child of another role, and a user can only be kicked etc by a user with a higher level in the hierachy. Thus you can have Operator as a child of Hub Owner, with Moderator and SuperVIP as children of Operator. A SuperVIP might have fewer powers than a moderator e.g. no kick, but a Moderator cannot kick a SuperVIP because they're both an equal distance from the common parent, Operator. An Operator could kick both a Moderator and a SuperVIP. Anyway, that's just the way I do it. Everything has to be slotted into the CT flag when I send it to other users though.

I fail at seeing the real world usage of 256 user classes... Will there be a hub with 256 users with different power, all of which you (hubowner, operator etc) should maintain? I can tell you right now that that will be a nightmare.
In any case, you could always use an additional flag -- your Role ID. CT for "operator" and "Role ID" for "this particular type of operator". (Here you can even use RIdark_sith_lord etc.)

Fair call. I guess it's meant to just make it easier to read than having to refer to a table in the protocol when you wanna decrypt a message. Like, hmmm what does REG TY3 mean? But yeah it should only be developers reading the raw protocol shouldn't it.

I understand what you're saying and the idea, while I don't agree. Also, while perhaps not needed in TY, it can be used in REG ME (which is annoyingly strange naming, but I digress) to be combined as CT is.

[Pietry]

I kinda think that a function longer than 50 lines is too hard to handle, so it should be broken into sub-functions Also, I'm surprised you didn't use a regular expression for the actual parsing.

I was lazy at the time and copy paste was a shorter solution. The coding was not done with performance in mind, I just wanted to see if it would work and how it would fit into the scene