Comment by josephg
20 hours ago
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names.
This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can also be used to prevent squatting and reuse attacks - just burn the full account name if the corresponding user account is ever shut down. And it prevents early users from being able to snap up all the good names.
Notably Discord stopped using that format two years ago, moving to globally unique usernames.
Their stated reason[1] for doing so being:
> This lets you have the same username as someone else as long as you have different discriminators or different case letters. However, this also means you have to remember a set of 4-digit numbers and account for case sensitivity to connect with your friends.
[1]: https://support.discord.com/hc/en-us/articles/12620128861463...
The actual reason here, implied but not stated outright in that one, is that Discord being a public platform, having only numbers to discriminate between users makes it extra-trivial to impersonate someone else. Obviously you can still do some of this with unique usernames (you see slight misspellings, adding harder-to-see characters like periods, etc, as strategies), but these are more complex to execute on at scale and easier to block once and reduce the impact, vs being able to use ~arbitrarily many post-username numbers.
(i work at discord)
Not saying that wasn't ONE of the reasons but the main reason was really that a large chunk of users had no idea that they even had a discriminator, as it was added on top of your chosen username. "add me on discord, my username is slashink" didn't work as people expected and caused more confusion than it was solving. This wasn't universally true either, if you come from a platform like Blizzard's Battle.net that has had discriminators since Battlenet 2.0 came out in 2009 it was a natural part of your identity. End of the day there were more users that expected usernames to be unique the way they are today than expected discriminators.
Addressing that tension was the core reason we made this change. We are almost 3 years past this decision ( https://discord.com/blog/usernames ) and I personally think this change was a positive one.
It was honestly a downgrade i ended up just putting the 4 digits I had before at the end of my username cause surprise the name was taken immediately
I haven't logged in since . I wonder if they'll delete my account eventually - as I essentially don't have a username because of that
2 replies →
The stated reason is obviously not able to justify the change; either they have an internal reason they're not willing to admit to, or someone at Discord just went crazy.
Imagine trying to connect with your friends... by telephone.
IMO a better general solution is UUIDs and a petname system, at least as far as chat apps are concerned.
For buckets I thought easy to use names was a key feature in most cases. Otherwise why not assign randomly generated single use names? But now that they're adding a namespace that incorporates the account name - an unwieldy numeric ID - I don't understand.
In the case of buckets isn't it better to use your own domain anyway?
Having worked in this space for years, it's not nearly as bad as you think. IaC tools can all look up the accountId/region for the current execution context and you can use SSM Parameters to give you a helpful alias in your code.
Also, if you have a bunch of accounts, it's far easier for troubleshooting that the accountId is in the name: "I can't access bucket 'foo'" vs. "I can't access bucket 'foo-12345678901'"
I like it for buckets, but adding a four digit code won't help with the package hijacking side of things - in fact might just introduce more typo/hijack potential. It'll just be four more characters for people to typo.
I just want to be able to use a verified domain; @example.com everywhere.
That still has "squatting" risks as described in the original article though, domains expire and / or can be taken over.
But you already have a domain for whatever you're doing so presumably that's going to be a threat either way.
For particularly high risk activities if circumstances permit you can sidestep the entire issue by adding a layer of verification using a preshared public key. As an arbitrary example, on android installing an app with the same name but different signing key won't work. It essentially implements a TOFU model to verify the developer.
The requirement for unique user names is a little strange, I was putting together a small internal tool recently and after a bit of thought decided to use an opaque internal id for users and let the users pick and change their name and secret at will.
I think for a larger public service it would make sense to expose some sort of internal id(or hash of it. What bob am I talking to?. but people share the same name all the time it is strange that we can't in our online communities.
The .NL gTLD used to work like that for personal registrations (ie individuals without a business registration). $name.NNN.nl where you were allowed to choose the number.
It won't surprise you the scheme never caught on and has been decommissioned (you can now register any available domain as an individual as well). The difference is probably few people use a personal TLD, but many use a name on some social media.
Small correction: .nl is a ccTLD, or country code TLD. Not a gTLD, or generic TLD.
I didn’t think it was possible to have a personal TLD - did you mean a personal domain?
Well, I guess it's possible now to have a personal TLD, but yes, I meant domain.