Ask HN: How do we pick an user ID while building a social-platform? | Hacker News Reader

Ask HN: How do we pick an user ID while building a social-platform?

16 pointspalakz14 comments

We're a team of 20 and 22 y.o. building an idea-sharing platform called Meraki. This is our very first try at building an app and also the very first try at building a social platform. The platform that we're building - Meraki - uses only Facebook and Twitter APIs to signup and login. The new users are then asked to pick a username. We want to provide a functionality to users to change their usernames later on.

Now, the problem is that we cannot use FB username, FB email, Twitter username or Twitter email or the Meraki username as a constant user identity for their actions on the app because it may vary as user can change it anytime.

How do we or what do we choose as a User identity? Providing numbers-identity to newly signed up users doesn't seem that attractive to us.

View on HN

You don't use an external ID.

You use an internal ID that you control, which fits the requirements of your design.

External authenticators can then associate to your internal account as you design. If the external authenticators can be 'renamed' you'll want to insist on a sidechannel (often email) and recovery process for that channel (or SMS is popular).

Any data you collect can and will be used against your customers in the event of liquidation and/or oppressive governments in the jurisdictions your servers are hosted in: I recommend allowing 'email only' as an option for your users.

For internal purposes, a 64 bit GUID will be sufficient. Look how Twitter uses Snowflake - https://github.com/twitter/snowflake - that's a scalable way to generate unique IDs which won't ever be revealed to the user.

For default user names, I quite like how gfycat does it - http://gfycat.com/about - AdjectiveAdjectiveAnimal - so a user is given a default name like "ReluctantCandidWombat". Fun, unique, hard to iterate, and hopefully provides an incentive to the user to change it later.

You will need two things:

One, a human facing unique id (or 'nickname') -- such as palakz -- which you can use in your HI and whatnot. This one could even change over time.

Two, a computer facing unique id (or 'subject') which uniquely identifies the person in your application, usually a guid, long integer or whatnot. This one never changes.

Then combine the two and put them either in a secure (encrypted) cookie (for your web app) or token (for your mobile app) and you are basically done.

This for example is how authentication on Twitter works. Every person on Twitter has a unique id (probably designated through Snowflake mentioned below) and a self chosen name (which you can also change if I remember correctly). The former is stored in a secure cookie (in the web app) or a token (in the mobile app) together with some other static user information (e.g. nickname). When visiting a page requiring authentication the id is exposed to the backend code so it can recognize who you are and for example decide what actions to take (e.g. take you to the onboarding page or your personal timeline)

Hope this helps :)

Looking at Twitter is a good way to anticipate some edge cases.

For example, think about identity from a social perspective. On Twitter, identity is defined not just by the "@handle", but by the name and avatar image as well. Changing the name or avatar has little consequence in Twitter's platform, so some users do that a lot to play with their identity.

BTW, playing with identity--defining it, testing new attributes, evolving it over time--is a MAJOR attraction of social networks, if not the main reason anyone uses social networks at all. If your platform attempts to treat identity purely as a fixed thing, you're going to have trouble with long-term engagement. You need to give users identifying attributes that they can easily change regularly.

Speaking of which--while Twitter users can change their @username, it breaks all previous conversations. Why? Because Twitter manages conversational references solely by the text of the tweet. So if you change your @username to @newname, all those @username references in old conversations will go black (i.e. not be linked anymore).

I believe it also releases your old @username for someone else to register!

So, it seems quite uncommon for folks to change their @usernames on Twitter. In fact the few people and orgs I know who wanted a new ID on Twitter just started a new account and then used their old account to tell their followers to follow the new one. That way old conversations stay linked and in control. And it's a sort of follow "list cleaning" in that only the most engaged folks follow you to the new account.

> The platform that we're building uses only Facebook and Twitter APIs to signup and login.

No normal email only sign-up? Does your demographic not include people who prefer not linking their accounts to external identity providers?

Just so you know, I googled Meraki and got this: https://www.meraki.com/

My opinion is that having number based user accounts is fine as long as you don't provide any access to them in any of your request parameters.

They should be safely maintained server side, within sessions, and any request for other user's details is done via their username.

My last point is that a user should never be able to find out their user id #.

If you allow users to change their username, then you put the responsibility in the users hands to update their external links.

Eg. If I change my twitter handle, I have no idea how many places I have that referenced - so I just don't do it (not sure if you even can change it at will actually)

You need to have your own IDs IMHO, so that people can associate multiple accounts (ex., both Facebook and Twitter). Could you go with something simple, like a timestamp with microseconds or a timestamp plus a random number?

If you don't want to allow that, why not just to fb_{facebook_id, tw_{twitter_id}, etc.?

You might want to consider a name that isn't owned by a tech giant: https://www.meraki.com/

Also, I recommend just using email for logins. They can change their username whenever, but the email stays the same.

Others have good suggestions, but I would also add that login and user should be decoupled. A user should be able to login with facebook or twitter (or email) and have them be the same account.

Good luck using the name "Meraki"; Cisco will have a shitfit.

combination of uuid and uui4 - unique and will never collide.

You use a GUID or counter as a user ID, and add a username field which resolves to this ID?

You would then have to enforce username uniqueness when assigning/renaming usernames.

Counters are a bad idea if they're ever used in a user-facing context. They're trivially enumerable so an outside party can write a script that iterates over them, which is usually a bad thing. That's easy to block, but it's better to design the system in a way that makes it impossible in the first place.

Plus, user-facing counters can leak business information - if I sign up and see example.com/user/1234 as my user page and then I create another account a week later and get example.com/user/1235 then I know the platform isn't growing very quickly.

tl;dr Don't use counters for anything that that'll end up on the frontend.

if you are using a noSQL database like mongo, couch, or even firebase, an _id will automatically get generated when you insert an user. You could create a hash of that _id as your user id.

Reply on news.ycombinator.com