Hacker News new | past | comments | ask | show | jobs | submit login
We Need a New Username System (venturebeat.com)
91 points by adamotaku on Apr 2, 2016 | hide | past | favorite | 35 comments

Blizzard's Battle.net has an interesting naming system which a few others have adapted.

You can pick any username you want. But the username is appended with a pound sign and a 4 digit number. (for example, my Battletag is minimaxir#1667)

Everyone wins the branding wars. Presumably, there aren't 10,000 people who want the same name.

Discord implemented the same thing, and I'd like to see more systems do it too. It works really well, especially when users can swap usernames at will.

> Presumably, there aren't 10,000 people who want the same name.

Pretty sure I've seen someone with a 5-digit number after the hash.

In any case, you're right, it's a great system. In most Blizzard games, the name you want is over your head. In rare circumstances you could have >1 person with the same name in the same game, but even then it's not going to be confusing because they'll be playing different heroes, or be your opponent, etc. Much better than WoW where people wind up choosing names like Årthäs to get sort-of the name they want.

However, the real reason this is a problem in the non-gaming world is that URLs and domain names need to be unique, so Blizzard's system can't apply.

And what's the practical difference between minimaxir#1667 and minimaxir1667, other than there's no "minimaxir" with no numbers?

Numbers are allowed in the username (https://us.battle.net/support/en/article/700007) so using a pound as a delimiter is necessary to separate numbers at the end of a Battletag and the unique identifier.

Unless you're hovering your mouse over them, it only shows minimaxir.

Like all things in life the username scarcity problem can be solved with gamification. Initially all users are assigned a unique number as their username. By reaching various predefined goals users can earn new characters to use in their username. For simplicity's sake I'll restrict my examples to ASCII characters. Made your first 20 comments? You've earned a random character. It'll be like opening a pack of Magic cards. Will you get a highly desirable 'e' or much less useful 'Z'? Created your first 3 posts? Get another random character!

You'll be able to trade your characters with other users. You need a 'Y' to form "YoloSwaggins", so you trade your desirable 'e' for a 'Y' and a 'g' (you need 2 'g's). You can also sell characters you have no need of or buy ones that you want, all through the website's online marketplace that takes a modest cut for themselves of course.

You can't just change your username at any time though. Each character change requires a special character change token that has a small chance of dropping with each achievement. Or you can buy character change tokens in packs of 3 from the online shop.

Have you considered that this introduces a huge amount of complexity to a practically trivial issue?

This is an interesting approach! A problem I think would come up in this case is that it encourages spam and low quality content to collect points to unlock desired features. So strict moderation (likely by the community as well) could be needed, depending on the type, target audience and size of platform this is implemented on.

A positive side effect, which I absolutely love, is that the more active people get to choose their name, while the more passive ones have to stick with the "less attractive" name for longer. Which makes complete sense as the screen time for active users' names is considerably higher.

Very interesting concept.

But wont your scheme make the most desirable usernames, the short ones, the cheapest? Or is your aim to shift the demand to longer names as they now convey status?

Slow day on HN I guess?

Instagram isn't one of the offenders, like you say. Usernames can be changed at will and logins are done through email.

I regularly change my username to a beer-pun when I've had enough of the current one.

I also don't really like your gamification grand plan. Names are too common for that to work. You'd be in the same position you were in before with a name like "Adam" because you'd be competing with "Adam Sandler" for example and he'll whoop your ass on "most pins/tweets/likes/friends/wins".

I signed up for instagram because some dipstick put my email address into the app and signing up and claiming the address was the only way to stop getting reminders from them to confirm the address.

(That is, they have their problems too)

Now that is a brilliant and evil marketing scheme.

But you can't change your username to one that is in use, right? That doesn't solve the squatter problem.

But that's exactly the point -- it makes a lot more sense for someone like "Adam Sandler" to have "Adam", rather than someone less popular. So it's not at all the position you were in before -- this is the whole improvement!

What if there's a more popular Adam than Adam Sandler? And does this mean I need to reserve the name "Adam" on my service, so that one day when Adam Sandler comes along, he'll be able to get the name I assumed he wants?

I think there's an unanswered question here: Why should popularity be the decider for who "deserves" a username, given the fact that it's a pretty awful metric for most use cases?

A "username" should be a uuid. The user should be able to put a string of their chosing next to it (an alias, real name, etc), and a service like gravatar can be used to distinguish between users who have the same string.

Right? Lets look at mature-er systems like Linked-In. There's plenty of "John Smith" or "Jane Kim", but they're all represented as different people. No stress, ugh.

LinkedIn allows users to choose a username for a unique link to their profile (e.g. https://linkedin.com/in/minimaxir ), which is subject to the same rules as normal usernames.

True. And that username is not in the main pipe for searching.

Each service is the sole owner of their own namespace.

If you want to solve this, go distributed and own your own namespace.

Instead of ${walledgarden}, run your own GNU social instance and federate.

The "minimum length" idea is sort of interesting. But is this really an issue? Many early Twitter users with one-letter names still use the service. Not all early adopters want a "one night stand" with your product -- many want to adopt it early. Also names aren't universally unique, and this often causes people to get more creative with their handles, which I think is a good thing.

I've been building a no-sign-up product, and now I'm getting ready to launch accounts. So recently I let existing users reserve their usernames in exchange for some feedback on the product thus far. I got some great feedback, and now they get an awesome permanent URL on the web. They deserve it, because without the early adopters, there are no late adopters.

I recently bought a domain name under one of the newer TLDs. I hadn't really paid much attention to how these work, but the registry is Donuts and they seem to be using some kind of market-based pricing scheme. As a result the names I wanted were available on namecheap.com, they cost significantly more than what a .com or .org would have cost, but were not unaffordable. That seems to be working to diminish squatters, since it's too expensive to buy a bunch of names and then hope you can resell them.

I feel like icq got this right, no one had a name, just an identifier of n digits. If we all used some central service that provides ids, user profiles could be linked between services.

Because numbers are impersonal and the shorter and "nicer" they are, the easier they are to remember, market for short ICQ numbers was huge and phishing and hacking for these went rampant.

It was a terrible system, the worst, really.

Usernames aren't a problem, discoverability is. Vanity IDs aren't a problem as well, but an opportunity and they are being sold either for money (registered trademarks, "lucky" phone numbers, short or custom license plates) or engagement (Facebook's vanity URLs for pages).

Vanity id shouldn't affect discoverability and it really doesn't these days. Do Nimble CRM's customers have confusion by @nimble on Pinterest being taken by the Author? Don't think so. pornhub.com ha more traffic than sex.com and doesn't seem to be bothered.

I'm not a number, I'm a free man!


All the solutions he mentions (including the Blizzard system) is just a more complicated first-come-first-claimed. Gamification to get a shorter name, is the same system with a slightly more complicated process of the registration after-first-registration. Blizzards idea that you always see the username and not the uid identifier is probably as human-friendly as it can get.

It's surprising that the solution of simply sharing usernames between websites wasn't mentioned, so that everyone only has to get their preferred username once -- something like https://onename.com/.

And if different sites have different people with the same username?

For example, on various gaming sites I use, there are different longstanding members with the username 'Mario'. So who gets it with that sort of system?

How about two companies with the same name in different fields? Apple computer vs Apple records?

There'd be conflict over usernames, but the conflict would only happen once ever, instead of happening once on every new site someone wants to sign up on.

"First-come, first-served originated with domain name registrations" - what!? That's not even wrong, so far as I can tell - it is an answer for some entirely different question. Perhaps this author does not understand that usernames existed long before the Internet did?

The proposed policy of shorter username requires more investment (time and activity) strikes me as being somewhat like the amateur radio handle scheme: the shorter (and more desirable, especially for morse code) handles require a higher license class.

Why would I take advice on naming from someone who wrote (twice!) that names are subject to copyright? And even if I did, why would I take legal advice from this person?!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact