Been thinking about this more today. Thinking about adding hmac or public/private key signing to the messaging, etc. however the problem that no one's brought up is the automated banning issue.

The master server counts bans - there's a massive potential for a master ban to happen if someone gets banned on one server. I'm not sure that there's really a fix for that... in a public setting

It would be really easy to spoof a report to a public Thor + Mjolnir mesh, and it would only take a few server admins running Mjolnir and accepting all bans before the LFS master server ban would kick in - basically a really easy way to get the LFS master server to ban a user. That said it could be done very easily anyway. Surprised that doesn't happen more often...

I was really hoping to come up with something less embarrassing, but implementing all this turnen up to be a bit more painful that I expected. As of now it doesn't really do anything useful, but it can catch a banned player in LFS and pass this information along to other peers.

I believe that the design is modular enough to implement communication over Gossip protocol (I'd love to make this compatible with Thor-Mjolnir system), all kinds of local storage (text file, SQL, whatever) etc. The peer-to-peer communication is implemented through OpenSSL, so verification and encryption should be easy to add later.

Bear in mind that this is more of a "how I think it could be done" kind of demo. It's pure C++11 with OpenSSL, but it currently won't build on Windows (changing #define CIS_LINUX to CIS_WINDOWS /cinsim.h/ and replacing pselect() with select() /insslconnection.h/ should get this sorted though).

@TAA: I've been thinking about the master-banning problem and I guess one way to at least reduce this possibility would be to introduce ban "severity". Admins would then choose what level of severity will result in autoban on their server. Maybe some sort of "time-to-live" property could be used too, for instance the more peers "away" the ban origines, the less "credible" is considered (hope you know what I mean )
IMHO a global ban system needs to be something more complex than a web of banned usernames.

I haven't paid attention at this really but I'd think a key feature that should be in a global ban system would be for server owners to verify offenders' offense.. So you when catching a player being banned the system should request a replay from the server and store it for 'evidence'. Otherwise a global system like that would end up a huge cluster**** where no one knows why people are being banned.

Quote from MadCatX :

I believe that the design is modular enough to implement communication over Gossip protocol (I'd love to make this compatible with Thor-Mjolnir system), all kinds of local storage (text file, SQL, whatever) etc. The peer-to-peer communication is implemented through OpenSSL, so verification and encryption should be easy to add later.

ooooooh, shiny I shall give it a bash

Quote from MadCatX :

@TAA: I've been thinking about the master-banning problem and I guess one way to at least reduce this possibility would be to introduce ban "severity". Admins would then choose what level of severity will result in autoban on their server. Maybe some sort of "time-to-live" property could be used too, for instance the more peers "away" the ban origines, the less "credible" is considered (hope you know what I mean )

That's what I've ended up thinking. As nice as a distributed database of names is, you're totally right

My issue with that is that there's no way to allow server admins to continue using existing tools - to get information about the ban, a whole in-game button system or external toolset needs to be used. I don't think that's necessarily a big problem, but it's still a [small] barrier to adoption

Will be honest I've not given this much thought yet.. I'm sort of jotting down what few things have come to mind.

I will be honest I was hoping to be able to come up with something that allows you to cherry pick, purely based on how much you trust other server admins to do "the right thing". I wanted to avoid the human cost of maintaining the UKCT barrier system that SamH, etc. ran a few years ago =/ I might be taking it to the extreme though

@MadCatX Checkout [telehash](http://telehash.org/).. It's a bit more sophisticated than gossip. There's a basic C library (I've not checked out how functional it is yet - I've run out of lunch hour). Might be something we could collectively use quite nicely. We'd just need to use a common +to to notifiy clients of events. Would be a nice starting point to create a cross language protocol with the "hard" bits already done...

Nice find! Telehash might be exactly what we need. Although the existing implementations look a bit incomplete (at least the C one), some sort of DHT network could be a way to go. However, before we go ahead implementing the all the network-specific bits I think we have a bigger fish to fry.

Even the best distribution system is not gonna be any good if it distributes wrong data. I'm not a fan of discussions where people just enumerate possible problems expecting someone else to solve them, so here's my partial vision how a global ban system could work.

PROBLEM: Master ban by LFS world.
SOLUTION: Rather simple. Do not really ban the offenders, just kick them as soon as they connect. The slightly higher overhead and a bit of a nuisance for the other players on the server in a form of the "xxx has connected" message is a small price to pay. It's not like an actually banned user cannot try to DoS a server by retrying to connect over and over again.

PROBLEM: Shall ban be a really global thing? Wouldn't that cause a mayhem all across the network?
SOLUTION: Yes, I think it would. There are different types of servers run by different admins, so a truly global system won't work very well. I suggest a form of subscription. Each server will have an UUID and admins will choose which servers are they going to accept bans from. If a ban is refused by a server, it will still be passed along to the other peers (obviously). There should also be a possibility to accept all incoming bans if someone really wanted to embrace the power of the banhammer.

PROBLEM: How shall a ban be revoked?
SOLUTION: This is IMHO a more difficult question. Imagining a ban spreading throughout the network is easy, but how about the situation when a ban is revoked? One way to handle this would be to not transmit such info at all, but this is far from ideal. For instance, what if a server where a ban had been revoked received this ban again from another peer? Should there be a database of active and revoked bans just because if this? If so, how long should the revoked bans be kept in the database? What about the unjust bans? Even is such a ban is lifted on one server, the unlucky user will still be banned elsewhere. It would seem that silent revocations are not the way. Let's say that servers transmit information when a ban is revoked prematurely. Imagine a situation where a guy is banned on server A. Servers B, C and D subsribe to server A and ban the offender too. Unfortunately, server C admin is offender's friend, so he removes the ban on is server. Because all servers in question subscribe to each other, the global ban is gone. Maybe if the ban info contained UUID of the server where the ban originated it could help a bit. Situations where a peer receives revocation info before ban info would also have to be handled.

Of course I'm opened so suggestions and criticism Once these questions (and most likely a lot of others I didn't think of) are resolved, I'm willing to put together a demo solution to test the system in practice...

Quote from MadCatX :

PROBLEM: Master ban by LFS world.
SOLUTION: Rather simple. Do not really ban the offenders, just kick them as soon as they connect.

Sensible, don't see any other way around it.

Quote from MadCatX :

It's not like an actually banned user cannot try to DoS a server by retrying to connect over and over again.

If a DHT banned user is just kicked on connection, if they could reconnect fast enough it could prevent votes, people spectating and pitting, etc. I don't think that's solvable or something we should be worried about. There's no mitigation without causing a master ban.

Quote from MadCatX :

I suggest a form of subscription. Each server will have an UUID and admins will choose which servers are they going to accept bans from. If a ban is refused by a server, it will still be passed along to the other peers (obviously). There should also be a possibility to accept all incoming bans if someone really wanted to embrace the power of the banhammer.

Exactly what I had in mind, however with a distributed system each message needs to be signed so that it can be verified. If any user can transmit into a DHT, then every message can be faked, if it's not signed. It's a performance penalty, but I believe it's necessary. I'd propose using public/private keys - it's the only way to do this safely and quickly. Libraries exist for all major programming languages and are used by billions of transactions a day - battle tested and ready to roll.

Quote from MadCatX :

PROBLEM: How shall a ban be revoked?
SOLUTION: This is IMHO a more difficult question.

I will be honest I've been ignoring this problem until now

The only sane solution I can think of is that bans are tracked and stored by the "local" client/switch. The client stores the ban origin. If the ban is revoked at the origin the local client/switch could mark that as unbanned. If it wasn't banned locally by the server admin (i.e. not manually) then the ban is revoked. If there are multiple origin bans, then you don't unban until it's manually revoked on the server or all origin bans have been removed.

It's not ideal, but strikes a balance between automation and fairness. I think... It introduces the issue of second and third hand bans - that presents an issue within itself

I will be honest this is the main reason I avoided a distributed system in the original post. This sort of issue is a bit easier to deal with in a centralised manner

PROBLEM: Master ban by LFS world.

AFAIK, the ban only "counts" as far as the master server ban goes if the user is actively banned while actually connected to the server. If the user is already in the server's ban list when they try to connect, then it's not counted. This would explain why there are relatively few global bans because of this - multiple connections to a server where you're already banned don't increase your tally. It's presumably also protection to stop some random server repeatedly banning and unbanning a user to get them LFSW banned while they're not even on the server.

You'd only be LFSW banned if:
a) you're stupid enough to do something to get banned on x different servers
b) a malicious server bans and unbans you multiple times and you're stupid enough to keep connecting only to get banned again
c) you're testing a banning system on your own server

