OpenTTD Network Improvements

network-improvements.md

Phase 1 - Add crypto

• Add crypto library to OpenTTD
• Generate a single crypto-based unique identifier on clients
• On joining the server, the client gives the server his crypto-based unique identifier
• The server challenges the client to validate he is the owner of this crypto-based unique identifier
• On creating a new company, the server adds the unique identifier to the access list of the company
• On joining a company, before a password is asked, the server checks if you are on the access list of the company, and lets you in passwordless if you are
• The crypto-based unique identifiers who have access to companies are stored in the savegame
  • Reloading a savegame on the same server keeps the access list intact

This will be enabled by default, but servers can opt-out via a setting.

Pros and cons

• ✅ clients can authenticate without password
• ✅ clients remain anonymous (it is not attached to any identity)
• ✅ simple cross-platform implementation
• ✅ requires no centralized infrastructure to track players
• ✅ no need for sign-up, passwords, or anything like that
• ❌ if a client loses his secret key, he lost access to his company (solved by Phase 5)
• ❌ cannot join your own company on another device (solved by Phase 5)
• ❌ friends still have to join with passwords (solved by Phase 3)
• ❌ server access is still public or via password (solved by Phase 3)
• ❌ you can be tracked over multiple servers (solved by Phase 2)

Phase 2 - Multiple identities

• Extend the client to allow creating more than one identity
  • You can use this to make sure you cannot be globally tracked over multiple servers
  • This can be as extreme as a new identity for each server
• Each identity has a predefined username; you can still rename ingame, but this will be the name you use when joining

Pros and cons

• ✅ you take privacy in your own control

Phase 3 - Access lists

• Servers get an (optional) whitelist
  • On this whitelist are the crypto-based unique identifiers of clients who have access to the server
  • A server-owner can generate an invite code
    • When joining a server in whitelist-mode, this invite code allows you access
    • After joining, your crypto-based unique identifier is added to the whitelist
• Companies get an access list with roles
  • The first client to join a company is owner
  • The owner can add members to the company based on the crypto-based unique identifier
    • Members that are already in-game, for example as spectator, can be added immediately
    • Invite code can be generated, similar as with the server whitelist
  • The owner can promote members to owner, and owners to member
  • The owner can make his company public, allowing anyone to join
• Password-based authorization will be completely removed at this point in time

The invite codes and access lists replaces passwords; the first can be considered a "temporary" password with the big difference that they are generated.

Pros and cons

• ✅ removes the need for passwords
• ❌ requires clear instructions for server and company owners how to manage their access list

Phase 4 - Friends list

• You can add people you play with to your personal friends-list
  • This is based on the crypto-based unique identifier
  • The last known in-game name is remembered for each friend
• A server can be queried for the public keys that are active on the server
• The in-game server-list will show servers where your friends are playing

Otherwise, you can only see if a player is active on the server you saw him on.

Pros and cons

• ✅ removes the need for passwords
• ❌ you cannot prevent someone adding you to his friendlist, so people can stalk you

Phase 5 - Store identity in the cloud

• Your crypto-based unique identifier can be stored encrypted in the cloud
  • You need to remember your username and password
  • The crypto-based unique identifier is encrypted before it leaves the client
  • The password never leaves the client; it is only used locally to encrypt/decrypt
• On other devices you can retrieve, based on the username and password, the crypto-based unique identifier

Pros and cons

• ✅ allows the same user to play cross devices
• ✅ on local data-loss, access to the company can be recovered
• ❌ if user forgets his password, all information is lost

technical.md

Phase 1 - Add crypto

• We use libhydrogen to add crypto to OpenTTD
• This library generates a single public/secret key; the secret will only be known to the client
• On joining the server:
  • the client sends his public key to the server
  • the server sends a challenge to the client
  • the client signs the challenge, and returns this to the server
  • the server validates the signed challenge
  • this ensures the server the client in fact has access to the secret key, and is therefor the owner of the public key
• On creating a new company, the server stores the public key to the company
• On joining a company, the server first checks if the public key is that of the company
• Server owner needs a way to reset public key of company
• Server owners need to be able to list public keys of clients, like via console/rcon etc

Public keys are stored in the savegame, so reloading works.

Phase 2 - Multiple identities

• Exactly what it says: a client can, in a dropdown or what-ever, pick the identity to use on server join.

Phase 3 - Access lists

• This is mostly UI work; the code mostly speaks for itself
• Invite codes should only be valid for a (short) period of time, possibly configurable
• Invite codes could have a limit on the amount of uses
• Such invite code can be integrated in openttd: protocol
• Server owner needs a way to change public keys of companies

Phase 4 - Friends list

• Friendlist stores public keys in openttd.cfg on the client (base64 encoded)
• Server can be queried via UDP for the current active public keys
  • This most likely in a similar way as the NewGRFs can be queried
• Clients, after receiving the server-list from the master-server, query every server one by one
  • For each server it will now do two queries:
    • The server information
    • The active public keys
  • The client can now indicate on which server friends are playing (possibly by a filter)
• Possibly we can also make the master-server query who is online where, so a client can have the option to only fetch servers friends are on. This would heavily reduce the amount of servers being sent to the client.

Phase 5 - Store identity in the cloud

• The public/secret key are locally encrypted with AES based on the user password
• This encrypted blob is stored on an openttd.org service based on the username
• Based on the username, this encrypted blob can be retrieved
  • Only with the correct password can it be decrypted again