search

stacks-archive / blockstack-browser

The Blockstack Browser
Mozilla Public License 2.0
1.12k stars 199 forks source link

Cannot create a new NON-blockstack ID when going through on-boarding #1715

Open moxiegirl opened 6 years ago

moxiegirl commented 6 years ago

Users can only create an id the blockstack namespace with the browser. We should support creating non-blockstack IDs primary ids. This is the case, where the user wants to create a primary id for the first ID, not add one after the fact.

yknl commented 6 years ago

Users can only create an id the blockstack namespace with the browser.

This is not true, you can create a .id username after onboarding.

The reason we make everyone create a .blockstack.id username during onboarding is so that they have a functional username right after onboarding. Most apps require a username to be fully functional, there isn't much value for the user to end the onboarding process without a username.

Registering a .id username is also a somewhat complicated process involving sending bitcoin to the browser wallet, and spending money (bitcoin) to get a username. It's definitely not an experience we want to subject new users to.

moxiegirl commented 6 years ago

@yknl Had a long conversation with @aulneau @hstove and @kantai. So, I understand the issue. Still, I think we should find a way to allow users to choose. The conversation was very interesting (I hope the guys agree). And I think we could find a way to solve this so that our onboarding allowed new users who are confused by our space and existing users who aren't (presumably the ones who aren't confused), to choose an id with or without the blockstack namespace.

And it even occurred to me that by forcing users into the blockstack namespace, we are creating a ton of ids that otherwise would not be created. I'm going to call this the "Slack" problem. So, that our namespace becomes cluttered (and if we are successful) really, really cluttered with names that serve no purpose other than onboarding. So, we hire a sally and she is unlikely to find sally.blockstack.id if she wants.

aulneau commented 6 years ago

find a way to allow users to choose

We do have a way for people to register names, but I don't think it makes sense to allow users to buy a name when the sign up immediately. Maybe we can allow them to opt out of registering a name, and then after onboarding they can go through the process of sending BTC and then buying a name. I think the vast majority of users would prefer to make a .blockstack.id username vs buying one (which they can do currently)

aulneau commented 6 years ago

really cluttered with names that serve no purpose other than onboarding

I think this is a false premise.

The IDs are useful in that they allow most apps to work. Apps like stealthy and graphite are not fully functional if the user does not have a name associated with their ID.

aulneau commented 6 years ago

@moxiegirl I changed the title of this issue to: Cannot create a new NON-blockstack ID when going through on-boarding as it is possible to create a new non-blockstack.id name in the browser, just not during onboarding.

moxiegirl commented 6 years ago

I think some of the ideas proposed by @yknl can fix a lot of the onboarding issues including this one.

@aulneau I didn't want to imply that the ids aren't functioning as stated. Extend the thinking a bit, I go to gmail to get a name. I want mary but it tells me that mary.gmail is the closests available. That's their onboarding, I setting for mary.gmail I get in only to find out I can get mary with some additional steps. I would abandon using the unwanted mary.gmail for my first choice mary. Also, likely, want to kill the bad one which gmail refused just because of the fact I was onboarding. Course, assuming gmail worked like our IDs, I couldn't do this.

Despite the fact gmail would have built this path the help newbs overcome onboarding confusion, the end result is a lot of names no one ever wanted in the first place lying around unused or largely ignored. This outcome is a distinct possibility from whether the names themselves continue to be usable.

hstove commented 6 years ago

Also, likely, want to kill the bad one which gmail refused just because of the fact I was onboarding.

This is overlooking the fact that there is no possible way for you to get through onboarding "instantly" without making a subdomain. It's not as simple as your "preferred" ID (mary.id) not being available, its that you'll have to pay for it and wait.

So when you ask the user the question, "Would you rather get mary.blockstack.id and be able to log in instantly and for free, or would you rather wait and pay with Bitcoin for mary.id?", I suspect the answer will 99% of the time be the first option.

Yes, you still have the case where 1% (or less) of users will eventually buy a paid username and prefer that. However, these are power users, and it's still extremely easy to log in with that second ID later on, because we ask the user to select which ID to use during blockstack auth if multiple IDs are owned.

moxiegirl commented 6 years ago

@hstove I'm not saying this (pick your ID) should be the default, I'm saying we should allow the option at the start. Right now, we've overcorrected and, if we are successful, the overcorrection leads to this other issue which can lead to problems and confusion.

Eventually, too, the long lead on transaction time could be reduced and/or we could discover solutions to this particular issue.To dismiss the resulting creation of many unnecessary identities as an issue seems short-sighted.