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.

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. 

I posted this to Github:  https://github.com/BitShares/qt_wallet/issues/69

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

Obviously the forums are great.  But they're less than ideal for communicating important messages:

- There are a lot of subforums that fragment everything
- People tend to stop re-reading the sticky titles on every visit, so new stickies are hard to notice
- There's often good back-and-forth Q&A and discussion between community members and developers, but insightful posts tend to get buried in pages of people giving their or general chatter

We've discussed various ways of improving our communication in the past.  I'm thinking we should have three different channels aimed at different groups:

- End-user announcements:  Announcements of policy changes and mandatory upgrades.  Tell end-users and delegates about changes that will directly affect them.
- Development announcements:  Discussion of planned features, changes to the long-term road map, and development activities.  Keep community members involved in development and I3 members working remotely informed.
- Marketing blog:  Discussion of current BitShares features, project philosophy, the rationale for changes, and How To explanations.  Explain all the goodness of BitShares to casual BitShares users who might not be aware of all our features, and crypto-enthusiasts considering getting involved in the BitShares ecosystem.

End-user announcements sort of exists as a sticky at https://bitsharestalk.org/index.php?topic=7067.0 however, when we implement changes to short mechanics, users also want to know the details of the new rules.  So something like e.g. https://bitsharestalk.org/index.php?topic=9521.msg125135 (note:  illustrative purposes only, the content of this post is out of date) should be included in the announcement.

The marketing blog already basically exists at http://bitshares.org/blog/

As for development announcements, Github tickets are useful for tracking individual implementation issues but aren't as useful at providing a big picture.  For example, the Github tickets show what kinds of bugs are being worked on related to BitShares Mail, but developers who aren't privy to I3 internal discussions are likely wondering about the overall design and vision of BitShares Mail.

This is just my personal opinion and doesn't reflect any I3 consensus.

Sorry, I didn't get the word.  My delegate has been producing blocks with v0.0.4 for a long time.

I've put most of the suggestions in this thread in various tickets, there is a list here:  https://github.com/BitShares/qt_wallet/issues/62

There is some public discussion of these suggestions in the individual tickets linked in that ticket.  Specific, actionable feedback is always appreciated.

The OP was originally an update to my proposal in https://bitsharestalk.org/index.php?topic=10597.0 but immediately after I posted it, I noticed the Github ticket was closed.  I didn't want to confuse anyone by posting a list of rules different from what we actually implemented, so I deleted my proposal from the OP and changed it to ask about the contents of the ticket.  Sorry if I confused anyone.

Given that delegate pay rate cannot be increased, does this mean that delegates that want to have more than 3% pay rate after Nov 5th will have to create new delegates (with new names)?

Excellent question.  I think I'll let @bytemaster answer this one.