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.