Player accounts & federation (XMPP promotion)

[Julius]

More and more games come with some sort of player account system (often steam based) for cloud services and achievements etc.

While I can see the appeal even for FOSS games, there is a risk of walled gardens or getting stuck with non-libre systems like Steam.

Therefore it would be nice if people working on FOSS games could agree on some sort of federated standard to be able to share accounts across games and maybe even hook into a larger ecosystem of federated websites (Stuff like GnuSocial / Mastodon, Nextcloud, Matrix.org, XMPP/Jabber and so on).

There is obviously a bunch of more or less competing standards, but IMHO the most suitable for gaming related services is probably XMPP. Originally a real-time chat protocol, is has in recent years improved a lot and despite what some people say is again very much relevant. There is also a huge ecosystem of existing code to easily embed into your game and has all sorts of extensions allowing for external logins, multi-user chats etc. It can also be easily embedded into websites to link your in-game chat with your online portal (see JSXC, converse.js or movim.eu). Oh and it has great modern mobile clients as well ( for example conversations.im and xabber).

For example the FTEQW engine has it build in, and thus you can easily add players to your friends list and join servers they are playing on with one click at a later point in time. You can also easily chat with players from outside the game. Pretty neat, heh?

XMPP also has good support for chatbots like Hubot and Errbot, allowing all sort of automation, and XMPP servers like eJabbered or Prosody are low resource, relatively easy to deploy and can hook into existing user-databases.

Last but not least, XMPP can support many kinds of end-to-end encryption to preserve privacy (OTR, OMEMO) and can be easily used to establish audio and video links through WebRTC in order to have peer to peer audio/video chat available to players.

So if you are thinking about doing your own custom account system, please think again

[Wuzzy]

I'm already using XMPP, so its adoption will not fail because of me.

What I'm really waiting for is an XMPP extension which allows players to share which games they're playing, and when, and send invites to a match etc. Basically an infrastructure to find other players, regardless of game.
This will be incredibly useful to find players in somewhat obscure games (which FOSS games usually are).

I think such a feature might XMPP also a huge boost in general.

[Sauer2]

Oh and it has great modern mobile clients as well ( for example conversations.im and xabber).

As a long term XMPP user out of multiple desktop clients with chat partners that use mobile clients I can state that even so much as transferring a file or even showing the other users state isn't guaranteed to work, in particular on mobile clients.
That being said, building a custom client that only connects to that custom client based on XMPP might work.

[Julius]

I doubt that was the fault of the mobile client. Both features you mentioned are newer extensions with apparently slightly different implementations and sadly there are a lot of old unmaintained xmpp servers out there that do not support these things consistently. But if both are registered on a modern eJabberd server it will work fine.

[eugeneloza]

More and more games come with some sort of player account system

[grumpy=on]
I know it's very IMHO, but I just hate this solution.
Every stuff requires you to make account. Download a public domain file? Make an account! Search the website? Make an account! Want to see all dictionary entries? Make an account! Eventually we end up filling 1024 forms with fake data, skipping thousands of pages of site-user-licenses, exposing our emails/phone numbers and sometimes even passwords (as I doubt every man has 1024 different passwords for 1024 on-line services he was forced to register to), browsing history to spammers and hackers.
And now just to download and play a game offline you are forced to create another account (fill another huge form with fake data, accept another non-standard eula, forced subscribe to spam, etc.). I'm not speaking of privacy issues, as such "forced Internet access" can deliberately/accidentally give others access to your computer resources (such as web camera, microphone, e-mail passwords), backdoors (to install keyloggers or spam-machines), execute some operations without permission (like downloading something you didn't explicitly allowed to, like ads or just wasting your bandwidth, e.g. in case the traffic is paid or limited).
[grumpy=off]
If we are speaking of freedom, I personally believe accounts should be very optional. And the first thing that should be made is A - game must explicitly allow user do deny all external/Internet access, or at least explicitly inform him/her of what exact actions are taken and why are they so necessary (even bug-reports should be a free-will choice, aren't they?) and B - allow anonymous/guest login (guests may be disallowed to use certain resources, such as achievements, ability to save progress, trustworthy players playrooms, etc, it's fine for an online-only game).

Yes, that's the reason why I don't have a STEAM account at all, and hardly will ever create one.
Yes, I voluntarily share some of my data/history with some services like https://popcon.debian.org/ . But I'd be very discouraged if anything like that would happen forced, without my explicit consent or knowledge of.

[dulsi]

@eugeneloza: I think Julius's suggestion is what you want for a player account system. It is not tied to a company. While most people would use some other site to manage it, you can setup your own server. Now granted that doesn't address the gripes you do have. I agree requiring an account for an offline game is annoying. I find the access rights in android annoying as they don't tell you why they need a right. I would definitely like more transparency there and perhaps allowing optional features to be disabled.

