
Ask HN: How do we pick an user ID while building a social-platform? - palakz
We&#x27;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&#x27;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.<p>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.<p>How do we or what do we choose as a User identity? Providing numbers-identity to newly signed up users doesn&#x27;t seem that attractive to us.
======
mjevans
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.

------
edent
For internal purposes, a 64 bit GUID will be sufficient. Look how Twitter uses
Snowflake -
[https://github.com/twitter/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](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.

------
mindcrash
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 :)

~~~
snowwrestler
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.

------
Freak_NL
> 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?

------
h_o
Just so you know, I googled Meraki and got this:
[https://www.meraki.com/](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)

------
56k
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.?

------
dyeje
You might want to consider a name that isn't owned by a tech giant:
[https://www.meraki.com/](https://www.meraki.com/)

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

------
flukus
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.

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

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

------
cryptarch
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.

~~~
onion2k
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.

------
ohstopitu
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.

