00:30 < bridge> https://t.me/Stevecoldham001 04:29 < bridge> huh, discord sdk is open-source 04:59 < bridge> <судный день.> wow 05:01 < bridge> <судный день.> imagine casually creating pr with rebranding ddnet 05:06 < bridge> probably just a mistake 06:06 < bridge> What type of client is that, anyways? 12:12 < bridge> Regarding Accounts-Issue#3411, I created a *very* rough summary of the conversation since it's quite a long discussion. 12:12 < bridge> 12:12 < bridge> 12:12 < bridge> Perhaps it may be beneficial to have a document that is easier for admins to edit/update. Or maybe heinrich5991 could edit his first comment at the top of . 12:12 < bridge> 12:12 < bridge> I'm assuming there is still interest in the topic, not quite a "season 2", but some derivative that may be beneficial? 12:12 < bridge> Regarding Accounts-Issue#3411 (), I created a *very* rough summary of the conversation since it's quite a long discussion. 12:12 < bridge> 12:12 < bridge> 12:12 < bridge> Perhaps it may be beneficial to have a document that is easier for admins to edit/update. Or maybe heinrich5991 could edit his first comment at the top of . 12:12 < bridge> 12:12 < bridge> I'm assuming there is still interest in the topic, not quite a "season 2", but some derivative that may be beneficial? 12:28 <+ChillerDragon> nice summary 12:44 < bridge> we'd finally need to decide if we want it to be decentralized or not. 12:44 < bridge> 12:44 < bridge> for heinrichs half decrentralized approach i have no sympathies. The gain that having a cache of account mappings sounds not too useful to me, that can also be done by a game server itself. And u have your password stored on your computer all the time 12:45 < bridge> https://youtu.be/TSCzC-WECw8?t=87 12:45 < bridge> wouldn't be a good idea to implement raycasts on every step the player makes in high speeds to see if it collides with an entity that should trigger something? Like kill for example 12:45 < bridge> before we do that we can also do simple password with auth tokens 12:45 < bridge> it does smth like that 12:45 < bridge> just not for kill tiles 12:46 < bridge> start etc. is unskippable 12:47 < bridge> Honestly I like the decentralized stuff but I also know that it's just completely incomprehensible for the average user 12:48 < bridge> the problem is, its not even decentralized anyway 12:49 < bridge> if we want real decrentralized we can do this: 12:49 < bridge> ddnet has a account manager (for non it ppl) that saves the private key which the client downloads. but its a one time key. once its stolen or somehow lost, u done 12:49 < bridge> 12:49 < bridge> the sha of the pub key would be the account ID 12:49 < bridge> and IT ppl could gen this key pair themself 12:51 < bridge> thats also why i feel like the half decentralized approach is almost not worth it 12:51 < bridge> it has imho not really many adnvatages over classic authing 12:54 < bridge> The one major advantage (which I think is honestly a disadvantage) is that it allows for creating accounts instantly on the client side 12:54 < bridge> I think that is actually a bad thing since it means our accounts will be useless in moderation 12:54 < bridge> Except for people that care for their points, which we already can punish using name_bans 12:55 < bridge> i guess the ddnet account mapper could still reject such accounts, but maybe its harder yes 12:56 < bridge> central authing could also geolocate authes to an acc.. and the session could be ip/ipregion bound 12:56 < bridge> the other type would really just need the keys 12:57 < bridge> well i dunno. but i feel like we going in a circle about the account system 12:57 < bridge> maybe ddnet has to be more ego and simply do accounts for ddnet first 12:57 < bridge> before caring about the community 12:57 < bridge> The freeform discussion in that issue didn't help much 12:58 < bridge> Maybe we should have people make complete proposals and vote on those instead 13:21 < bridge> another gain is that we don't have to handle insecure passwords by users 13:22 < bridge> and if they want to change the key? 13:22 < bridge> if its done by email, email also has a password 13:23 < bridge> yes, but we don't manage it 13:23 < bridge> what if i lost my email and want to change it? 13:23 < bridge> why take responsability for insecure user passwords? 13:23 < bridge> its their own fault 13:23 < bridge> because they'll come to us and ask for their account to be restored 13:24 < bridge> well u can also make requirements for passwords 13:25 < bridge> requirements don't work 13:25 < bridge> what would work is generating the password for the users 13:25 < bridge> requirements can't force good passwords 13:25 < bridge> it just doesn't work 13:25 < bridge> ok 13:25 < bridge> but saving the key file on the computer works? 13:26 < bridge> i feel like we try to achieve to much and it wont lead us to do any thing 13:26 < bridge> 13:26 < bridge> btw what about a simple email password auth on a per network basis, other networks require registering there, but with oauth they can verify this account is linked to x ddnet account 13:26 < bridge> I agree with you that it has the problem that a malicious client can fetch it 13:26 < bridge> not only that. i actually assume ppl will leak it by being stupid 13:27 < bridge> e.g. if we name the dir keys 13:27 < bridge> 13:27 < bridge> it doesnt sound like password related 13:27 < bridge> I wanted to hide it from the user. you think it'll still get leaked? 13:27 < bridge> well the attacker will ask to send maps/skins and keys dir 13:27 < bridge> i need it 13:27 < bridge> for the epic game play 13:28 < bridge> with private keys, it's comparatively simple. the server has secure auth before the connection is established 13:28 < bridge> name the folder "DO_NOT_SHARE" and put it in a separate dir than usual config 13:28 < bridge> .config/ddnet-secrets/ 13:28 < bridge> e.g. I thought about storing a key used to encrypt the key in the registry, on windows 13:28 < bridge> I thought that'd make it harder for people to tell you to fetch it for you 13:28 < bridge> yes 13:28 < bridge> or maybe in windows' built in password manager 13:28 < bridge> but that probs requires admin right? 13:28 < bridge> no 13:29 < bridge> the registry? 13:29 < bridge> user has their own registry 13:29 < bridge> ok 13:29 < bridge> HKEY_CURRENT_USER 13:29 < bridge> what about linux 13:29 < bridge> maybe some keyring there 13:29 < bridge> i legit havent seen a game do pubkey auth yet 13:29 < bridge> xd 13:29 < bridge> is the password your main motivation for the key approach? 13:30 < bridge> that and that it can also work for other networks without us 13:30 < bridge> and the offline capabilities, i.e. that you can have retroactive auth 13:30 < bridge> when the auth server is down 13:30 < bridge> but that also only partially works doesnt it 13:31 < bridge> e.g. by having a previous list 13:31 < bridge> which part? 13:31 < bridge> does teamspeak3 work? 13:31 < bridge> i mean if u use the pubkey hash as account id, u probably want it to be changable? 13:32 < bridge> I'd have multiple public key hashes that can be associated with a single ddnet account 13:32 < bridge> I'd have multiple public keys that can be associated with a single ddnet account 13:32 < bridge> but if u do a full recover 13:32 < bridge> the public keys can be verified even if the auth server is down 13:33 < bridge> i mean he lost his account 13:33 < bridge> and afterwards, the linked ddnet account can be fetched 13:33 < bridge> now he gets his email 13:33 < bridge> creates a new key pair 13:33 < bridge> this is all done by the ddnet account mapper 13:33 < bridge> or whatever u call it 13:33 < bridge> ye 13:33 < bridge> so its only partially doable offline 13:33 < bridge> yes 13:34 < bridge> so 99% of the time it has to be online anyway xD 13:34 < bridge> I wouldn't think so 13:34 < bridge> say you deleted your keys 13:34 < bridge> auth server is down 13:34 < bridge> you generate new keys 13:34 < bridge> you play on a server (it notes your public key) 13:34 < bridge> later, when the auth server is up again, you associate your public key with your account 13:35 < bridge> the server can then later associate your run with your account 13:35 < bridge> the auth server outage wasn't bad in this case 13:35 < bridge> mh yeah but then u could also say there is simply a fallback id for every client 13:35 < bridge> similar to timeout code 13:36 < bridge> the advantage of the public key is that it cannot be copied by the server you connect to 13:36 < bridge> and not MITMed 13:36 < bridge> etc 13:36 < bridge> auth tokens don't have that advantage, with them, you even have to verify the server as genuine, I think 13:37 < bridge> ah, you could do some zero-knowledge proof or so on them, but that sounds more complicated than doing public key auth 13:38 < bridge> but even then, if the auth key would be done for 2 days the runs might be lost again 13:38 < bridge> bcs u changed your keys twice 13:38 < bridge> yes 13:38 < bridge> if you change your keys before you authenticate, stuff might get lost 13:39 < bridge> but I wouldn't show the not-linked-to-an-account state as "authenticated" to the user 13:39 < bridge> but I wouldn't show the not-linked-to-an-account state as "logged in" to the user 13:40 < bridge> ok and about all the edge cases, did you think about account creation spamming and similar stuff.. are emails a must have with verification. ip bound account creation? 13:41 < bridge> can the challenge be computationally hard for the client? 13:41 < bridge> not in a way that stops our current day-to-day spammer 13:41 < bridge> but we could more easily introduce some "initial chat delay" that doesn't hurt users who already have a positive reputation 13:42 < bridge> also if its an offline list u probs dont want it to be a few GBs? 13:42 < bridge> dead accounts etc 13:42 < bridge> and ofc spammed accounts 13:42 < bridge> I would keep around accounts forever for now 13:42 < bridge> the good thing about accounts is easier heuristics to battle bad actors 13:43 < bridge> a little bit of social score kek 13:43 < bridge> yes 13:43 < bridge> dota 2 has that 13:43 < bridge> but knowing how hobbyless the script kiddies in this community are 13:43 < bridge> I think we can afford to save tens of bytes per email address or discord account or steam account that users create 13:43 < bridge> when u reach a low score u cant chat 13:43 < bridge> like in dota 13:43 < bridge> i mean yeah 13:43 < bridge> i said dota 13:43 < bridge> haha 13:43 < bridge> oh 13:43 < bridge> sure but every game server that fetches from ddnet has to keep in sync 13:43 < bridge> didn't see that 13:44 < bridge> he means dota 1 13:44 < bridge> the game servers could potentially forget it after a while 13:44 < bridge> I meant dota 2 ^^ 13:44 < bridge> dota 1 was more brutal 13:44 < bridge> never played it 13:44 < bridge> i wasnt even born 13:44 < bridge> u were 13:45 < bridge> "what's the price of boots of speed?" 13:45 < bridge> 3. 13:45 < bridge> 2. 13:45 < bridge> 1. 13:45 < bridge> kicked ryozuki 13:45 < bridge> bad ryozuki 13:45 < bridge> 450 13:45 < bridge> iirc 13:45 < bridge> too late, already kicked you ^^ 13:45 < bridge> xd 13:45 < bridge> actually dota 2 trivia asks stuff like this 13:45 < bridge> in the client 13:46 < bridge> btw we need a janitor like in dota 2 13:46 < bridge> our dev mascot 13:46 < bridge> https://dota2.fandom.com/wiki/Shitty_Wizard 13:47 < bridge> this would be robyt lately 13:50 < bridge> but yeah that the connection is directly secure between server client and even client client is nice 13:50 < bridge> 13:50 < bridge> So i assume for the later, the client needs to fetch this information too. and somehow the server's information cannot be trusted for this either (they pubkey hash of the client that the server might send as server info or smth similar) 13:50 < bridge> 13:50 < bridge> Already thought about such things? 13:51 < bridge> i already thought about such concepts for ddnet playground 13:51 < bridge> but only in theory 13:51 < bridge> how the server can prove to the masterserver that a specific client is online? 13:51 < bridge> I haven't thought about that yet 13:51 < bridge> yes 13:52 < bridge> because if we have accounts we basically want friend lists anyway 13:52 < bridge> and friendlist kinda must be secure too 13:52 < bridge> @heinrich5991 is there a way to exchange pub keys between users in a server 13:52 < bridge> my objective would be private encrypted chat between 2 users 13:52 < bridge> for whispers 13:52 < bridge> we can make a community server 13:52 < bridge> as trusted authority 13:53 < bridge> also we would need to add some handling for encrypted data right 13:53 < bridge> but yeah u need some kind of authority 13:53 < bridge> it would be nice to have it transparently on the game side, but the engine handles it 13:53 < bridge> what do ya mean? 13:53 < bridge> just encrypt everything 13:53 < bridge> and decrypt in network 13:54 < bridge> i mean that the engine encrypts and decrypts packets transparently 13:54 < bridge> before its a game msg 13:54 < bridge> i dont think we should encrypt everything 13:54 < bridge> ur position etc is not needed 13:54 < bridge> quic does that 13:54 < bridge> we kinda need to encrypt anything 13:54 < bridge> and its prob overhead no? 13:54 < bridge> oh 13:54 < bridge> i see 13:54 < bridge> anyway, I'm working on quic 13:54 < bridge> nvm then 13:54 < bridge> which encrypts everything 13:54 < bridge> nice 13:54 < bridge> this is definitly a compatiblity break right? 13:55 < bridge> who finishes first, heinrich with account system or me with ddnet playground? 13:55 < bridge> place your bet now 13:55 < bridge> what r u doign on the playground 13:55 < bridge> vulkan stuff? 13:55 < bridge> everything 13:55 < bridge> i break what cant be broken 13:55 < bridge> no, I don't like compat breaks ^^ 13:55 < bridge> im not doing anything, im a lazy bastard 13:55 < bridge> xd 13:56 < bridge> so u would support plain old udp too? 13:56 < bridge> doesnt quic allows better ddos protection 13:56 < bridge> idk 13:56 < bridge> xd 13:57 < bridge> I'm not opposed to stuff like "drop old-style connections when server is DoSed" 13:57 < bridge> if it's beneficial 13:57 < bridge> but I'm not sure if quic is good for ddos protection 13:57 < bridge> it'd enable us to use steam relays without trusting them though 13:58 < bridge> btw the funny thing is, i also implemented a quic backend 13:58 < bridge> 13:58 < bridge> but i use quinn for it 13:58 < bridge> heinrich uses the other 13:58 < bridge> very competitive 13:59 < bridge> is it easy to implement? 13:59 < bridge> the auth took the longest time, I think ^^ 13:59 < bridge> well generally yes, but i dont have any real key exchange mechanism yet, since im not connected to a master server or smth 13:59 < bridge> currently I'm refactoring and adding backcompat 13:59 < bridge> poggers 13:59 < bridge> also missing is: test on systems other than mine 14:00 < bridge> @Jupeyy_Keks btw are u working irl? 14:00 < bridge> if i am employeed? 14:00 < bridge> ye 14:00 < bridge> yes 14:00 < bridge> but i ignore that time 14:01 < bridge> i feel like lately i waste too much brainpower on my job to do anything xd 14:01 < bridge> and act as if i simply have less time now 14:01 < bridge> yep thats hard 14:01 < bridge> but somehow over the last 2 months i leanred to do both 14:01 < bridge> yeah 14:02 < bridge> @heinrich5991 is it in rust ? 14:02 < bridge> yes 14:02 < bridge> :poggers: 14:03 < bridge> pff ddnet pg is also in rust 14:03 < bridge> 100% except the annoying deps that need c libs 14:03 < bridge> compiler* 14:05 < bridge> https://www.reddit.com/r/ProgrammerHumor/comments/11yxx7g/gigachad_ken_thomson/ 14:05 < bridge> xD 14:05 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1088448340292812800/283ew0cn2dpa1.png 14:07 < bridge> so u r already far. did you use cxx for the packet compability then? 14:07 < bridge> no, I want to use the rust impl that I have lying around 14:08 < bridge> yeah ok thats the libtw2 advantages probs 14:09 < bridge> although I'm a bit anxious about bugs in there 14:09 < bridge> because it hasn't been tested in a widespread manner 14:09 < bridge> Why would he refuse? It'd be a good time to flex on the zoomers 14:09 < bridge> he is 80y old 14:09 < bridge> boomer flexing on da zoomers 14:09 < bridge> im surprised he can work 14:10 < bridge> i wanted to only refactors graphics first, but mixing rust idea of variants over enum structs and our way of putting stuff in a fat buffer and giving it IDs looked like a huge mess 14:10 < bridge> 14:10 < bridge> so i spent way too much time for this 14:12 < bridge> do u thin its possible to forget details about ur own language 14:12 < bridge> think 14:12 < bridge> i mean he is old 14:12 < bridge> I have this feeling that we'll end up with an account system that users don't understand at all, with features that are only appealing to the technically inclined, that has no use in moderation since we don't want to make it even a tad bit annoying to create accounts, has no use in detecting fakes because names are not singular, has no use in getting an accurate point count for people since we refuse to reset the ladder 14:12 < bridge> yeah thats my fear 14:13 < bridge> well we'll make the account system look like a normal one 14:13 < bridge> details, probably 14:13 < bridge> it all happens under the hood 14:13 < bridge> we don't want to expose any of that key mumbo jumbo to users 14:13 < bridge> c is full of subtle details 14:13 < bridge> it should just look like "log in" 14:13 < bridge> and "log out" 14:13 < bridge> like the users are used to 14:14 < bridge> brb 14:14 < bridge> A log in button which requires no credentials, a log out button that abstracts away an interesting key cycling scheme, and a way to associate a key which is supposed to be completely abstracted from you to an email 14:15 < bridge> It's honestly bizarre to say the least 14:15 < bridge> a log in button that logs you into your email address without a password 14:15 < bridge> that's maybe a bit alien for the user 14:15 < bridge> but I wouldn't describe it as "users don't understand it at all" 14:15 < bridge> they can also click "log in with steam", which doesn't even need any kind of interaction 14:17 < bridge> Even if it doesn't feel alien I feel it doesn't address much of any problem we have 14:18 < bridge> it allows us to attach reputation to players 14:18 < bridge> Which they can shed by just clicking log out 14:18 < bridge> allowing us to temporarily exclude new accounts from writing stuff when somebody is being funny spamming the servers 14:18 < bridge> Since we don't want to make it any more annoying to play without an account, we can't do much with reputation except maybe giving them an initial chat cooldown 14:19 < bridge> well we will see 14:19 < bridge> if u so far anyway it doesnt matter anymore 14:19 < bridge> but it generally feels more complex 14:20 < bridge> and the edge cases sound more scarry 14:20 < bridge> but yes from secure connection point of view its the cooler approach 14:21 < bridge> I really don't want to have annoying account creation, because I love the way I can let new players just play the game 14:21 < bridge> but even that can be slapped on top of the public/private key idea 14:21 < bridge> basically make the association with an email address annoying 14:22 < bridge> Also what do you have planned for names? 14:22 < bridge> discord-style 14:23 < bridge> sha256 hashes xdd 14:23 < bridge> How does that work for people that want to play without an account? 14:23 < bridge> they don't get an account name 14:23 < bridge> So we still get an account name AND an ingame name? 14:24 < bridge> I haven't thought about this a lot 14:24 < bridge> but currently I'd say yes 14:26 < bridge> Perhaps accounts are mandatory. 14:26 < bridge> e.g. Old username is: Aoe 14:26 < bridge> New account name is: Aoe#1234 14:26 < bridge> 14:26 < bridge> If the main part of your new account name matches an old username, then you can opt-in to include those points with this account (but they're marked as "unverified")? 14:27 < bridge> Perhaps accounts are mandatory. 14:27 < bridge> e.g. Old username is: Aoe 14:27 < bridge> New account name is: Aoe#1234 14:27 < bridge> 14:27 < bridge> You can opt-in to include the points of your former username with this account (but they're marked as "unverified")? 14:28 < bridge> Donators get to customise their #1234 number :trollet: 14:28 < bridge> https://github.com/ddnet/ddnet/issues/1234 14:29 < bridge> I think it'd be in our best interest to get rid of ingame names. It'd be extremely confusing to figure out if `Aoe#1256` with ingame name `Aoe#1265` who is claiming to be the `Aoe#1652` with the ingame name `Aoe` you played with last night is the real Aoe which you are supposed to know from another registry has the account name `Aoe#1255` 14:29 < bridge> Even writing that sentence confused me and I'm sure our resident rat can make it much more annoying than my non troll brain can come up with :konsti: 14:29 < bridge> $5/month to get blue tick :trollet: 14:31 < bridge> Will account names be on a first come first serve basis, then? 14:32 < bridge> Account names would be `Nameyouwant#random-4digit-discriminator` 14:33 < bridge> observation: discord and steam allow you to change your nickname arbitrarily, even on a per-server basis 14:33 < bridge> hmm... why does it work for them? 14:33 < bridge> I think your example is confusing, too 14:33 < bridge> But discord isn't a game, as soon as you click on my name here you'll get my real account name and discriminator 14:34 < bridge> It also has clearly visible account creation and server join dates 14:35 < bridge> since recently 14:35 < bridge> And the per-server rename is annoying enough that we disabled it in this server 14:35 < bridge> true 14:35 < bridge> but pls 14:35 < bridge> Steam idk, maybe faking isn't an issue there since no leaderboard would display your ingame name? 14:35 < bridge> keep display names 14:35 < bridge> else i can never be annonym 14:35 < bridge> that would be huge downer 14:35 < bridge> If you want to be anonymous I think you should be forced to log out 14:36 < bridge> bad design 14:37 < bridge> it is difficult to determine whether something works without deciding what the goal is 14:37 < bridge> So you want the ability to hide your account name from everyone else, I guess that's only possible if ingame names also exist 14:37 < bridge> But that makes it extremely annoying to have a friend system of any kind 14:38 < bridge> its probably not possible to make a system that prevents faking, allows anonymity, tracks points, is convenient to use, etc. but picking only a few of these is possible (?) 14:39 < bridge> allows anonymity without logging out is where my brain goes logical contradiction 14:40 < bridge> I can't think of a way to have one set name while also allowing anonymity 14:40 < bridge> The game server simply doesn't expose the name 14:40 < bridge> The non display name 14:41 < bridge> Would someone still be able to report that player? 14:41 < bridge> It's easy to do technically, but then you don't have one set name, which means we can't have friends lists that guarantee that you are talking to the same person 14:41 < bridge> i assume reporting would be the same as it is now by using ingame name or other descriptions, and the admin could see the account name 14:42 < bridge> but I mean either you're anonymous, or other people can find you in the server browser 14:42 < bridge> I can't see how to do both 14:42 < bridge> maybe there could be an indicator for when someone is using their "real" name but no indicator otherwise? 14:42 < bridge> I don't see how to do both 14:42 < bridge> that way it would allow for verification and anonymity 14:43 < bridge> Problem is pros need a anon button 14:43 < bridge> In this game nubs and pros play same server 14:43 < bridge> Is cool 14:43 < bridge> But also sucks hard 14:43 < bridge> They ask u the whole day 14:43 < bridge> they could just use a different ingame name and lose the indicator but still the ranks would get logged t the same account? idk 14:43 < bridge> Yeah 14:44 < bridge> The account name would also have to be not displayed 14:44 < bridge> right 14:44 < bridge> The game server should know but not expose 14:44 < bridge> i think thats how it works for bw server accounts 14:44 < bridge> Which creates an even more confusing situation. `Aoe` that is logged in to an account, but you are not allowed to see the name 14:44 < bridge> Is this really Aoe? 14:44 < bridge> the account could be associated with one "real" ingame name 14:45 < bridge> then I register an account with the real "noby" name 14:45 < bridge> so if its real Aoe's account and he is using name Aoe it would show that 14:45 < bridge> isn't that 'anonymous' mode that we talk about quite close to the offline or 'invisible' mode in steam? 14:45 < bridge> :thonkery: mh 14:45 < bridge> Associating with one "real" ingame name is immediately back to the very start where konsti registers all the names 14:46 < bridge> Even if you are offline or invisible in steam most games will still report your steam id on the scoreboard where you can go to peoples profiles 14:46 < bridge> true 14:47 < bridge> true, they have a underlying real steam id behind 14:47 < bridge> i dont think how this cant work here 14:47 < bridge> see* 14:48 < bridge> Maybe if we make it extremely clear who is logged in, display real discriminators in a very distinct way only when the scoreboard is open, then maybe it's easy enough to spot fakes and lets people be anonymous too 14:48 < bridge> faking initially will be a issue because we start from a blank state, trust is then formed when you make ur friendlist network 14:48 < bridge> Maybe a unique username is better 14:49 < bridge> Discord approach I'd say sucks 14:49 < bridge> You can't even make a friendlist if the server never reports the account name 14:49 < bridge> like most gamers do 14:49 < bridge> tell ur id via discord 14:49 < bridge> to ur friend 14:49 < bridge>