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
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
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 singly.com 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.