SOLUTION:
If that's correct, you could avoid the master server counter entirely by kicking the player on connect, then issuing the /ban command as soon as the user has fully disconnected. That way, the next time the user tries to connect, they're already on the ban list so it won't count towards an LFSW ban.



Edit:

I also have a suggestion that I think would make this useful to a lot more servers.

Ideally, as well as only subscribing to bans made by admins you trust, you'd be able to subscribe to specific pre-defined ban reasons. Specific rules would be referenced by ID within the system, so it wouldn't cause significant network overhead.

Pros: Different servers have different rules - a destruction derby type server probably isn't going to mind if people who've been banned for wrecking on a race server join theirs; similarly a race server admin probably isn't going to care about people who've been banned for breaking many of the obscure, weird and wonderful rules that cruise servers have. I'd assume that most server admins, regardless of the type of server, would want to subscribe to bans for being abusive to other players etc.

Cons: It makes the system more complicated and less automated, particularly when it comes to adding bans to the system in the first place.


This isn't really a necessary feature and can probably be added in a later version if enough people want it, but I think it would help the popularity of the system.

I don't think thor is required as the master ban list can just be a text file, as BZFlag's is, http://www.bzflag.org/master-bans.txt, so you just need to make a server load the list when it starts and when anyone joins that matches entry's in the list are kicked

