Author Topic: UI / UX idea for account registration  (Read 2266 times)

0 Members and 1 Guest are viewing this topic.

Offline valzav

  • Sr. Member
  • ****
  • Posts: 294
    • View Profile
Let's extend drltc's proposal just adding a couple of steps on top of it:
1. User goes over identity verification process, at the end she receives an email with a link (or just link on a webpage) like this:
bts://account/create?provider=btsregprovider.com&id=123456789ABCD (let's call it referral link)
2. User downloads the client and clicks on the link above
3. Client opens up and shows dialog where a user can enter an account name and clicks Register button (provider is selected automatically)
Further it's the same process as in drltc's proposal.

+5% but here is some clarification:

valzav's proposal actually kind of turns my proposal inside out -- instead of running the client and then being linked to a provider website, you start at the provider website and then get linked to the client.

- The user installs the client.  One step in the installation process is registering the client with the web browser as a handler for bts:// URL's.

- The user goes to the provider in their browser, does CAPTCHA or whatever anti-sybil measures the provider decides are appropriate.

- When the provider is satisfied the user should be allowed to register, they issue a unique code and provider-controlled callback URL.

- Specifically, the user clicks on a bts:// URL containing the unique code and callback URL.

- The web browser will launch the client with the URL as a command line parameter.

