Friday, August 7, 2015 at 6:42 AM

Why use Twitter for identity?

This is a frequently asked question, why use Twitter for identity in nodeStorage?

The TL;DR answer: It's easy for users, easier for me as a developer, and it might lead to collaboration with Twitter, which is something I'd like to see.

Now the more detailed answers.

  1. We have to use something for identity. The choices were: cook up our own identity system, or use Twitter, Google, Facebook, LinkedIn, Amazon, GitHub, or...?

  2. Cooking our own wasn't an option, at least not at this stage. An identity system is a complicated piece of software. Reliability is a huge factor. Building an identity system to scale is not a small undertaking. By using Twitter, I was able to focus on the other parts of nodeStorage and treat identity as a solved problem.

  3. I know there is OpenID and IndieAuth. There are probably other ideas out there that I'm less familiar with. These approaches make it more complex for the user, they introduce hurdles. None of this matters if there is no user adoption, and even with a really easy identity system it's hard to get people to try it. I didn't want to make identity a research project, I needed something that "just worked" for users.

  4. I already had code that implemented a Twitter-based identity system, and years of experience working with the Twitter API. Of the proprietary solutions it made the most sense, because I would have to start from scratch with any of the others.

  5. The most important reason to use a proprietary identity system is user comfort. As a user myself I'm more likely to use my Twitter identity with another net app, than create another login that I have to manage. OAuth, which Twitter's identity is based on, is more complicated for me to implement as a developer, but I appreciate it as a user. I can easily turn off apps that I'm not using without having to change a password.

  6. What if Twitter goes down? Seems not likely these days. Twitter seems very stable and performs really well. A more likely scenario is that Twitter might decide they don't want us using their system this way. Of course that's a concern, it could happen. If it does, we'll have to decide what to do then. If there's enough momentum behind nodeStorage, perhaps we can adapt to use a different identity system? Or come up with a driver structure that allows individual sysops to decide what identity they want to use? But if we haven't attained momentum, it seems unlikely that Twitter would care.

  7. We're not sharing much data with Twitter. They know how much time each user spends with a nodeStorage-based app, but beyond that, they aren't getting any information. The user's data is stored elsewhere. (On the other hand I think it would be incredible if Twitter or one of the other system vendors would allow app developers to store per-user data on their servers. It would quickly establish them as the leading Internet application developers platform.)

  8. Of all the potential identity providers, Twitter has the greatest reason to collaborate with independent developers. It would be hard to get Facebook's attention for a project like this. Embracing nodeStorage would be a huge win for both Twitter and open Internet developers. Because it defines an API for identity, it could be the basis for a new kind of net app, without lock-in. You could always add a new implementation behind the API if it became disadvantageous or impossible to use Twitter. Which would give Twitter an incentive to be fair to developers.


Last built: Sun, Aug 23, 2015 at 1:05 PM

By Dave Winer, Friday, August 7, 2015 at 6:42 AM. Still diggin!