letsdane VS beacon

The easiest way to do this is to use letsdane https://github.com/buffrr/letsdane

Easiest way would be to deploy LetsDane and then allow a user to set the DoH server for the LetsDane proxy to use: https://github.com/buffrr/letsdane

P.S. Does anyone know why "humbly/" isn't working with HTTPS either? It's the same error that I'm getting. According to https://github.com/buffrr/letsdane, 3b/, letsdane/, proofofconcept/ and humbly/ all have DANE enabled. "humbly" appears to be configured properly (DNSSEC, SSL cert w/ matching TLSA), but I get the same SSL error when trying to resolve with Fingertip. Anybody else??

To securely access an HNS domain using DANE, extra software is required (until we get DANE browser integration!): https://github.com/buffrr/letsdane

Yes but you need a HNS resolver, which can also resolve legacy DNS names. So I have hsd installed on a raspberry pi on my home network, and another running on a VPS -- I set all my devices to make DNS requests from those servers. Set once and forget: now I can visit all HNS names as well as every DNS website. There some caveats to this, and the biggest issue is SSL / TLS / https but we have a solution for that as well: https://github.com/buffrr/letsdane All web browsers work fine with HNS names, but until a major browser implements native DANE verification, the middleware proxy is required.

I readily admit that cooking the mozconfig is some holy hell, but they do have real-world examples in the repo; did you experience problems at that stage, or it literally wouldn't compile?

And while I haven't tried Ungoogled-Chromium, for unrelated reasons I helped an OSS project build their Brave-derivative in a container, so that may interest you: https://github.com/imperviousinc/beacon/blob/main/Dockerfile The only reason it's not already GitHub Actions for them is the chromium_src is 38GB and GHA cache is capped at 10G, but while digging up the link to that Dockerfile, I was reminded that there is a GHA for the macos build: https://github.com/ungoogled-software/ungoogled-chromium-mac...

While not exactly the same audience, one may find the Dockerfile for building Beacon handy as (a) more code, less talking (b) since Beacon is just a patched Chromium, its dependencies should be a superset of vanilla Chromium

Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated: https://github.com/imperviousinc/beacon/blob/main/tools/src/...

and again https://github.com/imperviousinc/beacon/blob/main/tools/src/...

This trend of "I'm going to invent some build tool because there are not enough build tools in the world" is evidently leaking out of the node ecosystem

For clarity, I did see that this was inspired by the brave-browser model, but of the ones to draw inspiration from, that's for sure not it given that their CI is closed source and they're trying to use npm in lieu of a more structured, comprehensible system

I like trying out alternate browsers, so congratulations on the launch, and I'll for sure try to build it, but I wanted to draw these to your attention because my experience with software is that error handling is about 80% of the job