- The client then issues an HTTP(S) request to the callback URL with the unique code, desired account name and public key.  (This is fairly safe from a security standpoint as the HTTP request is a RESTful API call, not a webpage that's going to be displayed which opens the door to much mischief.)

- The provider can use the unique code to link the callback to the previous successful registration.

- Provided the unique code is legitimate, the provider registers the account on the blockchain.

As a side note:

- We need to have the client registered as a bts:// URL handler on all supported platforms

- If the client is already running, we need to pass the bts:// URL to the client and exit on all supported platforms

- We should have some way for the user to enter a bts:// link manually if the bts:// URL handler doesn't work on their platform (e.g. it seems unlikely the bts:// link functionality will be flawless out of the box for people building from source on tons of different Linux distros)

- We should have a simple working demo which providers can extend with pretty CSS, branding, and their own verification system.

Overall I approve.  +5%

drltc, you proposal can also be supported - we just need to list existing verification providers on the account registration page, so a user enters account name and if there is not enough funds to pay registration fee she is being suggested to select provider and go over verification process (actually this is similar to the initial plan - we even used to have a reserved field for provider name on new account page). The list of trusted providers can be published by delegates the same way they publish price feeds or toolkit versions.

Also this allows us to implement referral programs like this https://bitsharestalk.org/index.php?topic=11356
« Last Edit: November 13, 2014, 09:55:08 pm by valzav »

Offline theoretical

Let's extend drltc's proposal just adding a couple of steps on top of it:
1. User goes over identity verification process, at the end she receives an email with a link (or just link on a webpage) like this:
bts://account/create?provider=btsregprovider.com&id=123456789ABCD (let's call it referral link)
2. User downloads the client and clicks on the link above
3. Client opens up and shows dialog where a user can enter an account name and clicks Register button (provider is selected automatically)
Further it's the same process as in drltc's proposal.

+5% but here is some clarification:

valzav's proposal actually kind of turns my proposal inside out -- instead of running the client and then being linked to a provider website, you start at the provider website and then get linked to the client.

- The user installs the client.  One step in the installation process is registering the client with the web browser as a handler for bts:// URL's.

- The user goes to the provider in their browser, does CAPTCHA or whatever anti-sybil measures the provider decides are appropriate.

- When the provider is satisfied the user should be allowed to register, they issue a unique code and provider-controlled callback URL.

- Specifically, the user clicks on a bts:// URL containing the unique code and callback URL.

- The web browser will launch the client with the URL as a command line parameter.

- The client then issues an HTTP(S) request to the callback URL with the unique code, desired account name and public key.  (This is fairly safe from a security standpoint as the HTTP request is a RESTful API call, not a webpage that's going to be displayed which opens the door to much mischief.)

- The provider can use the unique code to link the callback to the previous successful registration.

- Provided the unique code is legitimate, the provider registers the account on the blockchain.

As a side note:

- We need to have the client registered as a bts:// URL handler on all supported platforms

- If the client is already running, we need to pass the bts:// URL to the client and exit on all supported platforms

- We should have some way for the user to enter a bts:// link manually if the bts:// URL handler doesn't work on their platform (e.g. it seems unlikely the bts:// link functionality will be flawless out of the box for people building from source on tons of different Linux distros)

- We should have a simple working demo which providers can extend with pretty CSS, branding, and their own verification system.

Overall I approve.  +5%
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline valzav

  • Sr. Member
  • ****
  • Posts: 294
    • View Profile
cass,
I think it would be easier if faucets/identity verifiers would run referral and marketing campaigns. Actually the reason I'm calling the link with coupon code 'referral link' is because the end user receives it as a result of some referral program.
The only metric whoever runs the campaign can get is account name registration and coupon redemption, I think this should be enough to run successful referral program.

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
Also it would be great to let a user to go over the validation process first, then download the client and be able to register account right away. Any ideas how this could be implemented?

Answering my own question..
Let's extend drltc's proposal just adding a couple of steps on top of it:
1. User goes over identity verification process, at the end she receives an email with a link (or just link on a webpage) like this:
bts://account/create?provider=btsregprovider.com&id=123456789ABCD (let's call it referral link)
2. User downloads the client and clicks on the link above
3. Client opens up and shows dialog where a user can enter an account name and clicks Register button (provider is selected automatically)
Further it's the same process as in drltc's proposal.

if we call it *referral link* why not give users incentives who bring new valuable users aboard.
For example user have to use active his wallet for at leat 3 month, or another shield against spamming etc.! Just thinking loud. Honestly idk if this could be practicable …
But if we could get viral marketing effect for our network ...
« Last Edit: November 12, 2014, 06:20:31 pm by cass »
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline valzav

  • Sr. Member
  • ****
  • Posts: 294
    • View Profile
Also it would be great to let a user to go over the validation process first, then download the client and be able to register account right away. Any ideas how this could be implemented?

Answering my own question..
Let's extend drltc's proposal just adding a couple of steps on top of it:
1. User goes over identity verification process, at the end she receives an email with a link (or just link on a webpage) like this:
bts://account/create?provider=btsregprovider.com&id=123456789ABCD (let's call it referral link)
2. User downloads the client and clicks on the link above
3. Client opens up and shows dialog where a user can enter an account name and clicks Register button (provider is selected automatically)
Further it's the same process as in drltc's proposal.

Offline valzav

  • Sr. Member
  • ****
  • Posts: 294
    • View Profile
Also it would be great to let a user to go over the validation process first, then download the client and be able to register account right away. Any ideas how this could be implemented?

Offline valzav

  • Sr. Member
  • ****
  • Posts: 294
    • View Profile
I like the idea, we can even ship the client with the pre populated list of known providers.

Offline theoretical


My proposal differs greatly from your proposal in that your proposal requires hardforking changes, but my proposal can be used with the client that exists today.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline alphaBar

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
This doesn't differ much from my proposal here:https://bitsharestalk.org/index.php?topic=11096

There are no security implications if you do it the way I proposed, by creating a new free-floating account registration type that expires if not claimed by the client within X blocks. This also enables social-invites and other referral type onboarding mechanisms.

Offline theoretical


Much discussion has been devoted to the user account registration experience [1].

I propose the following:  On the account page for an unregistered account, there should be a space for the user to enter a registration provider's domain, and click "Register with this provider".

If btsregprovider.example.com is the domain name the user enters, then the "Register with this provider" button should open the OS's web browser to a webpage like:

https://btsregprovider.example.com/bts-register-acct?name=bob&pubkey=XTS7YjtxhJJaWHKo8hrJMwjtHkAFhLyxibgzpjDSwa2jpJb1y1WTb

where the name "bob" and the pubkey are filled in by the client.  Then the btsregprovider.com can do any user validation they desire.  When btsregprovider.example.com has decided the user is legitimate, the provider simply registers the account on the blockchain [2] and directs the user to return to the wallet.

Since the GUI wallet is browser based, we don't even need the OS browser -- we could simply load the https://btsregprovider.example.com/bts-register-acct URL in the wallet GUI.  But this would provide a number of potential attack vectors to a malicious registration provider; the security implications would need to be carefully considered.

[1] https://bitsharestalk.org/index.php?topic=11087.0

[2] The provider can register an account for the user without knowing the user's private key by adding the user as a contact account:

wallet_add_contact_account bob "XTS7YjtxhJJaWHKo8hrJMwjtHkAFhLyxibgzpjDSwa2jpJb1y1WTb"
wallet_account_register bob btsregprovider
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk