If we allow third-party applications inside BitShares client/wallet, a lot of things that require centralized services would be much easier to implement and make user friendly . Some examples:
- whoever runs a gateway (RealBTC<->IOUBTC) could publish an application, so users interested in this gateway could install an application be able to convert BTC to IOUs not leaving the client.
- faucet can run referral program, so users could use its application to redeem referral program's coupons or generate new coupons to share with friends right inside the BitShares client.
- escrow agent can have its own application specific to the service it provides.
- and many others more simple use cases, like advanced block explorers, market charts, and a lot more.

Another advantage - this allows us make the client as light as possible, by default it would contain only basic wallet functionality needed to register account and transfer funds, everything needed for more advanced users can be installed as applications, for example market GUI can be an extra app.

Later when ethereum-like scripting language is implemented, the same applications infrastructure could be used to interact with blockchain DAPPs.

And some technical details how this can be implemented.
A trusted party is needed to make this possible, first of all there should be some repository of applications, second, applications would have access to private keys, so there is a big security issue. I suggest delegates to be this party responsible for apps: delegates publish their list of trusted applications, the same way delegates now publish price feeds and toolkit version. List of applications can be publish json format, each application entry can contain download URL, API URL (if app is supposed to communicate with centralized service), checksum and the version number (if version changed the client will automatically update the application).
Technically, an application is Angular.js module - just a package comprised of html and js files. BitShares client downloads it, verifies checksum and signatures and plugs it in as Angular module.
There might be different rules for different kinds of application, e.g. if application doesn't require access to wallet_* rpc calls, it may require only one delegate to publish it, applications that require access to wallet_ calls may be required 10 or more delegates to publish feeds. To revoke an application, delegates just need to stop publishing it - BitShares client will mark it as revoked in the applications repository. DPOS shines again giving BitShares a huge advantage over competing platforms.

https://github.com/BitShares/bitshares/releases

Worth reading http://blog.referralcandy.com/2014/01/23/paypal-referrals/ - here is how 7 to 10% daily growth in 2000 (PayPal acquired 1 million users by March 2000 and 5 million by summer 2000)

A small quote:

PayPal’s big challenge was to get new customers. They tried advertising. It was too expensive. They tried BD deals with big banks. Bureaucratic hilarity ensued. Over ice cream, the PayPal team reached an important conclusion: BD didn’t work. They needed organic, viral growth. They needed to give people money.
So that’s what they did. New customers got $10 for signing up, and existing ones got $10 for referrals. Growth went exponential, and PayPal wound up paying $20 for each new customer. It felt like things were working and not working at the same time; 7 to 10% daily growth and 100 million users was good.

I've edited OP and refined description a little bit and added more implementation details.

Quote from: valzav on November 12, 2014, 05:07:21 pm

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. 

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

High-level description:
We can have marketing delegates that run faucet and finance referral program out of their payroll. The referral program pays some amount of BitAsset to identified unique users that download BitShares client and create account. For instance delegate can spend 80% of the payroll to fund referral program and pay 10 BitUSD per user/account created.
There would be also an initiative for users to invite their friends, e.g. each user referred a friend can get additional 10 BitUSD if friend installs client software and registers account.

