Brave Integration Update - Thursday June 17, 2021

This is an update from Brandon Dees in the Handshake discord:

So, basically i think we now all know the info @MikeMichelini revealed about Brave integration negotiations that were happening and the subsequent info that came from twitter discussions with Brendan etc. -- if you just look at twitter though, there's a lot of gaps in the info, conflicting assertions, etc.

Ultimately Brendan stated that we could just submit PR and get it merged the regular open source way and there'd be no need for Brave to get paid for that. The way he phrased it people interpreted to mean that we've achieved a negotiating breakthrough and now it's game on. I'm pretty sure that was already the official public stance they had established but wasn't able to dig that up immediately so maybe i'm misremembering or maybe stuff changed behind the scenes that i didn't know about. To my understanding there just weren't dev / funding resources to possibly focus on it sooner so nobody was pushing it.

AFAIK there's still also a path open to funding Brave's team to build integration features in-house on our behalf, and that's probably still an ongoing negotiation. Brave's documents come with confidentiality clauses so unfortunately nobody who's directly involved can really clarify any details at this stage, but my takeaway from chatting with a bunch of folks over the past few weeks is basically that dWeb Foundation has been going back and forth with them slowly for a while and things kinda were stalling out without much activity happening in that dialogue. Nothing had been agreed to, no final proposals on the table for a commitment decision yet even, etc. so I can understand why they may have thought it wasn't worth publicizing.

However, as we can now observe clearly from the community response to @MikeMichelini 's blog post and it getting scooped on twitter, this community isn't generally comfortable with high-impact strategic initiatives occurring in secret or without open community participation. Transparency and inclusive feedback.

So, after all that, @johnnywu/ had the good sense to establish a connection between someone with technical perspective / developer skills (me) and established familiarity with all the handshake concepts, and dWeb Foundation who'd been trying to figure out how to pave a path forward for Brave support to happen.

I suppose it looks like a natural fit because I'm available to work, I have dev skills, I'm adamant about security/privacy issues, understand the general tech concepts across the blockchain side and the DNS side and the browser side (although no specific deep experience in those areas), have made friends across the community's factions, etc.

I think if it works out how I'm hoping, it could be even more ideal fit than that. I've been thinking a lot about handshake "world domination strategy" since mainnet launch day, when I first read the HNS paper, have been collecting names, learning and explaining stuff, trying to gently steer the community in a wholesome trajectory, etc. In many respects, I feel like I have been consciously preparing myself aspirationally for this mission all year. I had really thought that more DNS experts and Blockchain developers would have been attracted into the active HNS community by now but the airdrop factor is still sort of dormant and well, devs tend not to be great at marketing/outreach networking stuff so it's hard to get the ball rolling. With some supporting team to keep me on track, I'm fairly sure I can pull off the essential technical implementation myself if needed, with no confidence about the timeline factor. Potentially with help of another dev or two to pair with, and someone more administrative to keep things structured and offload some chores, I feel fairly confident this whole Brave project should be possible to do, the configuration UI/UX, window chrome tweaks, and most importantly usable DANE, properly, in some kind of useful timeframe (vague uninformed gut instinct wild-guess is 6-24 months range, allowing for the usual kinds of slowdowns). When this discussion began I made a point of emphasizing the need for transparency about this process with the community and since then have mostly just been trying to get some initial perspective on all the involved players' perspectives before trying to start deciding things.

It might not work out how I'm hoping/imagining, and that's probably still ok one way or another. I have some trust that everyone involved here has benevolent intentions but paid or not, I'll try to do whatever I can to prevent this kind of project from being undermined from achieving the most essential goals of the HNS experimental project.

So anyway what I've discussed with dWeb Foundation so far is basically just catching up on some of that confidentiality-clause info between them and brave, which isn't a ton, and working on getting the key people in the community who should be forming consensus about this plan to the table to make sure this whole thing isn't ludicrous or anything.

So dweb foundation is exploring options to pay some dev(s) to do this Brave PR work. There are some scoping documents that had been proposed but I don't think they're anywhere near final. I'll be working on assembling my own variant proposal spec based on those. This stuff has to be pre-negotiated with Brave's team to ensure it's going to be something they'd be willing to merge before wasting resources on the implementation.

Ideally the next step is to present estimates for the time and money costs to deliver. There's naturally too many unknowns for that to be reasonable to conclude, so in the well proven manner of agile software development, I suggested just doing short/small commitment "sprints" to make some progress toward a next step incrementally and re-evaluate based on improved understanding each time before proceeding with more resource commitments. This iterative process limits the foundation's downside risks, allows for some kind of captured value to be delivered sooner rather than later, and helps the project steer toward true success rather than our up-front misconception of what success would look like.

The docs that were exchanged back and forth thus far, that I am aware of, are just two different implementation spec proposals. They're under confidentiality clause so I think I can only tell about them at the meta level and not get into their contents. The original was written by JJ. I haven't read all of it but first glance it seemed like it was covering stuff that we do need to be prioritizing tech-wise. The other one is a counter-proposal from Brave's team, and seems to me like they may be misunderstanding some of the tech and/or ethos of the project. I don't know yet whether either proposal would be at all reasonable to base any final binding agreement on, but I think it doesn't have to work that way. We should be able to discuss what we want browser support to look like as an open source community before submitting any "final" proposal or anyone committing to any expensive decision. There's some UI/UX considerations which seem to be what Brave team is most focused on, and then for HNS there's also DANE support which is fundamentally much more important. I think once a few things get cleared up, the UX stuff can be settled in a way that minimizes the compromises made. I also don't really care about that UX detail until DANE is sorted out. Shipping HNS resolution features to users without a DANE solution would be actively undermining their security/privacy and I can't support it. However there may still be some reasonable possibilities for getting some smaller PR(s) merged that focus on UI stuff and could be shipped before DANE support is completed.

