Implement Dat DNS-over-HTTPS

[pfrazee]

Tasks

• Resolve DNS over HTTPS.
• Implement an in-memory cache.
• Discover Dat alternatives to HTTPS sites and prompt the user to redirect.

Spec: https://github.com/beakerbrowser/beaker/wiki/Authenticated-Dat-URLs-and-HTTPS-to-Dat-Discovery

[pfrazee]

The "prompt to redirect" is a very simple P2P icon in the right side of the navbar. It will need work in the future.

[max-mapper]

👍 this is awesome

[pmario]

I like this possibility, because of the human readable format. ... BUT what about "link-rot", which is a major problem.

Let's say I have a link eg: dat://beakerbrowser.com/blog/ but the beakerbrowser.com domain doesn't exist anymore. So https://beakerbrowser.com/.well-known/dat doesn't return the dat-key anymore.

• Where and how do I get a valid dat-key?
• Even worse. What if the domain name belongs to someone else now?

just some questions that have come up. ... IMO none of them have been asked in #227

[pfrazee]

I think link rot is an inevitable tradeoff of an aliasing system. Unless the aliases are globally unique and permanent, you get link rot.

I personally wouldnt want an immutable aliasing system. Just yesterday some glitch caused me to lose the keypair that I was publishing dat://beakerbrowser.com with, so I had to update the DNS entry.

[pmario]

Yea. ... After posting it, I thought a little bit about it. eg: If one uses "prettylinks" in publications eg: PDF, the best practice should be to also publish the dat-link as a footnote, or somewhere else, where a user can find it. ... Not perfect but imo a usable workaround.

[pfrazee]

@pmario I think that's a pretty reasonable tradeoff. At least now it's possible, which is a big step up

[pfrazee]

One thing I'd like to do is enable site "snapshots", which uses Dat's existing ability to create static content-addressed archives (as opposed to the typical "live pubkey-addressed" archives). The idea would be, you nav to a site and say "New snapshot," and that'd be similar to forking: you create a new archive with the current content, but it's static and content-addressed.

[okdistribute]

The only thing I'm thinking is a problem here is that the swarm will become less healthy if the hash isn't able to be looked up by the live key. Ideally, the snapshot would be a subset of the live key so that any clients broadcasting the live key or the snapshot can share that with eachother.

[pfrazee]

@Karissa that's a good point. If we realize that needs to be a priority, we can use versioned URLs instead.

[pfrazee]

(And the plus side to versioned URLs is, we support them already!)