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

User + Connection ID refactoring #48

Open
prawnsalad opened this issue Oct 6, 2017 · 1 comment
Open

User + Connection ID refactoring #48

prawnsalad opened this issue Oct 6, 2017 · 1 comment

Comments

@prawnsalad
Copy link
Contributor

Currently user IDs are just the user names. Connections do not have an ID but the name is being used as an identifier.

To bring everything inline and easier to store in databases I propose we do the following:

  • Users and connections have both an ID and Name field.
  • Internally we use the ID fields for identifying instances, never the Name field.
  • We can then provide ways to change the Name field with suitable restrictions while the ID fields stay the same.

Baring in mind the different datastore backends that may be possible, I think that using standard UUIDs v4 would be the best ID format to use. Most database engines support these in some form and reduces friction in generating unique IDs in each datastore implementation.

Thoughts before I go ahead with this?

@DanielOaks
Copy link
Member

Hmm, I could see this happening, yeah. We'll need to keep the names unique anyways so that people can login using them, but if we use IDs as the primary identifier we can change users' names without worrying too much.

One interesting thing to consider, if we allow users to change their own usernames, we won't be able to use their username as the username send via IDENT (if we support ident). For big installations at least. Since nets will ban based on the reported ident username, we can't just let users change that at a whim.

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