The faucet would work as described below:
1. Somebody visits faucet website
2. There would be a clear call to action (CTA) “Download BitShares client, register account and get 10 BitUSD”.
3. Visitor clicks CTA link a goes over proof of person/identity verification process.
4a. After finishing step 3 visitor is suggested to download the client and install it.
4b. Also visitor gets a ’10 BitUSD coupon’ to his email address.
5. User installs BitShares client and clicks on a coupon link or just copies coupon code as text.
6. BitShares client/wallet opens coupon redemption page suggesting user to choose his/her account name and enter coupon code (if coupon linked clicked the coupon would be inserted automatically).
7. After user submits account name, BitShares client communicates with faucet website checking the coupon's validity, if coupon valid the faucet registers user’s account and credits it with 10 BitUSD.
8. Faucet generates new coupon, passes it back to client and client suggests user to share it with friends on Facebook, Twitter, forums, etc, if friend registers account, user gets 10 BitUSD and also friend going over identification process (steps #1-#7) gets his 10 BitUSD.

Advantages of this kind of referral program are:
- It's simple in terms of UX - user just goes over proof of person process, downloads and installs BitShares client, redeems coupon and chooses an account name, account name gets registered immediately.
- It's easy to implement - this doesn't require any toolkit changes or hard forks.
- It's self-sustaining - delegates compete to run the faucet - so stake holders voting for delegates, vote for some parameters of the campaign, such as niche served, marketing message, price per acquisition, so if stake holders think the dilution caused by the campaign not worse the value that new users bring it, stake holders vote out the delegate.
- This kind of campaign creates scarcity - spending 80% allows each delegate to register no more than 200 users each month within the current market cap, if there would be more users willing to register an account, the faucet can put them on a waiting list. Having a waiting list makes BitShares looks like something scarce which is good factor for successful marketing campaign, also this process resembles “invitations only” campaigns that were proven to be very successful (think gmail).

Implementation.
1. We need open source faucet/proof of person software that anybody can download and run as a website.
2. This software should be able to generate coupons and have json api, so BitShares client/wallet would be able to communicate with faucet.
3. Faucet software should be able issue and redeem coupons.
4. BitShares client/wallet should be able to communicate (via JSONP AJAX) with faucet to check and redeem coupons and making faucet to register user’s account.
5. Delegates running this service have to make all the records public so the community can audit referral links, coupons generated, etc and vote out non-effective delegates.

In order to BitShares client to find which faucet it needs to talk to redeem a coupon, delegates running faucets needs to publish faucet endpoint urls.
In general delegates can run not only faucet software, but provide some other services, so they can publish a list of services, e.g.:

"services": [
        {
            "name": "faucet",
            "version": "1.0",
            "coupon-prefix": "A123", // this is need for client to figure out what faucet to user to redeem coupon
            "url": "http://delegate-faucet.com/api/faucet/1.0"
        },
        {
            "name": "exchange",
            "version": "1.0",
            "url": "http://delegate-faucet.com/api/exchange/1.0",
            "app": {
                "url": "http://github.com/somedelegate/exchangeapp",
                "version": "0.1.2",
                "checksum": "1232142343243242"
            }
        },
        {
            "name": "escrow",
            "version": "1.0",
            "url": "http://delegate-faucet.com/api/escrow/1.0"
        }
    ]
Some of the services can be supported by the client out of the box like faucet or escrow service, some of them may require installation of angular module - delegates publish github link and client downloads and installs it, when delegates update app's version, client will automatically update it. If delegates removes this application from a list of provided services, client can uninstall the application. When delegate is voted out, the application would be no longer available.

Probably it’s too early to run full scale campaigns before we have stable network, simple lightweight client and on/off ramp services, but we before we get there we try this on a smaller scale, let’s have a single delegate running this and watch the results, if this would work, I'm sure stake holders would vote in more delegates running referral programs like this for different niches. Also voting in/out delegates may help us to figure out how much we want to pay for user acquisition and how much delegates can collect as compensation.

UPDATE 2
To prevent delegates from cheating and to have a single delegate efficiency metric (KPI) I suggest to remember first used faucet name or id somewhere in on the client/wallet side and make it to pass it to some centralized location each time the client is started, we can have a http callback address on bitshares.org for this, all the data gathered should be made pulicly available so everybody can see how many users opened the client multiple times and what faucets or referral programs have aquired those users.
Probably instead of a centralized location, we can find a way for clients to pass this data to all delegates on chain or off chain.

UPDATE 3
Some more features can be implemented on top of this, e.g. sending BitUSD to any email address directly from the wallet. Faucet operator just needs to have BitShares account so all the transfers to this account that include email address in the memo field would be forwarded to specified email address. There is no need for sender to create faucet account. Receiver needs to login to faucet via OAuth and verify email address.

UPDATE 4
This approach doesn't require a delegate position. It only requires a faucet with some funds that would be used to pay up referrals, it can be as low as 0.5BTS per user - just amount needed to register an account. Having a delegate running this kind of campaign just makes things simple.

roselee,
this is just rebranding - BitShares X was renamed to BitShares, all your balances and transactions won't be affected