Two years ago, two separate applications began their journey into the decentralized web. Stealthy and Graphite were early apps on Blockstack's decentralized application system. While Blockstack provided great developer tools, there was always something holding adoption back: 

Authentication. 

This is true of the entire decentralized web space. It's not just Blockstack, but it's also Ethereum apps, EOS, Steem, et al. The fact is, developers have hoped users would make the adjustment to seed phrases and key management quicker than they have. And that lack of adjustment has stifled growth. So, we set out to build a better solution. And that better solution is SimpleID.

How Things Worked

For those who have never built or used a decentralized application, it's important to understand what the authentication process looks like. We're going to focus on Blockstack because SimpleID's free offering includes Blockstack modules (but at launch we support Ethereum, Textile, IPFS, and Pinata as well). 

When creating an account on any application built on Blockstack, users are taken through what feels sort of like OAuth. The user bounces away from the app to another page, branded entirely in Blockstack colors and text. The user is then given the choice of "Creating new ID" or "Sign in with an existing ID."

When the user chooses "Create new ID" , they can choose a username, suffixed with .id.blockstack. The text below reads: 

"This will be your unique, public identity for any Blockstack app." 

Not a horrible experience, but a bit confusing. If a user finds a viral app that happens to have been built on Blockstack, they likely have no idea that the app is built on Blockstack. So, seeing that text and seeing the Blockstack branding can be significantly jarring. It also lowers user trust, as we've seen in user testing. 

Now, you might say it is the application developer's job to prepare users for this experience. And to a certain degree, we'd agree with you. However, the application developer owns the app and should be able to own the experience. Forcing an onboarding process that describes some other company (that to the user appears to be unrelated) is never going to be a good experience. 

But, I digress. Let's continue the onboarding process. 

When the user has selected an available username, they are prompted to enter a password. Cool, users know passwords. This is starting to feel more like the expected experience. 

But wait. After clicking "Register ID", the user is presented with an interesting screen. It's now asking for an email address?

Even though in the previous step, the text told the user that the password could not be reset, this step is saying that the email address would be needed for backup and recovery. As a user, you'd be forgiven for thinking this meant that you could recover your identity if you forgot your password. 

When the user enters an email, they are prompted to return to the app they were signing in with. (note: in the screenshot below, I'm not signing into an app, so it says "return to Blockstack"). But there's also a message about a "Secret Recovery Key" and some recovery instructions sent via email. If the user clicks "View Secret Recovery Key", they are taken to a screen like this: 

Oh man. This feels serious. The user may be thinking at this point "what if I hadn't clicked the button to see this thing?!" But let's take a look at this recovery key. 

I've edited the words in this example for effect, but the user is presented with 12 words that they need to record and save somewhere safe. For anyone familiar with cryptography, this is not surprising. For a user of today's web, this is possibly the deal-breaker moment. But let's assume the user is willing to go with the flow and they copy the words. Cool, now what?

Now Blockstack is going to verify that the user actually wrote these words down by making them re-enter the words. But, wait. What if the user chooses to go back? They're taken to the page that lets them click to view their Secret Recovery Key. But the user just did that, so the other option is clicking "Cancel" in the top-left. Let's say the user does that. Well, now the user is on a strange page completely unrelated to the app they originally tried to create an account through: 

If the user has not yet given up, they might check their email and see something from Blockstack, not from the app they were signing in with.

 
So, this is what the email address was used for. But this thing that was sent is not the 12 words. Why is that? A regular user of web applications does not understand this. The email refers to this code (it's a code, right?) as a "Magic Recovery Code." 

…Magic?

A Better Way

Listen, this whole analysis is not meant to be a takedown of Blockstack. The truth is, Blockstack provides, probably, the best onboarding and authentication experience of any of the decentralized web protocols. That said, it's not good enough to attract users from outside the decentralized web. 

That's where SimpleID comes in. 

SimpleID provides developers access to simple API calls and a JavaScript SDK that acts as a layer on top of decentralized protocols. SimpleID cannot access user keys or seed phrases. Yet, SimpleID provides developers the opportunity to give users the experience they know and trust. If you'd like to try the experience out for yourself, head on over to our Hello, World app. 

As you'll see, the experience is simple. Sign up with a username, email, and password. Log in with a username and password. 

The solution is so simple, that SimpleID has already seen a few early adopters convert, including the apps build by us, the creators of SimpleID. For example, Graphite has already made the switch and has drastically improved the user experience: 

For Blockstack developers, dropping SimpleID into their app gives them instant access to all of Blockstack's other developer tools. File storage, encryption, etc. 

For Ethereum developers, using SimpleID provides a custodial solution to deploying and fetching smart contracts on behalf of your users. 

For IPFS developers, SimpleID provides easy access to Textile's IPFS wrapper and support for storing content and pinning it via Pinata. 

Traditional Developers

As mentioned earlier in this post, SimpleID isn't just decentralized application developers. SimpleID is for any developers that don't want to manage usernames and passwords. It's for any developer that wants to give their users a secure and private authentication mechanism. 

For traditional developers, you'll receive a userSession object when a user logs in. This will allow you to display basic information and will also let you differentiate things like back-end access and storage calls. 

There are certainly other tools available to manage authentication. PassportJS, for example, is great, but it requires developers to trust third party social authentication or it requires developers to build out a secure database of usernames and passwords. 

SimpleID doesn't require any of that. In literally less than 10 minutes, developers can get started and have a working authentication system.
 
And it's free to start!

Get Started Now

If you're ready to get started, take a look at our website. You can also review the documentation here.
 
Please feel free to reach out with any questions, and we're excited about what you will build!