tripper21 asks: What is the difference between BAT Mercury, Gemini and Apollo, for those of us who do not know?

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 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 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.)

JustinBilyj: When will there be a two-way wallet and mobile password sync with desktop?

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!

OogieFrenchieBoogie: Hello Marshall, As of today, which part of BAT transactions are on-chain and which part are off-chain for tips, and for BAT earned by users through ads? Will we see some changes in the future?

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…

KahunaKevinTiki: When will BAT accrued in Brave be directly transferable to Crypto wallets and exchanges (both Deposits and Withdrawals?), for example I have BAT sitting in my browser, I'm not sending to any publisher and right now that seems like the only option. I want that BAT sent to Coinbase to be added directly to my existing large stack of BAT holdings. I opted in, I accrued the BAT, I want those BATs as MY investment for MY time, with the OPTION of sending to others. This action would be even better if Brave could auto-schedule monthly transfers for those of us accruing BAT and stacking off browser as a personal investment. HOLDERS - We are your earliest (and biggest) adopters and believers, do not ignore us, as we are watching very closely with fingers on the sell button at the moment as Bitcoin rises towards $10k. When will this functionality be possible within Brave? Ballpark Date and confirmation of this upcoming feature addition, or a solid NO not ever going to happen, please. Brave can either continue to have my stack of funds by directly rewarding early Investors/Holders, or Bitcoin can have them. I hope and believe Brave will do the right thing here. Thank you. Side thought while I have your Basic Attention (see what I did there?) : Start a BAT store where you can put items on layaway, like headphones, games, movies, small tech items, whatever, and you designate a certain % of monthly BAT to pay off what you want. Designated BAT commitment is locked until paid. When it's paid off, it ships to your doorstep. Those drop shipping product are paid in BAT. So the incentive for users to browse more to accrue BAT for spending is further amplified. More browsing = happier advertisers. Would be a fun option for those non-investor consumers out there while keeping BAT within the ecosystem. The cool thing is the BAT you designate towards item rewards would likely increase in value over the months, so that's a double incentive to stash BAT away on something you want to buy, but not receive immediately. I would honestly use this for game pre-orders (instead of Amazon.com) that are 6-12 months away. Once the game ships it seems like you just got something for free - by browsing the web normally. Key takeaways here is expanding BAT incentive to tangible products while stealing business directly from Amazon! You've got a great idea and tech, it just needs to be opened up a bit for investors and target mass consumers. Browse web and generate BAT = Incentive. Open crypto transfers = Incentive. Target consumers = Incentive. Increased browsing to generate spendable BAT = More advertisers on board. Then moon, and Lambos for everyone.

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!

dcwj: Hey Marshall! I can't wait to watch the Apollo phase of BAT unfold. What excites you most about this phase of the project? Also, can you say what kinds of things might be possible to do with the BAT SDK? I'm the creator of givebat.com, and two things in particular that I thought of as potential extensions to the site were: some way for a web developer to integrate BAT tipping into a site directly; either by triggering the BAT tipping panel to come up in the browser with a button click, or a tipping widget or something inside the page (I bought the domain givebat.to, and I hope to build something in the future where typing in givebat.to/pewdiepie could trigger a tip to that creator 🙂)

some way for a creator (or developer) to easily get statistics on received BAT tips as they come in (I want to make a little physical box thing I could sell to creators that would light up every time a tip was received, perhaps with a Raspberry Pi, or an Arduino) Anyway, thanks for doing this AMA. I think the adtech space and the tech space in general still hasn't quite realized or understood what a major impact BAT stands to have on the internet, so I find it fascinating and exhilarating to watch you guys reinvent the whole concept of advertising and funding digital content.

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...

dcwj: That's awesome to hear that you like the site! And fair enough, I'm sure there are still numerous questions to figure out, and that the whole team has been very thoughtful about laying a robust foundation to build upon. I'm just overly eager to hear some details so I know what kinds of things I'll be able to build with it 😄 Thanks for your reply!

IamMeeoh: In accordance with https://basicattentiontoken.org/bat-roadmap-1-0/, Apollo should have started in 2018. We are not yet in Gemini yet, in the middle of 2019. What went wrong?

"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…

Unbathed: People who write code for Automated Teller Machines must remain aware that there is an active, motivated, technically sophisticated adversary seeking ways to exploit the machines for cash. I imagine Brave has similar adversaries. Does this result in a team of developers, all technically expert, and all suspicious of the world and of each other? How do you mitigate?

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.

IamMeeoh: Can we please have an update on (realistic) timings for the Roadmap phases?

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…

Unbathed: Suppose a creator has a website or podcast which depends on user support. For this creator, users who do not tip are a deadweight loss. Is there any technical obstacle preventing the creator from specifying an ad campaign with rules... Do not show my ad to any Brave users who do not tip 80% of their Rewards to creators overall Show my ad only to Brave users who have visited two of the websites on this list Show my ad only to Brave users who have, in the past month, visited at least three of the websites on this list and have tipped each of them at least five BAT

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.

Badrush: I've always wondered, is this an industry Junior Software Developers can get involved in? I fear that cryptocurrencies are too complex mathematically and the risk if built improperly too great to have anyone but senior developers contribute.

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.

investorpatrick: You mentioned "Finally, I may have another project to announce, but the timing may not work out for that". Is this a BAT project?