This looks interesting, but I had a few questions:
1. If I use this do I have to handle account linking? Ex: Monday user logs in with FB, Tuesday with Twitter. Do you pass a unique key saying this is a canonical "user"?
2. From the gem docs it looks like you're returning a hash of whatever the social provider returns and explicitly not trying to "normalize" the result (ex: One service might return "email" and another "email_address"). This seems fairly different to what happens with Devise and Janrain. Is this going to change with time or do you see this as key point of differentiation.
3. What happens if you guys win the lottery and all retire to a tropical island? How screwed am I with my users?
Great questions -
DailyCred does the account linking, so if someone signs up with email, and then later Facebook, the accounts are linked. You can also explicitly connect users to multiple to services, for ex if you want to have them add their Twitter account after they're logged in.
We do both normalizing the common data, and returning the raw info/access tokens for the social provider. So if you just need the user's name you can grab that from us, but if you want some data that's unique to FB you can still access all of that. We look after maintaining these social tokens for you.
Yay - we win the lottery! Or another scenario, you decide to roll your own later.. We store passwords using standard (non-proprietary) bcrypt hashes so you can implement your own auth system if you like. And social permissions are granted to your Facebook/Twitter/Google apps, so you own that connection to your user too. We're basically a proxy in the middle that handles the glue between all the providers.
1. Yes, if a user forgets how they logged in and use a different provider, we either log them in or prompt them to use the first provider, depending on if their account email has been verified.
2. We do normalize common fields. It's done server-side however so you won't see it in the gem.
3. Not screwed. :) You can export your passwords (we use bcrypt) and keep all your social accounts as well. Because at the end of the day we're just another OAuth provider, you're not tied to us as a provider.
Great questions. I couldn't stop thinking about #3 while watching that video.
Edit --
Seems like he answered #1 in another commment:
Right. It turns out a lot of the work comes from gluing the various services together. For ex, when a user signs up with an email account, and then forgets and signs in with Facebook next time.
This takes care of deduping accounts, and flattening the social data, etc.
1. If I use this do I have to handle account linking? Ex: Monday user logs in with FB, Tuesday with Twitter. Do you pass a unique key saying this is a canonical "user"?
2. From the gem docs it looks like you're returning a hash of whatever the social provider returns and explicitly not trying to "normalize" the result (ex: One service might return "email" and another "email_address"). This seems fairly different to what happens with Devise and Janrain. Is this going to change with time or do you see this as key point of differentiation.
3. What happens if you guys win the lottery and all retire to a tropical island? How screwed am I with my users?