Players can sign in and synchronise client settings

[congratulatio]

This is the client portion of a player sign in feature, so we can get back the functionality of players keeping track of their game stats, levelling up, etc. Also might end up being useful for authenticating to the moderation panel on game servers.

It relies on two endpoints:

• https://login.airmash.online/login for authentication
• https://airmash.online/settings to save and restore settings

The code for these will be added to airmash-refugees/airmash-backend soon.

[ghost]

Looks good & merge at your leisure! Side thoughts:

• I wonder what Wight thinks about how this stuff should work
• As a matter of principle I almost never use these third party login services, same reason I never had an account on the original Airmash. Still a lot of people will be happy to see this returning

[ghost]

Final side thought:

• Are we going to have some way to federate the database, or will this inevitably mean there is only a single login service?

[congratulatio]

Looks good & merge at your leisure! Side thoughts:

• I wonder what Wight thinks about how this stuff should work

Good point, adding @wight-airmash for review/comments.

Final side thought:

• Are we going to have some way to federate the database, or will this inevitably mean there is only a single login service?

I've set this up with multiple Airmash clients in mind - though it's just airmash.online and test.airmash.online to start with, starma.sh could have these changes ported over and it would work the same. I think if necessary we could have some synchronisation between different login services to make sure a player logging into any such service via the same third-party account gets identified as the same player. But I reckon a single login service would be easier to manage.

[congratulatio]

A couple of points on client-server interactions:

With these changes, when a player logs in, the login service provides them with a unique player id, which is sent to the game servers (as LOGIN.session) but not to other players. This is the same trust model as the original Airmash, but it does mean all server operators have the capability to impersonate players on other servers.

The login service also provides the player with a client token which is used to synchronise settings. This is not given to the game servers, because they are not responsible for keeping the settings up to date. This differs from the original Airmash, where the game servers would update the name and flag settings, and the client would only read them (from the old /auth endpoint).

[wight-airmash]

Very cool!

Are we going to have some way to federate the database, or will this inevitably mean there is only a single login service?

But I reckon a single login service would be easier to manage.

I agree, and we will always be able to complicate the architecture, if necessary, I don't see the need to do it right now.

As for the data itself, we already have a bitter experience of data loss, so maybe we should consider how to make the data available to everyone (without violating privacy, of course), in the form of periodic dumps or otherwise.

[congratulatio]

I've added the backend server code for login.js and settings.js so you can see how these fit together with the client changes.

[congratulatio]

As for the data itself, we already have a bitter experience of data loss, so maybe we should consider how to make the data available to everyone (without violating privacy, of course), in the form of periodic dumps or otherwise.

Agreed, maybe to begin with, and ongoing for any sensitive information, a private repository could be added to airmash-refugees for synchronising such data?