Feature Proposal: Domainlists (DNS Systems Topic)

[ghost]

Ok, so there's been quite a bit of talk on how Domain Names should be handled by ZeroNet. Some people say to stick with Namecoin blockchain. Some people don't like Namecoin. Some people think we shouldn't be using domains in the first place and that we should stick to addresses only. Some want HTTP(S) DNS systems (and other dns systems) to work and be enabled by default, some don't. And some want to create a new blockchain.

Now... blockchains usually require money to pay for the domain. Then there's the issue of whether you own the domain forever (which could result in lots of domains pointing to expired/outdated sites) or for a limited amount of time (which could result in someone stealing your domain). Then there's the problem of how people access this blockchain... does someone replicate the database of domains to a zite (e.g. ZeroName)? Do we require all users to have the blockchain downloaded? etc.... Personally, I don't like the blockchain system.

Then... there's traditional decentralized (it's really more like federated) DNS. This greatly increases centralization and there's the problem of determining which DNS servers are trustworthy, etc...

There's also ivanq's new Name.Yo which is a centralized solution maintained by ivanq/imachug/gitcenter and is optional by default. Imo, this is the closest to the idea that I have... because anyone can create their own centralized dns "service" and anybody can opt into any one. One problem... people who want to register domains for the maximum amount of users now have to register at a lot of different "services".

The solution that I thought of is not perfect, and it has been thought about before. It is a very simple solution. It relies around the idea that your own computer is the most trustworthy of clients to yourself. By taking this central idea, we already have something that meets this... the relatively new Blocklists feature.

So, I propose a new Domainlists feature that will act like blocklists, but instead of blocking zites or users, it will be a list of domain mappings. A person can create their own domainlist for themselves, they can share this domainlist with others, or they can enable somebody else's domainlist (or they can do all three!).

And a zite that would make it easier to handle all of this would be relatively easy to create... it's about 75% the same as what my KxoBlock zite does right now.

2189 #2049 #2087 #1696 #104

[purplesyringa]

/cc @filips123 @geekless

[Thunder33345]

so to sum it up, in the most abstract way: basically sharable name to auth address mapping list i like it, it has 0 cost(unlike blockchain: miner upkeep + name renewals), pretty secure(only you can set it), shareable to certain extend(share it and others can mirror your list)

there might be some problems, the fact that how each links resolves base on the user themself we can end up with people sharing the same link to the site but each leads elsewhere(depending on which list they follows), so(links to list mapped sites) it cant be easily shared, opposed to .bit or others, poster would need to tell them who's list it is from etc...

we could address that by making them fall back to sharing the public address when posting, but it feels like that defeats the point of this(or any domain name resolution system)

[ghost]

Right, those are the two main problems. The first - where a list you have enabled has a conflicting domain with another list you have enabled - I think can be solved by going with a priority system or something - make one list a priority and always use mappings from that first. The other problem that you describe I'm not too sure on.

However, I don't think that this system is an end-all-be-all... meaning that I think it helps out with some things, but shouldn't be the only available option.

[filips123]

This is an interesting idea and I quite like it. However, because of the problems that were already written by @Thunder33345, this can't fully functional DNS system and shouldn't be the only available option.

But it is still be something that should be supported. It is something like /etc/hosts file but for ZeroNet level that can also be shared with others. This would be useful for testing or sharing personal sites with friends (or others).

[ValdikSS]

Take a look how domain names are implemented in I2P. Basically, it's very close to @krixano idea. There aren't any centralized DNS per se; each I2P router maintains its own "hosts file", with the functionality to merge hosts files of other users, by just downloading them over HTTP from a web server.

There are "domain registrars" which basically are websites which publish hosts files for other users. You can register your domain on such website and all users which use hosts file from this registrar would be able to access it.

