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.