Hello ddnet admins & devs
So me and a bunch of other people were just wondering about what happened to the account system and if there will ever be one to potentially come.
It would be nice to know about the problems and plans surrounding this topic.
Especially as it seems like the whole community wants something like this implemented (i. e. the survey that was done in the past in announcements ).
Probably the whole community would like to know about what's actually going on there so that perhaps solutions could be found.
Be it by funding and therefore paying the devs if that is the problem or by anything else (depending on how this whole thing turns out), I think many people would be glad to help.
Best regards
@deen@murpi@Robyt3
we do not want to force anyone to work on it. we just want to have an open discussion because it kinda got swept under the rug with no communication at all
Does anyone have a bind to change the buttons of different binds? Example: I am doing hammerfly and I want to stop doing that and the dummy doesn't hit anymore.
I feel like the whole thing didn't progress because the voices of the people who didn't want the account system were louder
and because of non-agreement on the 'type' of the actual implementation. Each active dev has his own ideas, and ofc each idea has pros and cons
we do not want to force anyone to work on it. we just want to have an open discussion because it kinda got swept under the rug with no communication at all
it never got swept under the rug with no communication at all, the communication is in a place where if you urself had self interest would have found, its always available and you got linked to it already: https://github.com/ddnet/ddnet/issues/3411#issuecomment-1534189301
the thing is, this is a volunteer project, this is a complex feature involving many moving parts and its hard to coordinate, there are many ways to go on about it, each with different drawbacks and pros, it also needs quite lot of work, people have jobs, their life etc, we don't have many new devs too, i dislike how u make it seem like people who work on this project tried to hide the accounts work, not at all, people just have their lifes
10:24
dont assume bad faith
10:26
also about paying devs: maybe a money incentive may make some dev work on it, but ultimately people need to keep their jobs and monthly wage, im sure it would be rly hard to afford to pay fulltime someone, even then i myself would think it hard before becoming a full time dev on a volunteer project, there is almost 0 job security as in you could stop being funded anytime unlike in a real company etc
Summary of this Accounts discussion as of 2023/03/31
Benefits of Account system
Verified users, preventing impersonations with fake finishes, and easier event organising.
Player roles/badges in-game, e.g. moderator, mapper, donator, tournament winner etc.
Moderation simplified for bans, mutes etc. Can't evade bans through a new IP.
Friend lists.
Clans.
Maps and skins can be bound to author accounts.
Drawbacks of Account System
No reasonable way to correctly link unverified accounts to new accounts for points transfer. Perhaps players can "link" their account to an old accountless username, but this won't be verified and will show up as a separate section on the account page.
Concerns
Worry about unknowingly leaking private keys related to login ("just send me this file and that file"), if credentials are stored locally.
## Design Requirements
Must-haves
Playable without authentication
Authenticate client via a login mechanism
Records and identity moved from name to a unique identifier UID (only necessary between client and master e.g. /w stays same)
Support account recovery
Desirables
Preserve old points so progress is not lost
Avoid storing confidential information
Decentralized authentication
Undesirables
Force accounts onto users
10:29
Future plans/suggestions to consider
PlayerRoles: Needed when wanting to grant permissions based on role e.g. tester, mapper, admin etc. (can be left out for now)
Clans: Needed when wanting to support clans (can be left out for now)
ConfigSettings: Save certain user config settings for syncing across devices?
## Proposal 1 by kyle-bradley
RaceCheckpoints: I noticed the majority of maps had these columns unused and when they did it was variable. Felt it could benefit from being its own table for that flexibility
DifficultyTiers: There is a coupling between difficulty levels, tiers (i.e. stars), and points. Unless I am mistaken, you wouldn't have a map with the same level, tier but different points. This allows for a singular location to maintain that association
Server: This logic is housed informally somewhere, so useful to bring it in here where the data is structured and queryable
User Flow
1. /login - email in server || alternative is to have a login UI button
1. /otp - email -code in server || alternative is to have a dialog post clicking login
1. Success!
Implementation
1. Client sends the email address to the master server
1. Master server sends an email with a pin to the address. The pin is a unique identifier generated off the email similar to a hash
1. Client sends the pin, email address, name, and country code to the master server
1. Master server checks if the pin matches the email address. If so, sends back access_key and upserts the account info. Master server doesn't have to be the same as the current.
10:29
The objective was to create a secure account system while still adhering to the principle of an open database. This is achieved through a static secret salt and generated salt per pin.
1. User requests login
1. Entry into PinTable made with:
Lookup: Hash of email address and secret salt
Readable Code: Deterministic Guid created from the email address, salt, and a different secret salt
Valid Timestamp: 12 hours
1. User supplies readable code and email address - client will send through name and country code as well
Lookup: hash of email address and secret salt. If still within valid period, fetches readable code
Compares associated readable code with the supplied code
If valid gets or creates the user with a new access key
1. Future account requests to be made with the access key.
I'm no security expert so welcome any feedback.
1. Central account server to register on and log in to administer your account
1. Account server returns private key token to player, stores public key token
1. When client joins a game server, game server asks account server for the currently valid public key tokens.
1. Game server sends challenge to client, client uses its private key token to solve it. Thus evil server hosters can't steal tokens and impersonate players.
1. Allow every username to be registered an unlimited number of times, assign a random integer to the username (similar to Discord). Players add friends using the name+id. Nicknames can be used in-game, but actual name+id are also shown. Thus we have no effort to make sure players are claiming names of known players already.
10:29
Don't move points from old accountless world. Keep them around as non-account players and players can keep using them forever.
Alternatively, start a season 2 of DDNet instead where account players start at 0 points, but can collect new achievements, only available for logged in players. Something like the Duolingo achievements, to motivate players to use accounts. "There seem to be a lot of conflicting ideas and wishes for season 2 and accounts. After some discussions, instead of a reset we will keep gradually improving DDNet." - deen
Some additional discussions regarding new setups proposed in season 2 are here, but could be useful for general account discussions.
10:29
Next steps
1. Check if the community likes this idea, done
1. Figure out how to safely get authentication data from other players to your client. We could only trust the http master server for this, which we also run, and not the game server. Registration server could tell the http master who is logged in where.
1. Implement a backend to register accounts from website/client. In case of DoS attacks put it behind cloudflare and force registration from website
1. Implement a frontend to administer your account from website/client. Register, delete account (disables but keeps ranks), change email address, change password, connect to some auth service (mainly Steam I guess).
1. Figure out how to make registration for Steam users "one-click". Can we get their Steam ID and connect them to Steam automatically to sign up? Then no email and password required.
1. Think about what achievements we want to have and make them show up on website/client. Some should be stackable so you can improve on them, design some nice graphics for them:
Number of days with finishes every day: 7 days / 14 days / ...
Long finish: 4 hours / 8 hours / ...
Reach points: 1000 / 2000 / ...
Team rank with same friend on number of maps: 10 / 20 / ...
Perfect time finish with :00.00
Team finish with large number of players: 16 / 32 / 64
Top ranks: 1 / 2 / 4 / 8 / ...
All maps finished on server: Novice / Moderate / ...
Account age and still active: 1 year / 2 years / ...
10:29
Are there any other major things we should change now that we have the chance of a "new season"? Things which could not be changed normally because of backwards compatibility? Skeith suggested disallowing team finishes "cheated" with dummies.
Each client generates an asymmetric key and uses it to authenticate against each game server. This is transparent to the user.
The user can "log in" to an account by giving an email address while authenticating with its private key. The account server will store a constant, never changing mapping of public key hash → account ID. This mapping is public and can be queried via an HTTPS endpoint so third party servers can also use it. The fact that the mapping is constant can be used to aggressively cache the mapping on all servers, lowering the impact if the authentication server is down.
A user might play from multiple clients – the private keys aren't shared by default, instead the user logs in from multiple private keys.
There are two methods I can think of to support logout. Either the client generates a new key (might have a bit of a bad UX because we then don't trust the client anymore), or we include an increasing login index, and use hash(public key + login index) as login identifier instead of hash(public key), meaning that logout would simply be incrementing the login index.
In order to securely support login, the client-server connection must be encrypted and authenticated, otherwise MITM and proxying issues immediately appear. The login protocol should bind to the cryptographic session so that the login sequence cannot be forwarded to other servers.
10:29
Also see issue #5411 about secure server connections.
Another proposal from discussion in #developer channel
Perhaps accounts are mandatory.
e.g. Old username is: MyCoolName
New account name could be: MyCoolName#1234
You can opt-in to include the points of your former username with this account (but they're marked as "unverified")?
Allow players to hide their account name (MyCoolName#1234) in-game to play anonymously.
While that option is enabled, they lose the ability to add friends and other features (/points and showing rank in scoreboard) that need the account name etc.
But they can still finish maps that can count toward their points.
Mods can still see the account name.
If someone has their account name hidden trying to impersonate someone, then you can just automatically assume that it's an impersonator.
Summary of this Accounts discussion as of 2023/03/31
Benefits of Account system
Verified users, preventing impersonations with fake finishes, and easier event organising.
Player roles/badges in-game, e.g. moderator, mapper, donator, tournament winner etc.
Moderation simplified for bans, mutes etc. Can't evade bans through a new IP.
Friend lists.
Clans.
Maps and skins can be bound to author accounts.
Drawbacks of Account System
No reasonable way to correctly link unverified accounts to new accounts for points transfer. Perhaps players can "link" their account to an old accountless username, but this won't be verified and will show up as a separate section on the account page.
Concerns
Worry about unknowingly leaking private keys related to login ("just send me this file and that file"), if credentials are stored locally.
## Design Requirements
Must-haves
Playable without authentication
Authenticate client via a login mechanism
Records and identity moved from name to a unique identifier UID (only necessary between client and master e.g. /w stays same)
read the linked text and maybe we can have a look at what community likes most, altho u need to understand the security and technical drawbacks
copying @Jupstar ✪ comment on github:
kyle-bradly - centralized Account system, mentions implementation details
❤️ Def - centralized Account system. User gets private key for auth. As far as I see ddnets account server would tell if the pub key is valid
Learath - from discord it sounds like he wants a classic centralized Account system with steam integration for easier registering.. so I assume for ddnet only(?)
Heinrich - accounts are decentralized(or partially? or are they at all?), but a list of keys bound to the user are account is hosted by ddnet which all game servers can download. Recovery is optionaly doable by setting an email. Account names like discord(?)
Jupeyy - decentralized or semi-centralized. Let the user choose if they want to use ddnet register service which also supports steam login or classic email login. Allow fully decentralized account where user has to make sure not to loose keys(can be used for new players that don't register over ddnet service directly to automatically have an account). Pub key is used to indentify. Key pairs per server group. Other game servers don't need to know about ddnet except for account recovery. For normal users this should feel like a centralized Account system. Can still be implemented even when starting with centralized accounts
I guess for all system possible UI would be integrated into the client direclty
React with emojis. I tried to only use positive emojis(edited)
Didn't all the new season (accounts) thing "stop" because there was so much hype devs got overwelmed? With so much "new stuff" being asked and none of it already being there
Devinci
Didn't all the new season (accounts) thing "stop" because there was so much hype devs got overwelmed? With so much "new stuff" being asked and none of it already being there
Didn't all the new season (accounts) thing "stop" because there was so much hype devs got overwelmed? With so much "new stuff" being asked and none of it already being there
I never did. I mention this all the time. I'm really thankful for every second people invest into developing the game. I'm just really sad because the account topic was brought up with a discord announcement which seemed like the devs came to the conclusion to actually work on a collective plan.
Sadly the whole idea was delayed because people expected too much which ment there was no plan of actually implementing it still(edited)
Stepfunn
I never did. I mention this all the time. I'm really thankful for every second people invest into developing the game. I'm just really sad because the account topic was brought up with a discord announcement which seemed like the devs came to the conclusion to actually work on a collective plan.
Sadly the whole idea was delayed because people expected too much which ment there was no plan of actually implementing it still (edited)
Thank you @Ryozuki for providing the github summary!
I haven’t read it full at this point but I will do so as soon as I get the time.
However, I understand that there are different approaches by the devs anf expectations overall.
The whole topic as of now simpy just seems a little off because of the publicly announced stop of working on it because „people expected too much“ and the closing of all channels etc.
If the project is actually still in process then I think it would be good to have some kind of channel or at least something similar. Like this the whole thing wouldn’t seem so dead and people could actually talk about the issues and problems and discuss about which approach would be the best.
<BµmM>
even with points reset, trolls will steal names (edited)
An option to the ticket system allowing people to contest for their names if it was stolen by a troll would be a way to "fix" this(edited)
Freezy
Thank you @Ryozuki for providing the github summary!
I haven’t read it full at this point but I will do so as soon as I get the time.
However, I understand that there are different approaches by the devs anf expectations overall.
The whole topic as of now simpy just seems a little off because of the publicly announced stop of working on it because „people expected too much“ and the closing of all channels etc.
If the project is actually still in process then I think it would be good to have some kind of channel or at least something similar. Like this the whole thing wouldn’t seem so dead and people could actually talk about the issues and problems and discuss about which approach would be the best.
Discussions are great, but at some point someone has to decide which way to go. All of the listed approaches are good and valueable but there is always a trade-off.
After the decision has been made, someone has to actually implement it.
Avolicious
Discussions are great, but at some point someone has to decide which way to go. All of the listed approaches are good and valueable but there is always a trade-off.
After the decision has been made, someone has to actually implement it.
It has been officially started and officially been cancelled.
At least this is basically how it seems to be stated to the most of the community.
Even now the whole process seems to be stuck because of complications that are being addressed on the one hand but not being discussed on the other hand so that solutions can be found and actual progress be made.
Because as of now people can't even work on it because admins, devs & the community aren't sure about how exactly this should turn out.
Therefore I'd say this is a call of the community to actually talk about those things.(edited)
The biggest issue is that all 3 of those have to agree on a compromise for any work to be done. None of the devs really want to put in time for something this large that might not be merged or liked by the community
Ryozuki
the only thing cancelled is deen himself working on it
The biggest issue is that all 3 of those have to agree on a compromise for any work to be done. None of the devs really want to put in time for something this large that might not be merged or liked by the community
That's totally understandable and it's obvious that you can't make progress there alone
This is why we, the community (I'd just say that I speak for the community) are offering to help so that it can actually be discussed again how exactly this could work out.
13:36
Like if it for example was too much work as stated in the past because of too many expectations, I'm sure that people might already be justified by the basics of an account system in the first place
Im not an expert but i thought that you’d have to go out of your way to make the acc system private, where as in a closed source code you dont have to bother with it
At this point I'd be okay with giving up on decentralized. It's a developer thing, we enjoy decentralized stuff but it's not that important for the end user at all imo
13:57
But the idea is that if ddnet dies a decentralized account system doesnt die along with it
13:58
And that other mods can use the accounts without having to rely on infrastructure we'd have to host (like a central authentication server)
Anyway, all cool stuff, for us. But also a massive engineering hurdle as there really aren't many examples around that we can take inspiration from(edited)
Still missing:
timeout protection
works on computers other than my own?
works on windows?
works for cross-compiling
review protocol for segmenting messages, is there some sort of standard may...
14:10
but yea, definitely not finished
Jupstar ✪
i honestly fear to rewrite SQLs for the website most xD
I think client-based accounts is the direction this is going already(edited)
14:40
Anyway, I was really hoping to get an extra channel on this server on the whole account debate so it isn't just forgotten in a few days again already as this is a constant wish of the community (at least from what I can tell)
I feel like only devs use github like ever - whenever I see a github post it always shows some dev talk that no one without IT-knowledge is able to understand so I always just ignore these posts
But what do you want that extra channel to be used for anyways?
Most of the talk would be about the possible implementation of the acc system, it's already known it's (mostly?) wanted.
If you were thinking about talking about more stuff than just accs, I feel it will just end up like the last time
Yeah, and I bet on those times you didn't have 100 players a day advertising some bot client, blockers, or whatever
Devinci
But what do you want that extra channel to be used for anyways?
Most of the talk would be about the possible implementation of the acc system, it's already known it's (mostly?) wanted.
If you were thinking about talking about more stuff than just accs, I feel it will just end up like the last time
I don't think there should be focus on more stuff than just accs, one could think about that after the basics of the account system are there but no need to do that as of now.
However, it seems like talk about the implementation of it is what's necessary as of now
Iam still a fan of building a small team and discuss it in a private server, collect all informations, pros and cons and a clear plan and than present it from time to time.
I can't really see how people with not enough knowledge to open a github account could potentially help on that discussion.
One thing is how users want them to be, then ig here it may be relevant to ask everyone on discord.
But the biggest issue rn is about how to implement them
I can't really see how people with not enough knowledge to open a github account could potentially help on that discussion.
One thing is how users want them to be, then ig here it may be relevant to ask everyone on discord.
But the biggest issue rn is about how to implement them
Alright, see that's very disrespectful and you're making assumptions, I know that you're a moderator but then you should probably just delete this message.
It's not about the knowledge here and I am sure I would pretty easily be capable of creating an account. I just don't see the sense of it.
Additionally the community is obviously an important factor on this whole matter.
yes, anyone is welcome to comment on the ddnet github
Devinci
I can't really see how people with not enough knowledge to open a github account could potentially help on that discussion.
One thing is how users want them to be, then ig here it may be relevant to ask everyone on discord.
But the biggest issue rn is about how to implement them
Is the biggest issue about how to implement them? From my understanding it's less about making it work and more about finding something that fits for everyone
14:55
Implementation comes after a consensus of what to do no?
Draggory
Is the biggest issue about how to implement them? From my understanding it's less about making it work and more about finding something that fits for everyone
I can't really see how people with not enough knowledge to open a github account could potentially help on that discussion.
One thing is how users want them to be, then ig here it may be relevant to ask everyone on discord.
But the biggest issue rn is about how to implement them
Alright, see that's very disrespectful and you're making assumptions, I know that you're a moderator but then you should probably just delete this message.
It's not about the knowledge here and I am sure I would pretty easily be capable of creating an account. I just don't see the sense of it.
Additionally the community is obviously an important factor on this whole matter.
Yeah sorry for the disrespect, didn't really mean it (didn't know how to formulate it differently).
But if I understood correctly the only thing we need to proceed with the creating of an account system is the common agreement of devs about how to implement it.
Community is a very important factor but not for this exactly? idk
I thought y'all were still deciding on who's idea you're going to use to implement, I get that the implementation is hard but don't you still need to agree to a method first?
which is why i always mention ppl have their own lives jobs, family
15:00
and that we dont have new devs
Devinci
Yeah sorry for the disrespect, didn't really mean it (didn't know how to formulate it differently).
But if I understood correctly the only thing we need to proceed with the creating of an account system is the common agreement of devs about how to implement it.
Community is a very important factor but not for this exactly? idk
Given that the entire game is community based*, why wouldn't the community be important for this? If the devs put something in that no one really likes then it renders it kinda useless no?
Yeah sorry for the disrespect, didn't really mean it (didn't know how to formulate it differently).
But if I understood correctly the only thing we need to proceed with the creating of an account system is the common agreement of devs about how to implement it.
Community is a very important factor but not for this exactly? idk
I'LL JUST PRETEND LIKE I KNOW YOU DON'T MEAN IT DISRESPECTFULLY!
I think it depends on how exactly you look at it.
I think it was @Learath2 who said that basically admins, devs and community must share the same idea and therefore it's actually really important to know about the community wishes and needs.(edited)
Given that the entire game is community based*, why wouldn't the community be important for this? If the devs put something in that no one really likes then it renders it kinda useless no?
Because honestly I don't think users really care about if the system is centralised, or not. or if they will realise their communication will secured or not, and a big etc. I would trust the judgement of the guys who implement it and are supposed to be more knowledgeable than most of us in this aspect.
Community comes into play when adding features that they can see
1
Freezy
I'LL JUST PRETEND LIKE I KNOW YOU DON'T MEAN IT DISRESPECTFULLY!
I think it depends on how exactly you look at it.
I think it was @Learath2 who said that basically admins, devs and community must share the same idea and therefore it's actually really important to know about the community wishes and needs. (edited)
look whatever, I'll just say a last thing before going.
The idea was adding accounts, and most of us ( admins, devs and community) agree with it.
if Somehow you are an expert at making account systems go at it and give all your propositions. I'm not really. So I'll trust them
Devinci
look whatever, I'll just say a last thing before going.
The idea was adding accounts, and most of us ( admins, devs and community) agree with it.
if Somehow you are an expert at making account systems go at it and give all your propositions. I'm not really. So I'll trust them
You can compare it. DDNet and KoG shares the same playerbase, currently we have 100k "registered" names and ddnet 800k. Not all of those names are unique players, some of this names do have 0 points or 1 point.
You have to consider how you want the transition from non-accounted to accounted
Avolicious
You can compare it. DDNet and KoG shares the same playerbase, currently we have 100k "registered" names and ddnet 800k. Not all of those names are unique players, some of this names do have 0 points or 1 point.
You have to consider how you want the transition from non-accounted to accounted
A bind that changes your tee color's wont ban you as far as I'm aware, so it's probably not that.
Open a ticket on #✉-create-a-ticket if you want to appeal for your ban(edited)
Devinci
A bind that changes your tee color's wont ban you as far as I'm aware, so it's probably not that.
Open a ticket on #✉-create-a-ticket if you want to appeal for your ban (edited)