So, I've actually been thinking about this off and on for the year or so that it's been proposed and added to the feature list for 0.4. As a result, I actually have a relatively mature design that's all in my head, never been written down, and thusly never shared. Sorry about that.
Politically, I believe the Player Police guidelines should be part of the moderator guidelines here on the forums. I think this because I expect that any server that is blessed as an "Official" server must subscribe to the player police and adhere to the policies involved, unconditionally. Private servers that wish to benefit from the system will be free to customize it according to their needs, but official servers cannot customize the Player Police. Therefore, behavior and expectations will be the same between the forums and official servers, but enforcement will necessarily be different because they are different mediums of communication.
I believe that all Player Cops must also be forum users. They must authenticate through the forums to be able to do their jobs as Player Cops, and any problems with individual Cops can and should be brought here and discussed openly. And the top of the chain of command for all official servers and these forums will be the Evil Triumvirate, but any decision to sanction a cop will still affect private servers using the system.
How is the above two paragraphs a part of design? I won't answer that right now, but it's obvious overlap between the other post someone needs to make.
Ok, how is the system going to be put together?
First, we'll need the resource repositories to host the config files and mirror them with each other. Banlists need to be synced amongst all official servers and the repo's, private servers need to be able to at least sync one-way (from the repo's to the server), but should sync both ways.
The config files must be designed as a hierarchy.
First, there will be a base config file, appropriately named "Player_police_base.cfg". All it will have in it is this:
Code: Select all
INCLUDE Player_police.cfg INCLUDE Player_police_users.cfg INCLUDE Player_police_local.cfg
This file also has to be included in everytime.cfg to ensure that changes to the system propagate.
This config file will define the access levels and what each access level can do. It is not to be edited by anybody using the system because it will be provided for you from the resource repositories, and any edits you make will be destroyed when the next update comes.
This config file simply lists the Player Cops and what access level they have. Since it's included before Player_police_local.cfg, private server operators can modify it, but again, official servers cannot override this file.
Private server operators can use this file to further customize their use of the system. Official servers can only customize if needed for technical reasons. This is the file you can edit to modify your use of the system. Also, official server operators can use this file to temporarily disable a Cop from being able to act if that operator believes the Cop's forum account has been compromised.
Syncing config files
Config files must be synced regularly, at least half-hourly. This allows changes to the config files to propagate, such as sanctions to Cops, and new Cops being added to the system. For POSIX server operators, you'll use a cronjob and a bash script provided. More discussion on the bash script below. For Windows/non-cron users, you'll have to find a way to do this on your own, but a batch file will be provided to do the heavy lifting, you'll only need to worry about making it update at least every half hour. Both shell scripts will become part of the game distribution, but will only be activated when server operators want to use them. And yes, I do intend there to be another 0.2.8 release if needed to get all this out there.
The banlist is different than the config files in that it has to be synced both ways: to the game servers from the repositories, and back to the repositories from the game servers. For the system to be effective, I propose that the sync must happen at least every 10 minutes, but suggest it should happen every 5 minutes, which would make it 10 minutes before a ban on one server takes effect on another server. Independent operators are free to choose longer intervals, but official servers must choose 5 minute intervals, or if a technical reason prohibits them from doing so, 10 minute intervals.
Obviously software will need to be added to the repositories to receive the banlists and reconcile differences automatically so that bans that happen to different people on different servers at the same time get preserved in the resulting file. I suggest that this software simply use a database to store the current banlist and render it as a text file when it's requested. That's what I'd do, anyway. It will be called often enough by game servers to also do maintenance work on the list, like removing expired bans from the list. If a permaban feature isn't currently in the game, then we'll choose a large arbitrary number that tells the banlist manager that it's a permanent ban so that it can mark the database entry accordingly and ensure that it always provides that ban to servers. It should return a time period for the ban suitable for the possibility that the game server requesting it might fall out of contact with it for a day.
If necessary, the game should be modified to reload the banlist between rounds, so the shortest amount of time it will take for a ban to propagate will be one round. I think this change has already happened, so this is probably a useless paragraph.
The sync system
The scripts that do the syncing need to do it in a particular way in order to ensure that the files they download are secure. First, the resource repositories should provide https services, preferably with a real certificate that can be verified through an authority, but can use an unverifiable certificate in order to ensure the encrypted transfer takes place. Regardless of the use of http, the scripts need to download the config files and banlist from two different sources, compare the files to ensure they are the same, and then copy the files into place in the server config directory.
I considered including a sha check, but realized it's just easier to download the files and compare.
The resource repository software will have to take this into account to eliminate the possibility of false negatives happening in case they're not directly in sync with each other.
The repositories should sync with each other at least on a half-hour basis. They should stagger their syncing so that they're not all trying to sync at once, so if we have three repositories, one would sync on the hour and at hour:30, one at hour:10 and hour:40, and one at hour:20 and hour:50, and so forth.
The repository software to manage all these files is the most challenging part of the system to implement.
Cops and their privileges
I propose three levels of Player Police: Deputy, Sheriff, and Detective, with their responsibilities as listed:
- A Deputy has access to kick and kill commands, but cannot ban anybody. They also only have jurisdiction on the server they're in at the time, meaning they can only enforce activity they see.
- A Sheriff has access to bans, but like the Deputy, only has jurisdiction over activity they see.
- A Detective has full moderator access, but has jurisdiction over all servers that subscribe to the system. That means that if something is happening in a server and there's nobody around to deal with it, a player can go find a Detective anywhere they can, be it another game server, these forums, the irc channel, or even a phone call, and ask them to come into the server to deal with the problem. A Detective has investigational powers to use as needed for the cases where a problematic person manages to escape before the Detective shows up. He can ask for log files from server operators, and server operators must give them. Detectives are awesome, we want lots of them, but we want to ensure that they are good, as well.
Now, when you have a problematic person and there are no Detectives available, but there is a Sheriff or Deputy, you can still find them and have them join the server. If the problematic behavior continues, they can act. If the behavior stops and the Sheriff or Deputy doesn't see it, they can't act, but they can file a report. That process is to be discussed in that other thread I mentioned.
This covers everything I've got in my head, with additions I thought up while writing it. So, discuss? Also, anybody willing to put together an initial implementation, I suggest you start with the config files and the sync system for those, put that out there for people to test, and worry about syncing the banlist second, rather than first. The first priority is forming the Player Police Force. The second priority is arming them with cross-server bans.
I'm also leaning towards adding the banlist and the sync to the master servers, but am nowhere near sold on the idea.
Edit: I forgot to add the part about the scripts and how they should manage the syncing, so if you read this and that part wasn't there, you have to go back and reread it.