Discuss: A whitelabel Blockstack auth

#1

Just curious what people think about this one, I’ve thought about it off and on since joining Blockstack.

My hypothesis: There’s a huge group of entrepreneurs and developers for which putting the Blockstack brand/browser/onboarding in front of their app at the beginning is a non-starter. Offering an ‘invisible’ version of Blockstack would open Blockstack up to more use cases and a bigger audience.

On a technical level, I have no idea how possible this is, but coming from Techstars and being a marketing person myself, I can tell you that entrepreneurs go to great lengths to keep the friction low and their brand experience tight, especially during any kind of first app interaction. I wonder how many good teams we lose because they simply can’t accept any Blockstack onboarding, regardless of how smooth it’s made.

Thinking outside crypto, it’s very rare/odd to expect someone to go out and sign up for another service they know nothing about, just in order to use your app. Facebook/Google auth is one thing, they have semi-ubiquity, they are providing convenience. Both are not true of Blockstack auth currently. I know if I were starting my own company, this would be tough for me to decide on, but if you gave me a white-label option, it becomes almost a no-brainer.

Agree? Disagree?

2 Likes
#2

@yukan did some great work around the concept of “burner IDs” last year - even wrote a proof-of-concept I think. The idea is you don’t have to leave the app to create an ID and use Gaia, and there is a flow to ‘convert’ your burner ID into a normal Blockstack ID that you can login to other apps with.

I think it’s a good idea.

1 Like
#3

I like that for sure. I still wonder if complete whitelabel/invisible is more powerful in the long run or if what you suggest solves the issue. There’s also going to be hesitation from those that don’t want to make it easier for their customers to breeze away to another app with their shiny new ID. Granted, they should just build the best app and not worry, but entrepreneurs weigh these things when deciding on what to build with.

The question for me is, do we want to be more like internet roads and infrastructure, or do we want to be a big trusted doorway?

It’s almost like being the App Store vs being something like AWS.

And side note: I hadn’t thought of it like this before, but isn’t making people go through a branded auth experience a very centralized style imposition anyway?

#4

I’ve also suspected that we may need to white-label or do something else to blend into apps chameleon-like. But even if we empower developers to either brand onboarding, etc. to minimize the hand-off shock – or delay Blockstack-ID creation via burners and the like – at some point users have to encounter and create something akin to a supra-app identity, right?

Whether we call it Blockstack ID or whatever else (“create your universal ID”), the user will encounter a conceptual context switch (“oh, I wanted to use Acme app but now I need to think of Ajax for my identity, data management, wallet, etc.”). And alternatively allowing developers to name that identity, etc. (“Register for your Acme Identity”) would defeat the point of establishing its cross-app purpose.

If the problem we face with developers is that they prefer to delay introducing Blockstack as a concept for users, then we may have viable option for punting the ball further down the field (e.g. burner IDs). If it’s that they want to minimize brand dissonance, then we have options as well (e.g. custom onboarding skinning). But I don’t see how we can avoid the core conceptual dualism challenge.

I’d go as far to say that viewing this challenge as a problem for users is perhaps the backwards way we should be looking at it. Perhaps this dualism is the key solution we’re trying to provide for users. While we may be unsatisfied with our current UX and sensitive to its frictions, etc. compared to traditional app-based identity UX, we should be asking ourselves how we make that UX so much better that new users love and appreciate it.

Ideally, new users across apps would arrive at the Blockstack onboarding flow and think “awesome, I’m going to start using Acme app and this Blockstack system guarantees me independence, management, transparency, etc. of everything I do with Acme. My experience with Acme is 500% better with Blockstack than without it.”

We have a lot of work to do to achieve that reaction and satisfaction, of course, but I suggest we lean into the problem and try to leverage this touch point with end users instead of try to fade into the walls where we can’t proactive affirm and deliver value to them. If we do lean in, entrepreneurs should love us for it and come to view us as not only saving them the headache of user management but actually enhancing it despite the context switch.

Finally, I agree with the concern that if we present ourselves as “just another (centralized) company you need to trust”, then all of this is a moot point. Somehow new app users need to grok palpably that we aren’t a middleman company but rather an internet protocol, community project, etc. This is another big design and communication challenge for us, but I think one we’re committed to solving.

2 Likes
#5

The way I would approach this problem is using the burner IDs proposal - IDs created in-app and transferrable to an authenticator of choice for complete user control. I would hesitate to call this white labeling though. We’re building a protocol and it should be transparent to the user what the underlying authentication protocol the app is using. Although it’s up to the app developer whether they want to show this to their users, I think if the value prop of Blockstack is good there’s no reason developers won’t want to. I think we risk getting stuck at a local maximum by continuing to iterate on the current onboarding UX.

2 Likes
#6

From a developer perspective, I try to work towards integrating ANY decentralized identity provider. I don’t see why users with an eos account or jolocom account should not be able to use my app. In that sense, I don’t really care how strong the branding of the authenticator is. I think there is some kind of group working on this UX issue. (To-do: add link)

I think the dualism/context switch between app and authenticator should be maintained and emphasized! This happens when authenticating with social logins or PayPal or so and is well accepted.

1 Like