from Hacker News

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

by palakz on 8/8/16, 7:23 AM with 14 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.

  • by mjevans on 8/8/16, 8:58 AM

    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.

  • by edent on 8/8/16, 9:36 AM

    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.

  • by mindcrash on 8/8/16, 3:59 PM

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

  • by Freak_NL on 8/8/16, 9:08 AM

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

  • by h_o on 8/8/16, 8:58 AM

    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)

  • by 56k on 8/8/16, 9:06 AM

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

  • by dyeje on 8/8/16, 6:09 PM

    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.

  • by flukus on 8/9/16, 6:39 AM

    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.

  • by evilneuro on 8/8/16, 11:19 AM

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

  • by fratlas on 8/8/16, 8:38 AM

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

  • by cryptarch on 8/8/16, 7:30 AM

    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.

  • by ohstopitu on 8/8/16, 12:32 PM

    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.