Domain registrars are not the only way to add domains into your address book. The URL may contain full destination information for the domain, which the router will parse and add automatically (or notify user that this domain is already added with another destination, etc). This is called "addresshelper link", which looks like this: http://zeronet.i2p/?i2paddresshelper=75002LwLP5cMwjkKt1DmlXF9fXflqKnCxhS01VU~CUcHbNPpwQmuLTAKVnm7HS2tGlRjn6SVQv-uQT4A2P2YAWzBcMHtH2AP9M2D6l-j32kgJ7Ai2jL2TV34o0XVCzUsxGt-6e8Rhub0z96S-25Jwci-A1ci~JAJoXpALoMXV0JYY7od0KVWDVczCrsA3eaCOjLAj8Fz~uMRD~FDA04s8PrSnjWdwsRmGqXGXlYVVcFLWIeOedzq2MVKIsSllo3atl7CON47pWjPde~iQGGjpy3KjpjzLWdPdTWj7k807J5zPa8ErF-zHRM-k8lfcxAlWrigfnfWYDVuIiyS-DKvL5TTkDs4qdKN8d8DvkgYG1q62Zr5~w-Du0g0ZmQwVF1~IyjsL5rk-gLS23fv7zvsEevVruZUW5VVQ2g3~2bJX9yFPHRpFYfokaW9NJW3PgaX5W1Hj1KycVM-Me2RLQ1mxnnLKD1jSc0J9FABjXrPYxhkdOjExMo~vhC3dxJs3MEMBQAEAAcAAA==

Oh yeah, there's ZeroNet gateway on I2P I'm running since Oct. 15, 2017. Did I mention that before?

There are also "jump servers", a special hosts (webservers) which just redirect you to the addresshelper link for the domain they know. Like:

jumpserver.i2p?q=newdomain.i2p
HTTP 301 newdomain.i2p?addresshelper=…

I2P router can have multiple jump services defined, they would be used if there's no destination for requested I2P domain.

More information here: https://geti2p.net/en/docs/naming

[ValdikSS]

Also please restrict this feature to unique, not registered domain zones. Name.YO used to be called Name.IT and has been renamed by my request. Here are my arguments:

.bit domains could be used in ZeroNet because they may contain a special record with ZeroNet address inside the domain information, just like with regular domains. They may contain real IPv4/IPv6 addresses, MX records etc as well. .bit domains are consistent: once you registered .bit domain, you control it in both clearnet and in ZeroNet (since ZeroNet does not "implement" .bit domains but sync it with a real NameCoin database). In your plugin, the owner of name.it DNS name can't control name.it inside ZeroNet with your plugin.

Imagine if ZeroNet could query such records for a real DNS domains, so you can open e.g. 127.0.0.1:43110/zeronet.io/ and it would open. ZeroNet queries real zeronet.io domain over DNS, gets a TXT record which contains ZeroNet address and opens the website. By using real DNS zones, your plugin creates conflict with real existing DNS records and prevents implementing this functionality in the future.

[filips123]

Also please restrict this feature to unique, not registered domain zones.

Or even better, allow users to have any domain zone locally, but limit them when publishing domain list publicly. This would be useful for testing.

[ghost]

Also please restrict this feature to unique, not registered domain zones.

Hm.... this just gave me another idea for another unrelated proposal for ZeroNet, so thanks! I'll write up this proposal soon.

Update: I've now written up this proposal as issue #2205

[Thunder33345]

also we still havent define the suffix of mapped address i am thinking of something like this to stop the possible confusion of multiple sites with the same name: (.map is just an example word used here)

if i navigate to abc.map would resolve into say abc.bob.map(aka domain abc, from published bob list, in real world it would be abc.(map site auth address).map) based on the priority order when resolved successfully the current domain would change into abc.bob.map this solves the "what if i share a site that links to nowhere/another site because of conflicting names" now user would fetch from bob's list, or be prompted to download bob's list first (other users when navigating, once the client realize it's the same link, they will prefer the same address with the highest priority, say alice.map for someone else)

for private list i am thinking of: if the site is in your private address book(not to be confused with publicly owned by self lists) and it's top on priority, it would be (name).self.map, it might be a problem in that, it's not very "sharable", but it's nice to be able to hide your own sites in your own short aliases, so maybe double edged

there's one big gaping flaw in my solution/idea: we are still falling back onto bitcoin addresses in the end, we might as well just make (name).map@site.tld(of any kind as long as your plugin support such) it's not solving the problem, it's just pushing it aside

[filips123]

@krzysztof113 This is already #2214 for this.

[ghost]

@krzysztof113 That's less simple, not more. It also relies on traditional DNS servers where you have to pay to register domains.

Multiple solutions are better than one, and this (what I proposed) is an extremely simple (too simple, actually) solution.

Finally, eventually we will want to have some form of decentralized DNS system, and currently we have none - ZeroNet currently relies on ZeroName, which is decentralized in information transportation, but not decentralized in ownership.