Try out the new, streamlined authenticator with Blockstack Connect (beta)

#21

Thanks! Did you run it through TMUI in Brazil?? :smile:

I suspect that most current Blockstack Browser users are not making it all the way to the identity management part of the UX anyway, given it’s so hard to find (particularly if you onboard directly into an app vs. discover Blockstack independently).

As such, while the feature does exist, I don’t suspect that omitting it from this release will cause a significant number of people to stop setting up profile images and names.

I think the best route forward with identity management (which I do think is important for cross-app usage with a single username) would be to find better ways to introduce profile editing to new users post-onboarding.

For example, we could provide a standard modal component via Blockstack Connect that apps trigger to set a profile photo in-app. It could have cropping, rotating, even filters! And make the whole experience a lot nicer than linking the user off-site to deal with a strange UI and then wander back to the app.

I would like to see the connect library licensed under CAL, not MIT

Interesting idea. Mind elaborating a bit on how you see CAL helping here?

Otherwise the claims in the modal dialog are false or at least misleading about what the apps are doing

We’ve brainstormed some ideas on how to enforce encryption via the platform even more tightly, so users don’t even have to trust developers to encrypt their data reliably. It gets a bit tricky, of course, since the user may want some data public and other data shared with just certain people. So the UX would be very important.

I just hope that the data won’t drive us away from Blockstack’s vision of a user-owned internet. I would like to see collections and a data explorer sooner than later!

It’s certainly our intent to seek out the best data to test our core theses, including data ownership and collections. If anyone has data of their own to share (e.g. from talking with customers, conducting surveys), we’d love to hear of it, too.

can I present my app as ꓐanter (with a different B) via the optional app details

I’m not sure how much we as a platform can or should do to prevent such impersonation if the user is already visiting from a falsified domain. If they’re visiting from such a domain, couldn’t the hacker simply fake Blockstack UI without even sending the user to the real authenticator?

app.blockstack.org as a landing page should be improved

Yep we plan to build this page out over time as we include features that drive users there.

#22

Thank you so much for putting the time into this feedback! :pray:

I think we’ve already made some progress fixing the bugs you mentioned here (e.g. that mention of “Instagram” :grimacing:).

We may expand that “How it Works” modal to include more materials and perhaps even link off to a dedicated page. So that feedback in particular will be helpful for evolving it.

I did have a random idea related to the “Powered by Blockstack” button. Would there be any way to make this a “security image” like the extra layers some banks do to ensure the website is the correct website?

I suppose I wonder why a phisher wouldn’t just send the user to a dummy version of this flow instead of the real one, thereby bypassing the authenticator and its security check entirely? This is similar to my comment to @friedger elsewhere in this post.

It went directly to the 12 word phrase, and I closed it out shortly after and didn’t save it. What happens now? Can I recover that? I see it on the list as a raw ID.

We need to handle this case especially. I’ve filed these issues: https://github.com/blockstack/app/issues/214 and https://github.com/blockstack/app/issues/215

Second choice: OverlyVerbose

Yep usernames need to be lowercase

It needs overflow-wrap!

Good catch, tracking here: https://github.com/blockstack/app/issues/217

Bugs aside, I cannot express how happy this makes me. The original process with browser.blockstack.org I could understand, but couldn’t recommend to “friends and family” without hand-holding and trying to convince them to use it. This is clean, simple, and straight-forward (as it should be!).

This is exactly what we want to hear! I’m glad you like this version so much and feel it’s ready for “friends and family”.

#23

@hank is this error because Banter needs a username and so runs into problems if the user doesn’t complete setting one up?

#24

Would it be possible to exclude the screen for the username? So the developer can decide.

Apps that don’t need usernames could benefit from it. Apps that require a username could have the screen showing when users without a username login the first time.

#25

We considered this in depth during our research into identity management for this release, and we were very much tempted to make usernames optional per app.

However, we couldn’t figure out how users would recognize their accounts when trying to choose between multiple accounts upon later authenticating that same app (since their accounts wouldn’t have human readable names but rather something like an identity address e.g. m2o30ghwsgggm293ghuhwsewheuhg42). So it forced a trade-off between confusing or inconsistent multi-account support for apps or usernames required for all apps.

#26

I see, what about a nickname to identify identity addresses (that stay private and are not published)

#27

The permission dialog disappeared. In the context of Marvin’s article about XSS there might need to be some kind of information for the user what to expect from the app.

#28

If we ask them to set a private nickname though, the work will be the same as asking for a username, won’t it? Or do you mean we should automatically generate nicknames for these apps?

#29

Yep we discussed that article yesterday as a team and are thinking through just what language and information we ought to use in this UI (and elsewhere) to indicate most effectively the extent and ways in which the platform and apps can – and can’t – protect users given vulnerabilities such as cross-site scripting.

We’d love to hear the community’s thoughts on this as well, in particular just how we all feel the responsibility should be shared between Blockstack PBC and developers in improving and delivering this communication.

We’ve also removed the permission dialog from this release having been obviated by other changes.

The scope store_write is universal and implicit to virtually every app; email is no longer collected during onboarding, so the email scope is now irrelevant; and we now warn users before re-using usernames across apps that their apps usage will be public information, which greatly clarifies the publish_data language we had before (and which no one understood).

#30

I also believe that usernames should be kept in. Identity addresses are confusing and sometimes even intimidating to users. It makes the experience feel more “complicated”. Even my (app development) students were confused about the old on-boarding process and seeing their identity addresses.

@markmhendrickson that warning looks great.

1 Like
#31