So this week we were supposed to start talking about me doing paid effort to do the information gathering recon mission stuff to start coming up with a ballpark estimation of scope of work. I still haven't heard from a bunch of folks with key perspectives to contribute yet, and I think just getting a browser codebase to build from source is a bit of a project itself so I'm deliberately putting off everything that might not actually end up being needed in favor of getting everybody to the table and gathering perspective to make sure we're starting something that makes sense to start. Even then I want to start with small incremental feedback cycles so that we don't do something like get 6 months into writing DANE according to the spec before finding out that there's a newer spec that overrides it and that there are some special HNS compatibility issues to sort out before it's even a possibility, for example. The iteration time can probably stretch out once things are well informed and well planned if there's nothing specific to try to deliver in between.

Brave Browser Status (part 2)

Update June 11, 2021

The last couple weeks has been discussions in the Handshake developer community about the PR (pull request) path to Brave integration.

Brandon Dees has stepped up to help oversee and PM the initative - first by documenting where we currently are, who in the community can help and what we have. Once we have the ballpark analysis complete, we will have an idea of dev hours and cost needed.

Namebase and Dan from Kyokan are discussing the support of this integration, as well as grants from dWeb foundation and others


"The Day After"

Update - Saturday May 29, 2021

https://skyinclude.com/brave/

Wow, woke up 4am here and haven’t seen so many tweets and comments.

Have been collecting so many and reading them and my inbox on Telegram, Discord, and other channels overwhelmed.

About the source
There are groups trying to HELP the community - and some are not sure when / if / how to communicate that information to the community at large.

But from all of this - Brendan, the co-founder and CEO of Brave has made an amazing way to help us all deal with this awkward situation.

Thank you Brendan and Brave. Now it is our turn at the Handshake developer community to integrate.

Sorry if I divided the community on this. I love Handshake.


Brave Browser Status (Part 1)

So it is close to June 2021 - and many have asked for the latest status of the Brave browser integration with Handshake domains.

Here is the situation - and this is not “first hand” from Brave, but the information I am sharing is coming from multiple sources that are high in the Handshake community.

Brave is asking for 3 to 3.5 million USD for a 2 year of having Handshake names to work on their browser.

Yes, you heard it correctly. It seems we can “bargain” it down to 3 million US dollars from the 3.5 million.

We have all been excited and waiting for a couple months as we have heard of upcoming decentralized domain protocols being supported in Brave.

Seems .crypto by Unstoppable Domains was that protocol. And it seems (we cannot verify) that they paid this fee or something in that range.

Those in talks with Brave have said in private chat groups that Brave cannot “waive” the fee for us, as then they would have trouble charging other naming protocols in the future. That they need to be equal and fair to all of these new naming and blockchain protocols asking to be included in the Brave browser resolver.

Seems this is a nice new revenue channel for Brave and other gatekeeper browsers.

So where does this leave Handshake in the quest for mass adoption?

From a few chat groups I am in:

1) Open a discussion on the Handshake GitHub. This Github seems to be the more popular way the Handshake community has raised issues and shared their insight. Honestly I need to learn how to get on Github and in those chats - but the idea is we should post this publicly on Github and hear what the community has to say.

2) Raise money (open a GoFundMe? LOL) - so should we crowdfund 3 million US dollars from the Handshake community and internet community at large? But some have said - if this is only for 2 years, then we would constantly need to fundraise just to pay Brave browser.

3) Hard fork Handshake to re-allocate some of the funds - I know hard fork sounds scary - but some have said we can “carve out” locked HNS funds that would go to other groups (such as the ICANN reserves) and re-allocate that to Brave. But others have said - Brave already claimed their free money, and didn’t do anything to help the Handshake ecosystem - why give them even more funds. And is Brave browser really that important in the browser ecosystem?

4) Build our own browser - well it is something some have said. but there are already browsers, such as HandyBrowser, that are made for resolving Handshake names. Just for completeness of the options here I write this one

5) Hardware solutions - I am personally interested in more hardware solutions at the router level to bypass these Brave and other gatekeepers. Leaned that at HandyCon from Nik on “Beyond The Browser” https://www.youtube.com/watch?v=c_-sqRRw3sg or on http://handycon.promote.hns.to for full library.

6) Put that money to developers - If we can raise 3 million USD in the community - should we really put that into a minor market share browser? Why not put that into the open source developers. Maybe even hire developers who worked on Brave browser or Firefox browser and have them help Handshake with various solutions and plugins and enhancements.

I just thought it would be something we have to share as a community. I am tired of the tip toeing around about this Brave browser integration and hope this video and blog post raises more awareness of this.

While I do understand Brave may not have a solid income stream, I do wish this was a bit more transparent of a process.

What is your idea?

If there is a Github discussion on this topic - I will share here the link.

Tweet about this

Image Image Image

Brave’s Crypto DNS strategy