Community moderators

[Lucifer]

Ok, in the spirit of apparition's comments about development talk being too technical for some people's interest, the community moderator discussion is being forked here for technical discussion. If you need to link to continuing posts in the other thread, please do so.

http://forums.armagetronad.net/viewtopi ... 799#203799

So, going off z-man's last post in that thread, what tools need to be provided to allow community moderators to exist? What tools will server admins need to be able to include community moderation lists in their servers?

[Lucifer]

Heh, replying to myself. I have a few more questions.

How often does banlist.txt get loaded? Last I heard, it only got loaded once, at server startup. Would it take much to make it load more often, like between rounds? Or better yet, just make two console commands to flush the banlist and reload it and then server admins can put that in everytime.cfg after flushing the current list, and then loading a new list.

While at it, could it be made to support more than one banlist file? Then a server admin could use a cronjob and wget to download from a webserver. All we'd need to provide, then, is a way for self-appointed community moderators to upload and/or maintain their banlist files. It does set a minimum time before a ban goes into effect of "until the next round starts, you can keep behaving like a smeghead".

What other options are there without code changes to arma?

[Z-Man]

How often does banlist.txt get loaded? Last I heard, it only got loaded once, at server startup.

Yep, but banlist.txt is the wrong tool It's for automatic bans or bans remote moderators put up that need to be persistent between server sessions. What we want here is a one or serveral configuration files containing BAN_IP lines with reasonable timeouts (one hour to one day) that just get included by everytime.cfg. There's no way to flush the IP ban list (and it wouldn't help here anyway, because doing so every round would flush the ad-hoc bans), but setting a timeout works just as well. It just needs to be tuned to be longer than every round, but short enough so ban removals get applied in a reasonable time. There's also BAN_USER to ban users via their global ID, if they send it. That one needs a UNBAN_USER_ALL command, it doesn't support timeouts.

For server admins: yep, wget and cron, and possibly our list merge tool. RINCLUDE doesn't work because it caches the include indefinitely, and a modified RINCLUDE that doesn't cache doesn't work because it would risk blocking the server for too long between rounds. Hourly to daily updates of the ban list should be enough.

For moderators: also yep, a place for them to host their lists would be useful. They probably would all be able so self host their lists, but having them all in one place would make things easier.

I wonder, would one giant bzr branch work? We could create a team for it on launchpad, make it self-moderated (have it be its own owner, if possible) so its members can approve new moderators, put all ban files into a bzr branch owned by that group, let server admins fetch the files via bzr pull (has the advantage that it's just one operation for all files). Technically, moderators could then change other moderators' files, but that's something one can deal with via policies and hanging violators upside down by their balls.

Oh yeah, the lists shouldn't be plain arma config files. We should guarantee that the banned user gets information on why he was banned. So the moderators should just publish lists of IPs (with comments containing usernames and information about the ban reasons or pointers to that information), metamoderator lists are just references to moderator/metamoderator lists, and some to-be-written merge tools then compile a ban list where the message to the user says something like "You have been banned by the trust chain X (moderator issuing the ban), Y (metamoderator trusting that moderator), Z (meta^2moderator). If you believe this is in error, please appeal to them in the given order."

[compguygene]

This is the kind of tool I thought that I would find in the banlist.txt file.
Z-man...it sounds in general like you have the right idea for what we would need to implement bans of this nature.

[Z-Man]

I created the team on launchpad: https://launchpad.net/~armagetronad-moderators

Problem is, self-moderation is not going to work. I think. IIRC, only the team owner can approve or reject join requests. So to allow everyone to approve a new member, one would need to make everyone team owner. And then everyone can hijack the entire team, if it's possible at all. So now the team is just open for everyone to join, which means we would not be able to put everything into one big branch writable by the whole team.

Soo, alternative suggestions for helping people host their lists?

[Luke-Jr]

RINCLUDE AAMods/banlist-LATEST.cfg

[wrtlprnft]

RINCLUDE doesn't work because it caches the include indefinitely, and a modified RINCLUDE that doesn't cache doesn't work because it would risk blocking the server for too long between rounds. Hourly to daily updates of the ban list should be enough.

[Luke-Jr]

RINCLUDE doesn't work because it caches the include indefinitely, and a modified RINCLUDE that doesn't cache doesn't work because it would risk blocking the server for too long between rounds. Hourly to daily updates of the ban list should be enough.

The "LATEST" version spec would fix the first problem, though I admit I missed the second bit. Would embedding a simple cron-include engine be too extreme (eg, RINCLUDE it once an hour instead of everytime)?

(Note the "LATEST" redirectors would only download the file if it had changed since the last change)

[wrtlprnft]

Well, whether you send a GET or a HEAD request (to determine if the file changed) doesn't make a difference if the server's busy or otherwise not reachable.

OTOH we already have zthread, so RINCLUDE could just spawn a thread.

[Z-Man]

The "LATEST" version spec would fix the first problem, though I admit I missed the second bit. Would embedding a simple cron-include engine be too extreme (eg, RINCLUDE it once an hour instead of everytime)?

I don't think it would. In fact, I think the request for a once-per-match include file bubbles up at times. Timed includes aren't too far off from that.

The drawback of a simple RINLCUDE is also something else If you RINCLUDE a complete configuration file, you need to trust the creator enough that he won't mess with your server by, say, including himself as admin at a later time. And it requires that metamoderators upgrade their merged configuration files every time their source lists change (although a recursive RINCLUDE would do the job if we decide we don't need the chain of trust info in the ban message and a "you were banned by moderator X" message suffices).

A second resource repository specially for those config files where you're limited to upload scripts containing BAN lines would solve the trust issue. And the update issue if it lets the user only edit ban lists or include lists and autogenerates full config files itself.

Is LATEST implemented already?

[nsh22]

ok, stupid question #1: is all this talk having to do with features in armathentication or something else.

stupid question #2: would it be hard to make a mod to an armathentication version that would give mod status to somebody on all of the servers with that version? if so, it would allow anybody who wants their server modded by the community armatrator and a global ban list to jus t get that version of armathentication.

[Z-Man]

ok, stupid question #1: is all this talk having to do with features in armathentication or something else.

No, it's independent and can work on non-armathentication servers just as well.

stupid question #2: would it be hard to make a mod to an armathentication version that would give mod status to somebody on all of the servers with that version?

No, that would be easy, but distributing said version requires all the work of distributing a regular release, and more: all the hack branches would require the same treatment. Then again, a modified configuration works just as well.

if so, it would allow anybody who wants their server modded by the community armatrator and a global ban list to jus t get that version of armathentication.

That would only work if the server never restarts. Everything the Armatrator (<- <3) sets up gets lost on server restarts.

[nsh22]

aw oh well...
what about putting a banlist on some kind of repository and then haveing the server load that list after every round?

[Lucifer]

There also needs to be a way for armatrators to get the IP address. Putting up a config file is "good" for that, I think, because then a particular armatrator could have extra lines giving him whatever he needs to see an IP address.

Ummm, a little python script that runs on the server, downloads a file from a webserver, and then *writes* it into a .cfg format file should be pretty straightforward. It's not a 10 minute job, but an hour or so, maybe a bit longer.

I could probably snag some code from my current top secret project and slap together a web interface to serve these files and allow armatrators to maintain their lists or just upload the files. I'd be willing to host, but right now my hosting situation shouldn't be considered reliable.

Anyway, then the server admin could just put the appropriate include in everytime.cfg, and run the python script in a cron job. Or remove remote retrieval from the script and use a bash script to do the retrieval (makes the retrieval method extremely flexible ).

[Z-Man]

For the IP viewing: we left room in the authentication level table for stuff like that. We could add Armatrator one or two steps below Moderator. Then lower the IP/Authentication ID viewing default rights down to that level and make it so that if a server admin directly or indirectly trusts an Armatrator, (s)he'll be given the Armatrator access level in the generated .cfg file. A more fine grained permission system would be useful here (Armatrator < Team Leader in some respect), but it'll have to do for now (/me feels a blueprint coming up)

I'd be willing to host, but right now my hosting situation shouldn't be considered reliable.

I have that shiny new VPS and for this kind of task, at least for read only backup purposes, my small home server would also be suitable. Tell me what you need.

If said serverside script could be pure python, that would be ace; then it'd also run on Windows and we'd have less of a reason to be hated by Windows using server admins.