Join the dedication session for this beta release on the 27th with @markmhendrickson register here https://www.crowdcast.io/e/blockstack-connect/register

#32

That could be a good option (together with jdenticon for profile pictures)

Adding nicknames help to create identities that are not hooked into the blockchain for apps that do not need this feature.

1 Like
#33

The word “key” is not very well known outside the crypto space. The term should be something like “Secret Encryption Phrase” or just “Secret Phrase” (a kind of multi-word password). Using “key” is also possibly confusing for users as it can be confused with real public/private keys which are usually not multi-word phrases.

#34

Debatable. The term “key” is a super generic and I feel like anybody could understand that versus “encryption phrase” which is more high falutin tho “Secret Phrase” could also be an option. Don’t forget there’s a session tomorrow before this discussion points.

#35

You don’t need to use the word encryption. “Secret Phrase” is enough. Again “key” is meaningless to most people outside crypto. And if DID (names) are the direction we are going even private/public key strings for bitcoin/etc. will be a thing of the past - as they should be.
And to make things even clearer I think the following definition adds clarity…
Key = single long alphanumeric string
Phrase = a set of multiple short English words

#36

in today’s cast --> https://www.crowdcast.io/e/blockstack-connect
I said ~

I’m open of course to what others think but the more I think about it the more I don’t like “Secret Key” because it’s never a good idea to call two different things with the same name (key). Users will be using real BTC and STX keys when dealing with wallets and Clarity apps and it can be (will be?) confusing. Imagine users reading the docs explaining things like “enter your key here” or “be sure to save your secret key in a safe place”.

I understand that “key” provides a good mental model and it’s an easy term to remember. But the fact that new users are liable to confuse the two things - “secret key” with real crypto alphanumeric key strings - is enough to avoid this. Users could end up losing control of their identities and money - serious losses.

#37

I am cautiously bringing my feedback from the user point of view as I am a non-technical Blockstack evangelist. Moreover in the past months I have addressed end-users to introduce them to some Blockstack DApps and I recently did I a webinar about Identity and the Blockstack Id. With such background I was really surprised in the meeting yesterday. Then I went to the explanation here and read all the comments and answers… Now, my surprise is not without concern because I feel there is something essential which becomes invisible in the new onboarding process: the awareness of getting an Id which can provide much more than just access to the DApp.

I understand that the onboarding process should be made as easy as possible for a better UX, thus reducing the info collected, not asking for email and password as well as just remembering the secret key and provide a username seem great improvements to me.

Nevertheless, for the features omitted from initial release “having deemed non-essential for new users”, I have to disagree at least about identity management (I also liked the BTC wallet). As Friedger also expressed his concerns…

For the new user (who might not even know about the advantages of blockchain, not to say of Blockstack) it won’t be easy to understand WHY it’s worth keeping his secret key, why this process makes sense because it opens to a world of new DApps that can’t be evil. This new authentication shouldn’t get rid of the idea that the secret key the user is provided is somehow an “Identity” with which you can enter lots of new DApps and start your journey into the web 3. This is an information that should be made clear somewhere, somehow, in the Blockstack authentication. Omitting this is not a good idea.

Privacy is for sure a powerful argument to use DApps as it is one of the fundamental individual rights that have been most abused. Nevertheless it is not the only one, also property and freedom of opinion have also to be considered. Like in the physical world, on the Internet, especially on the blockchain, their existence depends on having a digital identity. This is the reason it is important to preserve this awareness of identity when on boarding. After all Identity is the missing piece that Blockstack is providing the users to get back in control of their online presence.

I hope there is a way in the authentication to make users conscious of what all they can do with that “secret key”, so they get it’s not just a way to rush into a DApp…

Btw, like Brad, I also find confusing the expression. “secret key” , how about “secret identifier”? Just thinking…

Best to you all!

2 Likes
#39

Thanks for your thoughts on this matter, @Georgina!

It would seem to me that this screen in particular (for choosing a username) is where we may be missing most the opportunity to educate new users about the power of their new identity?

One idea that comes to mind is perhaps a little FAQ area below the “Continue” button that’s similar to the one we have earlier for the Secret Key step. The FAQ could explain just what makes Blockstack usernames unique (e.g. “Where can I use my username?” -> with any Blockstack apps, "Who can disable my username? -> no one, etc).

What do you think? Are there any particular facts we ought to clarify here?

I’d note that our current onboarding design doesn’t do much at this step either, but it does mention briefly that the ID is unique and public for any Blockstack app:

#40

Thank you, Mark.
Your suggestion is very good. The uniqueness and utility of that username must be explained somewhere. I don’t know if a Q&A is the best through. I like the sentence “This will be your unique, public identity for any Blockstack App”.
Moreover, I first thought that at the bottom left in the first step the sentence “I already have a secret key” is not clear… maybe this would be another possible place to provide information on the possibilities of the secret key.

I keep having all this in the back of my mind… If I think of other possibilities I’ll share them here.

I can’t help but commenting that as Identity is getting more interest in the blockchain world, I think Blockstack can’t miss the opportunity to shine and take the lead in educating in this matter, and that the new authenticator can benefit from the general interest in Identity. Otherwise, I feel it could become a missed opportunity, and this would be a pity considering the very good job in making it much easier for end users to get on board.

1 Like
#41

I like it. The use of context pertinent help text is always a good idea as long as you keep is simple and don’t throw extra jargon in or other complexity that might cause more harm/confusion than good.
I wonder if referring to something familiar to everyone (email addresses) would help? Eg…

"This will be your unique identity, similar to an email address, but used when logging into all applications."

1 Like