Quote from enrico2285 :

I don't think thor is required as the master ban list can just be a text file, as BZFlag's is, http://www.bzflag.org/master-bans.txt, so you just need to make a server load the list when it starts and when anyone joins that matches entry's in the list are kicked

My original post was for a centralised server. It was slightly more fancy than a text file, but centralised nonetheless. The thread then went along the lines of supporting decentralised - Thor would be entirely optional if the clients were based on the DHT, and allow you to setup meshes - both public and private. The extra benefit is that there's no delay - when someones banned in any type of pubsub system (be it centralised or decentralised) you can have all the client servers update immediately.

If you want a ban text file that's downloaded from a server every X minutes and then the bans loaded into a running server, no problem. That could be quickly knocked out. Loses a lot of features though, and you still need some way to send bans back to the central text file(s).

Quote from Degats :

I also have a suggestion that I think would make this useful to a lot more servers.

Ideally, as well as only subscribing to bans made by admins you trust, you'd be able to subscribe to specific pre-defined ban reasons. Specific rules would be referenced by ID within the system, so it wouldn't cause significant network overhead.

This has been my plan all along, bans have to be categorized by the type of server where the user was banned (race, cruise, drag, ...) and the kind of offense (wrecking, spamming, foul language or comments, cheating, ...). Some custom data like a short comment or a link to a replay might be useful too in case someone would like to review a ban by hand. I'd certainly appreciate some input from the server admins here.

(BTW, there's also another thing to consider and that's the programmer's interest. Everybody has done some sort of client-server application, there's nothing new to it, it's all been explored and done. A custom peer-to-peer network is much more challenging to imagine and implement.)

I didn't rode the whole thread but it would be pretty simple to have a database, and when someone gets banned from server with /ban command it inserts name to the database and there is a bool named ban and it changes that to true. When user connects to a server, server searches database for his name and when bool is true server bans him.

E: Oops i made a litlle bump