If we allow these characters we have to do replaces for them in the app subdomain routes otherwise they won't be valid subdomains.

@coadler I think we should add a "normalized" username field which is the username but mangled to be subdomain-safe, and have a unique index on that. Thoughts?

If we allow these characters we have to do replaces for them in the app subdomain routes otherwise they won't be valid subdomains.

@coadler I think we should add a "normalized" username field which is the username but mangled to be subdomain-safe, and have a unique index on that. Thoughts?

I agree. What do you think should happen if a username doesn't conflict but the normalized one does. Should we fail or try and make it unique?

I don't think we should have the concept of a normalized one... that seems weird to me. Maybe we eliminate the idea of named subdomains and move to a workspace UUID approach?

I'm in agreement with this based on POSIX Standards.

Can I hand this back to someone else who is more familiar with the topics discussed above please?

I agree. What do you think should happen if a username doesn't conflict but the normalized one does. Should we fail or try and make it unique?

On new user creation both must be unique, the username you enter and the hidden "normalized" variant. During migration we can write the migration to avoid conflicts

Maybe we eliminate the idea of named subdomains and move to a workspace UUID approach?

app-name--a3cf0290-92bc-4f87-b91b-7afed4f12896.dev.coder.com does not look good and is an extremely long subdomain. UUIDs are 36 characters, you can save 4 by removing hyphens, and you can save a further 6 by using base32 instead of hex.

Having a hidden "normalized" username field for URLs that is guaranteed to be URL-safe and unique seems like a better option to me, and looks much better in URLs. It is also fairly cheap to implement, just a function to convert a username to a URL-safe version and a migration to apply that retroactively to existing accounts.

The standard you linked is about posix filenames not usernames, and even this might not be enough. LDAP for example allows more characters than this in the user name field.

I can take over on this but I'll wait until kyle makes a decision before starting anything.

@deansheather what happens if I have:

kyle.carberry as one user, and kylecarberry as another... the URL-safe name would conflict.

@kylecarbs we would have a unique index on the URL-safe username so the second user couldn't be created. We don't need to write a complicated migration for this since all usernames currently are already URL-safe once lowercased, and we already have a unique index on lowercase.

I think that rationale is likely to confuse people, TBH. If I can't make my username kyle because someone else is k.y.l.e, that would frustrate me. A reasonable alternative is to strip out non-URL safe chars but has a different string in the URL to identify which user it is.

TBH. If I can't make my username kyle because someone else is k.y.l.e, that would frustrate me.

I don't think this is frustrating at all. The error would only occur in deployments that use non-URL-safe usernames and the error message would clearly say "you can't use the username 'kyle' because a user exists with a similar username 'k.y.l.e' which are identical after stripping non-URL-safe characters" or something along those lines.

This is a similar problem to capitalized usernames. We allow uppercase characters in usernames at the moment but we unique index on the lowercase username. If someone had the username Kyle you would not be able to register as kyle. Obviously this is a less annoying case than dots and underscores though.

I don't think it's worth having ugly URLs with random IDs for apps just to support usernames with periods and underscores. The username conflicts seem few and far between so I don't think we should be optimizing for them.

We could make support for non-URL-safe characters disabled by default and add a flag/env var to enable it so less people run into the problem to begin with.

@kylecarbs ^

This Pull Request is becoming stale. In order to minimize WIP, prevent merge conflicts and keep the tracker readable, I'm going close to this PR in 3 days if there isn't more activity.