[eugeneloza]

@dulsi, yes, of course, I didn't mean that the proposal is bad. Julius's post is on HOW to make the accounts better, not whether to make them or not.
That's just still a bit frustration left, when I was forced to register at a dictionary site to view all the content, but after I filled in a form, my e-mail wasn't accepted and support only answered "try another e-mail" and some recent "forced to register" to search and download some sort of one-time data for my work project (which eventually proved to be irrelevant) - just two examples out of thousands.
So, the idea behind that was: don't force users to have an account unless it's really essential to (e.g. like on a forum or social network).
Proprietary software/sites do this to gain some "product to sell" in form of information or unauthorized access to user data, but that shouldn't be the case for really Free software. It smells bad .

[c_xong]

We know how to solve all these problems. Please don't equate this with the old crappy profit-driven account systems of the past. The solution is simple:
- Single identity provider to avoid creating many accounts
- FOSS, federated identity provider so you can trust or run yourself
- Granular, user control over what bits of data to expose
- Offline fallback so you don't lose functionality if no internet, with options to sync or attach to existing identity later on

[Lyberta]

Deleted.

[eugeneloza]

We know how to solve all these problems.

That's good to know and I hope it's implemented in a nice way.

Single identity provider to avoid creating many accounts

E.g. by using gravatar you accidentally find your image and e-mail exposed to everybody in unexpected places where you just (forced) typed in your e-mail. And unless you typed in a non-standard password (do you honestly have a unique password for every single-time login?) you're left at mercy of honesty of the site owners, who can easily try the password you provided them on every site they'll find you registered gravatar image. Otherwise hackers will do that, as they did to pascalgamedev recently, getting password hashes & e-mails for all the forum users.
I don't mean to equate/not-equate with paid services (I just tell where the "fashion" comes from).
I mean adding a 5th statement to your post:
- accounts and Internet-connection must be optional and explicitly free-will unless it is unavoidable.

[Julius]

I think XMPP is a bad idea because XMPP uses DNS for account names and DNS is centralized which is bad.

That is FUD DNS is more or less decentralized with internet providers offering DNS mirrors and even domain name registration is quite liberal these days. And nothing is stopping you from running your own DNS service in a closed off network.

No doubt your approach is also good, but you will more or less have to repeat decades of work that already went into XMPP. Its also easier to agree on an existing standard...


@eugeneloza: I very much agree with your points, but wouldn't running your own XMPP server in a federation solve most of these?
You can also setup a kind of two factor authentification with XMPP where instead of typing a password you get a prompt on your external chat app for example on your phone.

[c_xong]

E.g. by using gravatar you accidentally find your image and e-mail exposed to everybody in unexpected places where you just (forced) typed in your e-mail.

That's what the granular access control is for. You control what you expose to third parties.

And unless you typed in a non-standard password (do you honestly have a unique password for every single-time login?) you're left at mercy of honesty of the site owners, who can easily try the password you provided them on every site they'll find you registered gravatar image.

The site owners don't see your password, the authorisation request goes to your identity provider. See for example OAuth 2.

Otherwise hackers will do that, as they did to pascalgamedev recently, getting password hashes & e-mails for all the forum users.

A properly salted and hashed password with high entropy cannot be used in place of a password.

[Duion]

Accounts for games should be maintained within the games, where they are needed and not on some external "social" media platform, which is just invented to datamine people, to sell more stuff to them, so I don't see a need for that in open source games.

[charlie]

Maybe you don't, but others do, and it's not for data mining. So don't strawman the discussion.

[Lyberta]

Deleted.

[Duion]

Maybe you don't, but others do, and it's not for data mining. So don't strawman the discussion.

So you want to create a datamining platform that is not used for datamining?

[Julius]

It's not a datamining platform if no data is collected and the accounts are federated.

[charlie]

So you want to create a datamining platform that is not used for datamining?

You know way less than you think you do. You should start assuming that the things you know need questioning before making yourself look silly like this.

[dulsi]

So you want to create a datamining platform that is not used for datamining?

By making it federated there is not one company with control of the data. By making it a common standard that all games use it allows you to look and see what games your friends are playing. It allows you to implement achievements which are visible to others. This is not something everyone wants but it does appeal to some people so as long as it is optional there is no harm.

[Duion]

You could just ask your friends what they are playing or they could tell you.

[Julius]

Came across this interesting project that basically implements a digital payment system on top of XMPP. It's not a cryptocurrency or such, but would probably make for an interesting in-game currency that you could even transfer to another game or such.

See: https://www.voucher-safe.org

[Julius]

https://wolthera.info/2020/12/xmpp-client-in-godot/

This seems like a great start to implement such a system and player chat into a Godot game.

Oh and I recently learned that 0 A.D. does indeed use XMPP to manage player chat and related functions in their game engine.