Imho the beauty of your BAT system (the way it is envisioned) is it's independency from the current model of monetizing the web, which is ads, gradually evolving towards direct transmission between publisher and consumer.
Ads in the way they work on the web are just a very inefficient system of transferring this value, and they don't serve the original function of marketing anymore. It turned into a big game of psychological warfare.
The system is so inefficient that it finances almost the complete operation of Alphabet/Google.
As a user I don't know how the system works in the background, and when I read the recent news about Brave attacking Google for GDPR violation it was the first time I read about RTB and the technical aspects in the media. People need to know, so they can decide if they want to feed such a system!
Funding Choices seems to be a part of Google's answer to the growing problem of ad-blockers, but it can also bee seen as Google's answer to competition like Brave/BAT.
I read somewhere that under the umbrella of Funding Choices Google is also experimenting with subscriptions like BAT, but without the token.
I don't know how successful Google is with this, but this might be a tough competition for Brave, they will fight tooth and nails, and they control the Android ecosystem.
BAT is attractive for power users as you ride on the wave of privacy-friendliness which Google can't, but I think the real challenge will be the average user that wants a standardized, seamless cross-platform solution that can be used as the main payment gateway for accessing content, which is increasingly via gated Apps.
With Google controlling so much of the market with Android and Chrome, I wonder how they will react to BAT if it ever becomes successful, as they could theoretically quickly scale any competitive project.
I think the biggest advantage of BAT would be if big players could acknowledge it as a de-facto standard for decentralized transfer of micro-payments and privacy friendly ad networks. For this to happen it would be necessary to be somewhat "Open-Source", i.e. not strictly tied to a singly company controlling much of the tokens. I am thinking in line of an open consortium with different players holding a significant part of the BAT tokens each.
On your last paragraph, we can't standardize the BAT ecosystem until it is proven, and as it consists of more than the ERC20 token -- specifically it includes endpoint software currently developing in Brave, plus an anonymous accounting service alongside the Ethereum blockchain -- it won't be proven via the existence of the token alone.
On a future blockchain with anonymity, high throughput, and low fees (a trilemma?), the BAT ecosystem could be fully decentralized. That blockchain does not exist yet.
So our roadmap divides and conquers (the Mercury, Gemini, and Apollo phases), and we will expand beyond one browser when the system is ready, some time next year in my best guess. In particular (as noted in my other comments here), we need a high-integrity and fraud-resistant open source SDK.
Note that the BAT has diffused since inception to over 69,100 holding Ethereum accounts (https://etherscan.io/token/tokenholderchart/0x0d8775f6484306... -- you can see our User Growth Pool and Bittrex's liquidity pool as the top two accounts). The remaining roadmap work items are about token mechanics not token ownership.
> The system is so inefficient that it finances almost the complete operation of Alphabet/Google.
Since Youtube is wildly unprofitable, Alphabet/Google has to be funneling in money generated from other sources. Thus, Youtube is funded by ads, just mostly not from the ads on Youtube.
It was mentioned in a private email that the only reason YouTube exists is that Google's servers happens to have a lot of free disk space in the days before SSDs.
Imho the beauty of your BAT system (the way it is envisioned) is it's independency from the current model of monetizing the web, which is ads, gradually evolving towards direct transmission between publisher and consumer.
Ads in the way they work on the web are just a very inefficient system of transferring this value, and they don't serve the original function of marketing anymore. It turned into a big game of psychological warfare.
The system is so inefficient that it finances almost the complete operation of Alphabet/Google.
As a user I don't know how the system works in the background, and when I read the recent news about Brave attacking Google for GDPR violation it was the first time I read about RTB and the technical aspects in the media. People need to know, so they can decide if they want to feed such a system!
Funding Choices seems to be a part of Google's answer to the growing problem of ad-blockers, but it can also bee seen as Google's answer to competition like Brave/BAT.
I read somewhere that under the umbrella of Funding Choices Google is also experimenting with subscriptions like BAT, but without the token.
I don't know how successful Google is with this, but this might be a tough competition for Brave, they will fight tooth and nails, and they control the Android ecosystem.
BAT is attractive for power users as you ride on the wave of privacy-friendliness which Google can't, but I think the real challenge will be the average user that wants a standardized, seamless cross-platform solution that can be used as the main payment gateway for accessing content, which is increasingly via gated Apps.
With Google controlling so much of the market with Android and Chrome, I wonder how they will react to BAT if it ever becomes successful, as they could theoretically quickly scale any competitive project.
I think the biggest advantage of BAT would be if big players could acknowledge it as a de-facto standard for decentralized transfer of micro-payments and privacy friendly ad networks. For this to happen it would be necessary to be somewhat "Open-Source", i.e. not strictly tied to a singly company controlling much of the tokens. I am thinking in line of an open consortium with different players holding a significant part of the BAT tokens each.