MSTR - an Administration Extension

[Dj_Offset]

I have discussed this idea with darkKlor on the dev hub, and I must say, I really like this proposal if we can make it broad enough to be useful.
I think we then can write separate administration tools that ideally can be used on any hub adhering to the extension standard, which could include a common GUI for managing ban lists etc regardless of which hub is running.

I think there should be methods to list existing/effective ban rules, so they can be added and/or removed.
In addition I'd like a generic get/set configuration variable method, which has a similar list function. This way we can add a generic way to configure stuff with a get/set functionality.

[Pretorian]

I wrote the following on an airplane so below is entirely based off of the PDF and it's relatively incomplete in the end. Please bear this in mind since some stuff have been discussed previously.


I'm going to split this post in two parts. The first part will be my comments to the current proposal and I proceed to offer my modification as I see fit. The second part will be the modification but in the form that I'd have it in the spec, but without the annotations.

I do think that the command BAN is too complex and is trying to mix two concepts; setting hub restrictions and not allowing users with certain data. Now, it can be argued that the second concept is a subset of the first, but I think mixing the two in one command is simply confusing.

The command should therefore be split up in these two concepts.

The first concept I call "Hub restrictions" or "Hub information". The idea is that users send a "SHR" command (Set Hub Restrictions) that have the same parameters as the PING extension: min share, max share, max hubs etc. This makes it clear that the extension isn't about any specific user or client, but rather the general settings in the hub. Indeed, I suppose this command could instead be used in the more general for of "Set Hub Setting" (SRS). Revoking a parameter or setting the value to 0 (or no limit at all, depending on what you define) is done like elsewhere in ADC with no value on the parameter.

While a hub may send its restricitons or settings in its initial INF, it might be good to have a "Get Hub Restriction" (Get Hub Setting) command that simply asks for the SHR information. The hub should respond simply with an I-type SHR. If the GHR command has any parameters, then only those parameters should be sent in the SHR by the hub. Potentially, an INF could be sent out insstead of the hub's SHR, but I am leaning toward SHR since I think it's more consistent.

Splitting the information up into e.g. "min share" and "max share" avoids the problem of managing "><" etc.

These two commands could very well be split into a new feature altogether (with its own FCC), as they don't rely on the ability to kick or ban etc. Obviously, hubs will have to decide for themselves whether a user should be able to get hub restrictions (but they'll probably allow it since it's harmless) but only allow operators to use the 'set' command.

The second concept is the aformentioned "BAN"; the ability to not allow certain clients (or users) in a hub. Now, the information that a client provide that makes it worthwhile to ban is different from the information above. The typical information should be possible to ban on: ID, I4, I6 and NI. I am not decided on the ability to ban clients per se -- hubs shouldn't ban clients, only features.

Banning, kicking and redirecting users are very similar in concepts, and was so with the command QUI, which was removed from the base specification. I would therefore propose that the command QUI is instead used, with the potential additions of having regular expressions, ranges and revokation of a kick/ban. The commands KCK and RDR should definetely simply go away in favour of the QUI command. The QUI command (or whatever it should be called) should of course also manage offline users. Getting the banned users may instead be a parameter to the GHR command or something... (Obviously, it doesn't make sense that a client sends this "get banned users" command.)


The registration command:
The ME parameter only allow one type of registration, this should instead be a bitfield (same order as in PT) Combine to register with multiple ones.


SHR - Set Hub Restrictions
Should use the same fields as the PING extension does;
Min share
Max share
Min hubs
Max hubs

Example: "MS10" for min share 10 bytes.

To remove the current restriction, simply send "MS" (min share).

GHR - Get hub restrictions
GHR

Optionally, add parameters for those items you want

Hub responds with SHR... (all information unless specified in the GHR)


To actually ban a user or some type of information
BAN
NI, ID, I4/I6
If multiple, specify parameters for these
BAN NIjohn NIdoe