Implement a master server scheme in JS

[koraa]

Can we do something decentralized even?

[Croydon]

20

[Fohlen]

Since we agreed to this previously, @aschaeffer and I have talked a lot about a scheme for decentralized server lists.

Below is the protocol proposal:

• each inexor-flex instance is a "node" in the network
• only nodes that meet the requirements from #459 (FQDN, valid SSL) will distribute the server list (since these are usually servers)
• each node has an internal git repository with two files, server-list.json, karma.json
  • the server-list.json contains the actual server list
  • the karma.json contains a specially crafted ranking (see Karma)
• the git repository can be publicly checked out via a HTTP end point
• a new server can try to add himself to an existing node
  • via a REST API
  • if the server meets the criteria (FQDN, SSL) and has an overall good karma he will be added to the server's list
  • in a timely manner all server fetch the server lists from different servers to update the list
• "client-only" nodes fetch the server list (for the first time) from an entry node (inexor.org) or a git repository
• after that, it will try to fetch the list from any of the servers from it's internal list (if a server is down)
• we can either display the karma of the server directly, or even add filters to exclude servers with a karma > specific value

Karma

Karma is a sort of rating, that every node in the network has.

• there will be a certain ranking of all available actions (such as connect, ping, kick, kill....) that we will need to determine
• each node tells the other node an overall karma (at the end of the game or connection)
• client nodes will by default try to catch their karma from the server nodes
• based on the ranking, servers and clients can determine wether another node is trustful
• since every step in the network is versioned, we can analyze the network, and intrude if necessary

Karma protocol

We need to decide on a way to protocol karma, since we don't want to read 5000 lines lasting .json documents. Ideas are welcomed.

Spam prevention / intrusion

There are generally two intrusion mechanism that we can build into the network

• by default, servers will fall back to a Git repository of our choice
• the more servers verify your karma, the more likely you will stay in the network (or the opposite)
• we can sign commit's of server-history or karma, making them more trustworthy (it will receive much more karma, if the commit is signed)

Karma ranking

Below, we need to discuss actions that we will want to determine karma for, and a virtual scala that rates them. I suggest that the scala ranges from 0 to 14 (like the pH scala), which comes (more or less) naturally for everyone, in so far as that you can tell, something is good (below 7) or bad (less than 7)

Action	Rating
connect	7
bad ping / connection lost	5
kicked	4
banned	2
cheats	0

(many more can follow here) Keep in mind that the table design might be inaccurate. Most of the actions will trigger a bi-directional, however some (such as cheating, a server doesn't cheat ofc.) are not.