Meta March 26, 2020

Would you sign in to Indie Hackers with DID .app?

Richard @richardesigns

DID.app is an identity provider with a difference.

We make it easy to sign-in with a single click. However, we don't have a business model that requires us to track our users across all the sites they visit.

We don't run a search engine, social network or payments empire.

DID.app was started last year and we have bootstrapped ourselves to this point. We have received a huge amount of help and support from you, the indie hackers. It would mean a huge amount to us if we could give a little back. To give indie hackers a bit of convenience along with a bit of privacy.

An integration with DID.app to works with the OpenID standard. This standard is an extension of the OAuth 2.0 framework that enables the sign in with Google, Facebook and Twitter buttons that IH already supports.

Because we use the same standard it would be easy to add DID.app along side those other providers for anyone who chooses to use us.

It would look something like the image attached.

So - would you sign in to Indie Hackers with DID.app?

  1. 4

    I always log in with the native email and password option, so not for me I'm afraid.

    1. 1

      Hi Primer, just out of interest, do you use a password manager? Thanks for your comment.

  2. 2

    Sure, I would happily use it to log on. I wouldn't make an effort to switch though as I'm also very comfortable with my password manager flow.

    I offered passwordless auth to begin with on plausible.io and a good number of my customers complained about it. They wanted to keep using their password managers. I didn't want to manage two solutions o I completely switched to a normal password flow.

    One question about DID, do you share the user email with the website that uses you to authenticate? I'm always weary about using third party auth because I don't know what information the website is going to receive.

    1. 1

      Hi Uku, Thanks for this. DID uses the OpenID Connect standard and sends 'email' and 'sub' in the claim back to the relying party.

      DID can be whitelabelled into a site so to all intents the user is signing up to that website (i.e. Plausible) but DID is doing the hard work of authenticating.

      Love Plausible by the way. Everyone should definitely switch to Plausible.io ! :-)

  3. 2

    From the point of view of the web app maker, what's the motivation to use this over Google or Facebook or LinkedIn or GitHub, etc? Maybe I'm wrong, but I would think that for my web service I want to prevent troll accounts, and pushing people to use a public profile would help in part with that, even on the guise that it is reducing friction for them to signup.

    Also, I think that many consumers will be confused because DID is not part of a larger service that they already know and use, meaning that the education cost of training the potential user is high.

    On the flipside, for my own products, I'd like to white label this and use it so that I can port a person's profile from one app to another related one, and reduce redundant data entry for the client. For legal and health industries it makes a lot of sense. I've had this on my roadmap for a long time.

    1. 2

      Hi Blake,

      Thanks for these insights. Really glad you mentioned the white labelling. This has always been our intention. The user needs to know they are signing up to 'your' website (and they are), but DID just does the hard work of actual authentication. For the purposes of this post, we're looking for early traction so 'signing in with DID' made sense to me at the time of writing.

      The network effect as you point out is tremendously valuable. Now the user can hop between services and one-click sign in wherever DID is used (Even when whitelabelled).

      Related apps created in the DID.app dashboard do have that connection for users so sign in on one.example.com and you'll already be signed into two.example.com.

      The main benefits of DID.app for the developer over social auth is reduced development time and complexity. We really want DID to be the fastest, simplest way to add auth to a site. I think were there or pretty close.

      For a website that offers DID (either whitelabelled or not) should see some improvement in conversion rate for new and existing users. Username and password combined with several social auth options creates choice fatigue at sign up (which social account do I use?!).

      According to a study by Blue Research, 90% of users abandon sign in if they've forgotten their password.

      It would be great to discuss your own requirements in more detail if possible. To see if there is any way I can help with ideas and if there is a possible fit for DID.app.

      1. 1

        It would be great to discuss your own requirements in more detail if possible. To see if there is any way I can help with ideas and if there is a possible fit for DID.app.

        For sure [email protected]