How should we persist players?

[Mushroom]

So we're getting to the point at which we're thinking about potentially storing players' previous positions etc when they connect, and when the host saves.

This means we will need to find a way to persist/differentiate the different clients as they connect and disconnect.

There are several options/approaches we can take:

• Use their steam ID - every player has a unique steam ID, we just treat that as their identifier
  • Pros:
    • Every client is already assigned a unique ID by an external service
    • We don't have to manage anything except storing numbers
    • Players can connect from different machines to the same server
  • Cons:
    • As this is a mod, we do not have access to the same things as the real developers might, so I don't know if we can verify steam IDs, which may mean people can spoof them
    • This breaks sandboxie, as we need to have seperate accounts for testing
    • If we can verify IDs, this may make a requirement to be online, as opposed to just on a LAN (EDIT - confirmed, session tickets require steam to be in online mode)
• The client generates a keypair and uses that to identify themselves (like TeamSpeak)
  • Pros:
    • Verification can be done instantaneously by just checking a signature
    • It doesn't break the sandboxing approach
    • IDs are transferrable
    • You can verify any action by a player if they sign it
  • Cons:
    • If public servers become a thing it becomes very easy for hackers/griefers to gen a new key and hop right back in if they get banned
    • If you lose the key that's it, no recovery

Plus other options such as running our own auth service, but that has all the same pros and cons as steam auth, apart from we can issue new IDs whenever, but them we become data controllers under GDPR (not fun) and have to run our own infra (also not fun).

Suggestions welcome.

[hubastard]

I think that we could do the following:

• We generate a UDID on the client and store it in it's %appdata%
• When we connect to a server we provide our UDID
• The server checks if this UDID already logged in and the server will save the UDID AND the IP of the player in its internal server save file.
• When we want to blacklist a player, we blacklist both his UDID and IP. So if he wants to reconnects he need to change his UDID and is IP
• When a player connects with a known UDID but with a different IP, we override the known IP in our save file (to work with dynamic IPs)

One important thing, I think that UDID should ONLY be used for the initial connection step, after that further communication with the client is done using the client short playerID. That will help prevent hackers from copying another players UDID.

[Mushroom]

I'm more inclined to agree with @Flapperkewiet - we can always add on "offline mode" with no verification, similar to how minecraft does it, for development purposes. Steam seems like the more trusted, safer option.

[hubastard]

Go for it, it could be nice also if we could extract the player name from his Steam account

[hubastard]

From the new update it seems like there is now a creatorID in the save game. Maybe we could use this, we should look into it, it could be the actual steam ID.

https://store.steampowered.com/news/app/1366540/view/3064108587879145729

[Therzok]

Save files in the newest release contain account info (platform, id)

Edit: heh, page didn't refresh

[Mushroom]

So, looks like we might have to go for the approach @hubastard suggested - looking at the enum values, it looks like there is a "standalone" and "WeGame" platform, so we will need to account for cross-platform play, as well.