Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

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

Open
moxiegirl opened this issue Oct 16, 2018 · 8 comments
Open

Comments

@moxiegirl
Copy link
Contributor

moxiegirl commented Oct 16, 2018

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.

@moxiegirl moxiegirl changed the title Cannot create a new blockstack ID through the Browser Cannot create a new NON-blockstack ID through the Browser Oct 16, 2018
@yknl
Copy link
Collaborator

yknl commented Oct 17, 2018

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
Copy link
Contributor Author

@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
Copy link
Contributor

aulneau commented Oct 17, 2018

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
Copy link
Contributor

aulneau commented Oct 17, 2018

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 aulneau changed the title Cannot create a new NON-blockstack ID through the Browser Cannot create a new NON-blockstack ID when going through on-boarding Oct 17, 2018
@aulneau
Copy link
Contributor

aulneau commented Oct 17, 2018

@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
Copy link
Contributor Author

moxiegirl commented Oct 17, 2018

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
Copy link
Collaborator

hstove commented Oct 17, 2018

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
Copy link
Contributor Author

moxiegirl commented Oct 18, 2018

@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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants