Proposal: Web of trust DNS

[cblgh]

I wrote about this briefly in IRC, but I figured I'd write an issue so that you could follow up.

The idea arose in conjunction with thinking about dat://shortnames-example.com, i.e. servers that host a file with a dat's location in /.well-known/dat.

Currently these can be used to access sites in Beaker in place of using a 64 character dat:// hash. However, we've been reluctant to use them in Rotonde due to the re-centralizing it entails. (If the server goes down the address stops working, and the p2p aspect is lost.)

DNS shortnames however provide both convenience (you can type a shortname from memory & recognize it when seen, as opposed to a hash) and mutability (should you lose access to your original dat you can point /.well-known/dat to a new dat.)

The main issue of the dat shortname being inaccessible due to a server outage can be fixed with a permanent local DNS, or cache, where you simple associate each DNS entry you've visited with its last known address.

I've seen that you've been working on bookmark-sharing in Beaker, where you can subscribe to bookmarks that other people make available. If we combine this idea of p2p sharing with the local DNS cache we could create a kind of web of trust DNS, where the people you follow can publish their local DNS lists. These shared lists could be used as a second fallback, should you want to visit a shortname address for the first time and the corresponding server can't be reached.

(There are issues with this, such as two peers publishing different dat hashes for the same shortname. One solution could be to use the newest entry. Another solution could be to present information to the user saying all of your peers agree that this is the latest address and 17/20 peers agree that this is the latest address.)

[Frando]

I've been thinking about similar problems, but came up with an alternative proposal (no code or detailed docs written yet). My idea was a "Dat Federated Name System". Basic idea is as follows:

• Beaker registers a new protocol handler, e.g. datns://
• Beaker comes with a default "root dat", but exposes a setting to override that root dat
• A datns Dat exposes a file, e.g. datns.json, listing paths pointing to either a) a path within this dat, b) another dat
• A resolution system travels through this name tree to find the target dat
• A user can override the root dat with a custom dat, listing different existing (shared) root dats with prefixes

The result I was imagining was something similar to newsgroup hierarchies. E.g. rotonde could provide a datns dat for the prefix "/rotonde", providing a username registry. Beaker's default root dat would have {'rotonde': 'dat://abc123...'} . Dat abc123, controlled by the rotonde community, would list individual usernames pointing to individual dats. Then, rotonde dats could be accessed in beaker via datns://rotonde/username ( or datns://rotonde.username, syntax would be tbd. It should have a seperator for paths within the dat, so either datns://rotonde.someuser/img/foo.jpg or datns://rotonde/someuser:img/foo.jpg or even dns-style datns://someuser.rotonde/img/foo.jpg , though I was initally thinking of not making the URL format too identical to DNS to avoid confusion, but maybe that's a non-issue due to the protocol handler being visible).

This would provide a federated naming system with different hubs providing unique names for different application domains. A datns for homepages could start with /me , one for software packages with /package , etc. A default root dat with its key included in beaker would provide a DNS-like experience, but the system would be completely federated by allowing users to override the root dat (thus customizing prefixes).

The result could be a naming system with the same UX as DNS but without relying on existing centralized DNS infrastructure (and removing the need to register a domain to have a user-friendly URL for a dat).

[Frando]

... and by re-reading the docs on the app:// scheme, I realize that most of what I wrote is covered by that. The missing element would be self-contained dat apps and a not dns based federated naming system that is not only known to beaker, but also to the dat cli and possibly dat-node.

[pfrazee]

Yeah, we'll be experimenting with this in some form via the app:// scheme. Now's a good time to toss out ideas. It'll be very interesting to see what happens when URLs are non global.

[ragekit]

I'm super noob with p2p but wouldn't a DHT be a solution to this problem ? a DNS server is basically a bit HT no ?

[pfrazee]

A DHT can only work in two modes:

• Anybody can write but the information is self-verifiable
• Only trusted users can write

We use DHTs to manage data that's addressed by cryptographic hashes or keypairs, because we can verify that the data is correct with minimal effort. Shortnames don't have that quality, so you'd need to control who can write data to the DHT. It may still be a useful solution, but it doesn't solve the core question of trust.

[JoshZeidner]

how do you resolve naming conflicts?

[ragekit]

Up this discussion because I do not think the App scheme solves the issue of trust.

Maybe there should be a way to check in your network of trusted people if they think the dat name resolution you examine is correct or not ? It brings the problem of user experience for non technical users up tho. Maybe there should be a way to subscribe to a dns service (another user or several users), if wanted.

[cblgh]

👀 looks left, right

bump

[pfrazee]

So in the last (oh my god) THREE years since this was brought up, I've done a lot of experimenting on this. I'm totally open to alternative views, but here's my current thinking:

I don't love DNS. The centralization is an issue, but I mainly don't love it because the usability is trash. We're trying to make web publishing easy but the infrastructure for registering a domain is still very manual and unapproachable to the average user. Plus it costs money.

My concern with a social or WoT domain system is that users expect URLs to be global. If you have a local address book, you're going to hit situations where sharing a URL to someone who is not sharing your address book will either give them the wrong resource or a 404. There's also a security concern: what happens when WoT names are used for software imports?

Instead I've been thinking WoT search and certificates might work much better. Search doesn't have the same concerns because it doesn't act like a 1:1 mapping; you look up the address and then interact with the resource's pubkey address. Certificates are basically equivalent: they label what the resource is but don't affect URL scheme.

Thoughts?

[guybedford]

Since no one else has responded yet, I thought I'd jump in with my blunt opinions on this topic. I've been thinking about this problem quite a bit from the perspective of how a decentralized npm registry might work, and I hate to use the "b" word, but ultimately I tend to think this is where it can be useful since it can ensure global uniqueness, verifiable history of name transfers, protection against squatting (since names have value), cryptographic reservations without exposing the name (the act of indicating a purchase of a name provides information of its value which shouldn't be possible to preempt in automated squatting). The browser as an SPV (or even full node) itself seems pretty powerful in joining this model, then treating a naming system as a highly generic "name of names" system - the naming problem is a general one shared by every package registry and dns, such a registry of registries that solves the core usability problems seems like the ideal to me. And there's also money to be made. Handshake etc are proving this out, but I tend to think the more general naming service approach over DNS-specific might be an interesting perspective.

[RangerMauve]

If Blockchain is on the table, I'd strongly advise using an existing one instead of making a new Beaker-specific one. Something like ENS or whatever the popular thing right now is.

[pfrazee]

If we're talking about a registry approach, a hypertrie would be able to provide an efficient, auditable registry that hits all the bullet-points that @guybedford mentioned. It would use a registration node rather than decentralized consensus.