Ask HN: How do we pick an user ID while building a social-platform?
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.
14 comments
[ 2.0 ms ] story [ 18.0 ms ] threadYou would then have to enforce username uniqueness when assigning/renaming usernames.
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.
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 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.
If you don't want to allow that, why not just to fb_{facebook_id, tw_{twitter_id}, etc.?
No normal email only sign-up? Does your demographic not include people who prefer not linking their accounts to external identity providers?
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.
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 :)
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.
Also, I recommend just using email for logins. They can change their username whenever, but the email stays the same.