Merge multiple user accounts #26

kristjan opened this Issue Apr 9, 2012 · 13 comments


None yet

3 participants

kristjan commented Apr 9, 2012

After a user has created N accounts using N profiles (eg, they log in to one app with Facebook and another with Twitter), they should be able to merge them into a single account with multiple profiles.


Should we let apps force this? When they have the id of the account they want any others under, they could force an auth to it by adding &account=X to the /oauth handoff, and hallway when it encounters an existing account for that auth will re-ACL it to the given id?

@smurthas what do you think?


I know ZeroBird wants this. It feels a little funny to me because

  • We're trusting infinity app developers to merge people properly (malicious or no)
  • We become account storage, not account management
  • It's creates a secondary auth paradigm when we should be focusing on doing the primary one well

Seem like it should be on an as-needed-and-approved-by-Singly basis at very least (most, i suppose)


Legal says there are ramifications to this that we need to pass down to these app developers. Specifically, that because we're not doing the user authentication ourselves, the app needs to make reasonable efforts to do the right thing (which they would anyway). Also, because we're no longer involved in the flow, the user needs to somehow be told and accept that Singly exists and is storing their data.


@kristjan I don't think that stuff is relevant to this issue?

I'm also talking specifically here about merging profiles only within that app, not for anything else, so I don't think this has any ramifications or concerns outside of a single app. This essentially would meld two tokens together for a single app.


I'm pretty sure it's relevant

  • The user has never themselves hit, yet their data is being kept there, which usually has a Privacy/TOS associated with it
    • It seems reasonable to me that this could fit under a "third-party service" clause on the app side
    • In any case, we need/want a relationship with this user, because them knowing where their data is is the whole point
  • The app could send us a Facebook token for Francine to attach to an account that has an existing link to Ferdinand, and now they can see each other's potentially private data when they log into the app
    • Singly did not get a chance to verify Francine's identity

Drafts of our documents are on the way, so I'm not saying we should block on them. Just keep in mind that this stuff is weird and needs to be thought/worked out.


yep we're def talking about different things!

I'm proposing that we let an app provide an existing token attached to a new /oauth/authorize request to ensure that any auth that succeeds from it is then associated with the given (verified) token. We've verified everything, we're just honoring the app's request that it's a secondary auth on an existing token(acl).

The ToS/Singly interactions should be in another issue somewhere else, this is about merging within just an app :)


Ahhhh, I lost context - need to stop replying to issues from Email vs. on GitHub. So this allows the app to merge two Singly access tokens into one; no third-parties involved.

I wonder if there are cases when the user made two accounts on purpose and wouldn't want this to happen. Until an app requests it and has a use case, I think we should limit it to the user's own account management.


Every app has encountered this and complained, I even have a broken (split) ketchup due to it right now. It's not a "merge" call manually either, it's a "you're auth'd with X already, and now you want to add Y" pattern but when Y was added in a different browser session already that just switches the token to Y instead of the expected add.

I think it's a bug that this doesn't already work this way and would like to provide the means for apps to force/fix it unless anyone has any concerns... talking this through has vetted mine already so I think I'm good :)


The original issue here was a user feature request. We are now talking about API endpoint to provide a workaround for a bug in our code. @quartzjer, can you file another issue for the bug we have? We can take a closer look at it, and then see if we still need the workaround, or whether the bug fix actually solves the problem.


the multi-account bug is fixed, is this still important before ACW?


moved out of the milestone.


This madness is fixed with the new /authenticate endpoint.

@smurthas smurthas closed this Nov 17, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment