Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracker and improved friendlist #81

Open
ghost opened this issue Feb 13, 2016 · 4 comments
Open

Tracker and improved friendlist #81

ghost opened this issue Feb 13, 2016 · 4 comments

Comments

@ghost
Copy link

ghost commented Feb 13, 2016

Add a char[32](or 16) which is sent to a modapi client as unique identification of players. It should be a config value (though changeable) and the default value is a random string filling the char. Add an entry in the gui with a text section and a "regenerate" button next to it

Usage:

  • enhanced friendlist which keeps track also after name/clan change
  • maybe some sort of authentification or timeout protection, backdraw is, the id is available to any client who asked the server for server info or is on the server.
  • statistical usage (general statistics like what time are people playing what (=far better stats like what gamemodes ate played the most because, not only registered the most) or player/clans based stats where you can search based on name or based on id. If someone registeres a clan, they could decide whether to display all unique players who had the corresponding clantag or add Player manually by id. Non-registered clans should not be displayed there (that would provide a clan list, too)

I think we should implement this, it may be a tracker, but it's like the ad ID you are carrying in your phone. You can reset it at any time (Noone would see you as friend and so on), but you can also get the id and insert it into another pc.

Some could even develop a sync based on these ids (sync friend list or favorites, maybe config values, too)

@necropotame
Copy link
Member

All of these features are needed, I agree. However, with this implementation, it's too easy to stole the identity of someone. You just have to create a fake server to collect some IDs.

  • Server authentification : could be done by using a cookie system, with one cookie per server, or cluster of servers
  • Player Statistics : if it's only based on public informations, it can be easily faked by spamming the server list with false servers. A better approach is to provide a statistic system for a cluster of server that share some password. Player identification can be done using the cookie system
  • Client sync: Can be done with dropbox ?
  • Friendlist based on something else than nickname : if you change your name, it mean that you want to change your identity. I'm not sure if this point is important.

@ghost
Copy link
Author

ghost commented Feb 13, 2016

Firstly, you don't need a server in order to steal an "identity" because clients would get them too. That's because server authentification isnt gonna work with that.

There has to be at least one possiblility to move or copy such id's to a second client.

With the statistics I meant that some server can actually grab the server list and information and don't see, what server are registered, but instead which server are played on (by mod).

Client sync: I thought about doing it with p2p via udp hole punching and involving our modapi master server (udp hole punching means basically that two peers connect to each other even through NAT with the help of a third server (both connect to the third server and establish a connection through it, punching a small hole in nat/firewall and then data goes directly from one to another))

Friendliest: you have to differ between people who want to change their identity or people just not having a good nickname or changing it rapidly. In teeworlds we have the problem that many people, especially newbies change the name rather often because it's just a client setting. Maybe we add a notice that change client doesn't mean changing identity.

Server auth: thought about Kerberos? (like any other game is using :D). Then we could just generate a random token to auth against the Kerberos third server. Unfortunately that would he a more central solution (thought about random tokens for each server, too

@GutZuFusss
Copy link

A char32

Ok ;D

@ghost
Copy link
Author

ghost commented Feb 17, 2016

Thanks for your very appropriate and good notice, @xushWT
I wrote char[32] but our nice github made a link to nowhere out of it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants