AMA with Marshall Rose

I apologize for the length of this answer; I'm using it to provide context for some other questions.

StrosPartisan pointed to the pre-launch roadmap which, while out of date, still has the true phase structure and many of the goals and anti-goals. I'm trying to get that updated, but I'm not in the author/editor path.

First, there isn't a single deliverable for each of these phases. There's an initial release for what we view as the phase's MVP, and then a series of incremental updates of both functional additions, feature improvements, and fixes. So, as with the US Space Program namesakes, there are multiple missions in each phase, starting from the MVP, and phases overlap.

So, here's how I look at things:

1. BAT Mercury is the initial architecture for the BAT ecosystem.

Many decades ago(!!), when I was in school, I learned an important rule: "You can solve any problem if you are willing to make it small enough." With that in mind, here is how I view BAT Mercury:

• Function:

  After you opt-in, the browser "measures your attention" on the sites you go to. Initially, "sites" were websites and YouTube channels, since the BAT Mercury launch, and we've recently added Twitch and X (formerly Twitter). The other side of BAT Mercury is the introduction of notifications pertaining to advertisements based on where you spend your attention. After you opt-in, if you view the advertisement associated with that notification, then a process starts to have some BAT contributed to your browser.

• Mechanism:

  The browser needs a lot of detailed information in order to make these determinations. This information is kept in the browser and the only thing that leaves the browser is a highly-synthesized synopsis sent in a disjoint traffic stream. For example, BAT Mercury starts with "statistical voting" for monthly contributions to publishers. Let's say that you spend twice as much time paying attention to site X than to site Y. All things being equal, twice as much BAT will be contributed to site X than site Y. First, the value of each "mini" contribution is the same, so twice as many messages get sent for X than Y. Second, through the use of zero-knowledge proofs, neither our servers nor a third-party can correlate any of those messages together. A similar strategy is used for contributions associated with advertisements.

• Process:

  The attention-based contributions, for both sites and advertisements, tend towards a "virtuous circle": BAT goes to the browser based on the advertisements that you pay attention to, BAT goes from the browser based on the sites that you pay attention to. This occurs entirely within an environment that places browser privacy first.

  With those three points in mind, BAT Mercury is very much a learning experience. Brendan had the vision, and the rest of us filled-in many, but not all, of the details. This process of continuing refinement will, over time, become finer grained.

2. BAT Gemini is the transitional architecture for the BAT ecosystem.

It added grants from the User Growth Pool to kick-start the "virtuous circle" until the advertising component is in full production (another part of BAT Gemini). It adds site-specific tipping, which is especially important for things like X (formerly Twitter) where the browser's attention is very fine-grained.

BAT Gemini is also about moving BAT functionality onto our mobile platforms—it's now on Android and is being aggressively developed on iOS. I don't know the release schedules, but I expect that before fall all three platforms will be in lock-step and close to feature parity.

Following this, BAT Gemini will add synchronization of BAT activities between browser instances. I am very much looking forward to that.

Finally, BAT Gemini is going to add bi-directional wallets.

3. BAT Apollo is the final "near-term" architecture for the BAT ecosystem.

The top-level goal is to match Brendan's vision—Many things that were deferred in BAT Mercury or Gemini are planned for this phase (cf., above: "You can solve any problem...") However, BAT Apollo is not the final architecture. (First you get to earth orbit, then you get to lunar orbit, then you do a lunar landing, then you go to mars after the Apollo phase is done.)

The primary goals of BAT Apollo is to add transparency and decrease transaction costs and improve decentralization. All of this while maintaining (or improving) browser privacy. The paradoxical requirement is increased transparency for advertisers and publishers to compare their gross revenue and net income.

At present, we are investigating the use of a proof-of-authority side-chain—I must emphasize we are still in the research phase of deciding which approach is best. Independent of this is the addition of "code points" to support multiple providers for wallets, site verification, settlements and so on. We are very much pragmatists in preferring to orchestrate domain experts (e.g., companies like Uphold) to handle important parts of the process; however, we're also sensitive to concerns of relying on a single provider.

One of the advantages of using a proof-of-authority network is that it allows us to spread the load between us and trusted partners. Part of the vision is that BAT eventually operates under a non-profit consortium. (You can find this in some of Brendan’s earliest writings… BAT purposefully refers to the "Basic" Attention Token, not the "Brave" Attention Token.)

That's supposed to be in BAT Gemini. I doubt that's in the MVP (cf., above: "You can solve any problem..."). I am very much looking forward to this. As of this writing, I have 5 different wallets with BAT on different versions of our browser/platform, and i'd really like just one!

In BAT Mercury & Gemini, only the entry/exit points of the process are on-chain. The primary reasons are economic and time-to-market. That is going to change in BAT Apollo, so that more things are on-chain, but the "chain" is going to be a side-chain not the mainnet. That should address the economic concern, and if we go with a side-chain using some kind of proof-of-authority consensus mechanism, then we should be good to go in terms of timing…

In truth, these questions are better directed to someone in the Product group. However, I can address two of your questions fairly easily:

• With respect to bi-directional wallets in the browser:

  This functionality is being worked on now for BAT Gemini.

  One thing to appreciate is that we are "crypto pragmatists". Among other things, that means that we'll continue to use the Uphold platform for hosting the browser wallet, and bi-directional wallets will require that you create an account with their service. As a part of that, you'll have to go through their know-your-customer (KYC) process. I am told that other wallet providers are also under consideration... however, I am quite confident that any wallet provider you deal with is going to have a KYC process, regardless of what the "crypto maximalists" would have you believe—that's the world we live in.

• With respect to BAT as a generic means of exchange, rather than being focused on Internet advertisements:

  This doesn't interest me. Another term for "generic means of exchange" is "currency", and BAT is a utility token. Anyone who wants to start their own currency needs plenty of legal and accounting counsel. However, my training is in computer science, neither law nor accounting, so I'm not giving anyone any legal or accounting advice.

• With respect to the other questions:

  The folks in the Product group are reading this thread and may chime in. I appreciate that you were expecting substantive answers to these other questions, but you probably also realize that you are asking the questions of the wrong person!

I am a fan of your site! One of the reasons we spent a lot of time rewriting the initial BAT Mercury client-side libraries was to be useful for a future BAT SDK; however, I am rather distant from the part of the company doing the BAT client work, so I don't have a lot of visibility into what the thinking is.

However, I do know that several of our internal folks will see your questions/ideas and then take a look as to how we can make this easier. We're still learning the best way to integrate the basic functionality into the browser, I doubt we'll see anything for a while. Sorry for having a not-so-helpful response...

"No MVP survives contact with the customer."

After the initial release, experience and feedback resulted in making the phases larger; however, the timeline document was not kept in sync. Internally, we've shifted some things between phases. Other delays arose due to switching from Muon to the chromium front end fork, for head to head competition with Chrome.

Of course, in my long answer on Mercury/Gemini/Apollo, I am describing my view on them, but I not the final word on these things…

I am a firm believer in Sutton's Law -- so, yes, it's a concern. Fortunately, Yan Zhu, our Chief of Security, and her staff have put into place a robust set of processes for both security and privacy reviews of projects and code. In particular, new features and major upgrades get a fresh review prior to merge. Other policies include our use of BCPs (best current practices) for logins and devices.

We're in Gemini now with Apollo early work and experiments overlapping. The current Gemini phase will run throughout this year and probably into next, while Apollo will continue into 2020 and 2021. In this industry, predicting anything beyond 24 months is almost certainly going to be inaccurate…

I have to respectfully disagree that free-riders are a "deadweight loss". Pretty much all systems have free-riders. You may respectfully disagree with my view: there are no plans to penalize free-riders. The BAT ecosystem is designed so that a particular site can not specify an ad campaign. Of course, a site may indirectly impact what notifications are generated by the content on that site. It is key to understand that notifications are generated in response to the browser's attention throughout the browsing session, not just the page/tab they happen to be viewing.

I suspect that most of the early ETH folks would disagree with you; though I also suspect that the early BTC folks would agree with you.

For myself, if you are serious about your profession (regardless of what the profession is), then seniority should denote experience. I started programming with punched cards. That environment has a relatively long turn-around period in terms of the edit/run/review cycle (e.g., 30m), so it tends to teach a check-your-work-first philosophy. However, back when I lived in Mountain View, a friend of mine was a PhD candidate in Physics, and was telling me how he had to schedule the linear accelerator 3 years in advance to run the experiments needed for him to complete his doctorate. 3y >> 30m, so I'd say that he learned those lessons far better than I did.

Another thing to keep in mind is that today's younger programmers stand on the shoulders of giants—whether we are talking about the folks who write mobile apps that work because mobile devices are so incredibly powerful, or folks who write distributed apps that work because Cerf, Postel, Braden, Clark, et. al., did such a wonderful job with TCP/IP, etc. Old folks such as myself must remind ourselves to constantly climb up to the same heights that the younger programmers start with.

BTW—no insult is intended with respect to these observations.

It's called the altsumer project. It's not about BAT, though Brave is supporting it. Since I work so much with crypto, I work with a lot of products and services, and I spend a relatively large amount of my time finding and evaluating those offerings. I'm planning to share my experiences on the theory and practice. As to what an altsumer is, you'll have to wait until the project launches, which is RSN.