The domain naming scheme proposal

[wandrien]

Some related comments and discussions:

• Browser plugin for 127.0.0.1:43110 -less site access #83 (comment)
• Browser plugin for 127.0.0.1:43110 -less site access #83 (comment)
• ZeroID-based domain names #1696
• Add DNS Support #104
• More domain name systems #2049

The idea:

• ZeroNet site should be accessible with both http://127.0.0.1:43110/... and http://.../ via a proxy.
• When accessing zites with a proxy, the pseudo-TLD .zeronet is used:
  http://<address>.zeronet/
• When accessing zites with http://127.0.0.1:43110/, the .zeronet part can be ommitted and is ignored by the core if present.
  These point to the same site:
  • http://127.0.0.1:43110/<address> - the classic way.
  • http://127.0.0.1:43110/<address>.zeronet - for similar look&feel to the proxied addresses.
• The second-level domains are handled by plugins.

---

The proposed second-level domain schemes:

• Namecoin domains: .bit.zeronet

  • Proxied: http://Talk.ZeroNetwork.bit.zeronet
  • Non-proxied: http://127.0.0.1:43110/Talk.ZeroNetwork.bit

• Cert-based, as proposed in ZeroID-based domain names #1696: .user.zeronet

  • Proxied: http://geekless.zeroid.user.zeronet, http://geekless.kxoid.user.zeronet
  • Non-proxied: http://127.0.0.1:43110/geekless.zeroid.user, http://127.0.0.1:43110/geekless.kxoid.user

• Opennic-based (Add DNS Support #104): .opennic.zeronet

  • Proxied: http://example.libre.opennic.zeronet
  • Non-proxied: http://127.0.0.1:43110/example.libre.opennic

• Onion-based (the protocol proposal hasn't been published yet): .onion.zeronet

  • Proxied: http://nd6bvylhggfd41g.onion.zeronet
  • Non-proxied: http://127.0.0.1:43110/nd6bvylhggfd41g.onion

[rllola]

Are we sure we want the .zeronet at the end ? It makes it a bit more hard to read... It is slightly more difficult to find the relevant domain name information. I am personally in favor of the zero:\\ or zeronet:\\ protocol handler.

[wandrien]

In my opinion, the protocol handler cannot be considered as a proper solution, since 1) the protocol used by browser is actually HTTP, 2) Zeronet also makes use of the ws:// protocol under the hood (websocket connections). 3) there can be other widely used protocols in the future, which will also be supported by ZeroNet. (As discussed in #83 (comment).)
The issue is about the name resolution, and the protocol has litle or nothing to do with the name resolution.

.zeronet looks a bit overwhelmed, but .zero is already registered by ICANN. Despite the fact that ICANN can steal just any TLD name for its own purposes, I think we should do our best to avoid the name clash with the existing TLDs. At least, if the name conflict appears in the future, it will be possible to say that .zeronet is long in use and other applicants are playing foul game.

[wandrien]

The problem of the proposed approach is that domain names are case-insensitive, while cryptographic hash addresses are case-sensitive. So http://127.0.0.1:43110/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D/ turns into http://1hello4uzjaletfx6nh3pmwfp3qbrbtf3d.zeronet/ which is totally wrong.

So, for those addresses, we need the hash part to be in the path after the domain name.
The other way is to switch to a case-insensitive encoding, but it breaks the compatibility with the Bitcoin address format as well as with most other widely used formats for public keys. (Except for .onion ones)

We can use something similar to http://zero/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D/ or http://zeronet/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D/, and it looks as a working option as long as we are able to provide the domain isolation with iframes.

If the iframe support gets dropped by browsers some day, a case-insensitive encoding is the only option.

[filips123]

I think that easiest and fastest way to at least enable .zeronet domains it to use Proxy PAC file.

Users need to add this Proxy PAC file to their system or browser. This will use localhost:43110 for all hosts ending with .zeronet.

function FindProxyForURL(url, host) {
  if (shExpMatch(host, '*.zeronet')) {
    return 'PROXY localhost:43110'
  }

  return 'DIRECT'
}

Then the ZeroNet code needs to be updated. There are currently a few problems which need to be resolved:

• Server will throw Error 403: Invalid host. The server also needs to accept hosts that end with .zeronet (maybe there should also be some additional security checks). There is already 4ffd642 but it needs to be enabled by default and with more features (support for .zeronet).
• Code needs to be updated to ignore .zeronet at the end of the address. If not, the site will not be found.
• Addresses will turn into lowercase, so they will become invalid. There needs to be some solution for that. There is also PR Support different cryptographies #2053 for multiple cryptographies and some of them might support case insensitive addresses.
• There could be problems with UiPassword or Multiuser plugin. Users who use those plugins will need to input password for every site they visit (because cookies will be only for one domain). See my issue Better user management #2050 for better user management.

This is for the beginning. It could be annoying for users to set Proxy PAC file, so there also needs to be some more automated solution.

This could include some registry tweaks and some other settings to automatically use ZeroNet for all .zeronet domains system-wide.

Also, can we register .zeronet TLD? This would make sure no other would use it.

---

The proposed second-level domain schemes:

There should also be support for other domain systems, as suggested in my issue #2049. But domain scheme structures should be almost the same.

Cert-based, as proposed in #1696: .user.zeronet

What if there is some ID provider that would use another domain system, for example, Ethereum Name Service (.eth)?

Based on your examples, cert-based domains are http://geekless.kxoid.user.zeronet which is user geekless on provider kxoid.bit. But what if there is user geekless on provider kxoid.eth (note .eth)? How would you write this?

Opennic-based (#104): .opennic.zeronet

Here it would maybe be better to just use .zeronet. See my #104 (comment) for why.

Onion-based (the protocol proposal hasn't been published yet): .onion.zeronet

I don't know if support for this is actually needed. Onion domains are random, so there's probably no benefit from using it instead of a regular Bitcoin address.

But if there could be some benefit, maybe similar to that with classic DNS, it should still be supported.

---

We can use something similar to http://zero/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D/ or http://zeronet/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D/, and it looks as a working option as long as we are able to provide the domain isolation with iframes.

I personally more like .zeronet domain than http://zero/ hostname. It looks more clear and more valid because ZeroNet sites should be different origins.

I hope there is some solution for turning URL into lowercase. If there's not, we would need to use some other solution.

[wandrien]

Also, can we register .zeronet TLD?

We should have $185000 and be some kind of legal entity (company or organization).

[purplesyringa]

I hope there is some solution for turning URL into lowercase. If there's not, we would need to use some other solution.

Simple & silly solution: Just ignore the address case. The probability of two addresses matching case-insensitive but not totally equal is small enough to ignore it.

[purplesyringa]

I don't know if support for this is actually needed. Onion domains are random, so there's probably no benefit from using it instead of a regular Bitcoin address.

Though I have no idea how onion domains could be used in ZeroNet (waiting for @geekless'es proposal), there's a thing like vanitygen there. facebookcorewwwi.onion would like to have a word with you.

[filips123]

We should have $185000 and be some kind of legal entity (company or organization).

Oh...

Simple & silly solution: Just ignore the address case. The probability of two addresses matching case-insensitive but not totally equal is small enough to ignore it.

This would be ok it it would be possible to implement.

Though I have no idea how onion domains could be used in ZeroNet (waiting for @geekless'es proposal), there's a thing like vanitygen there. facebookcorewwwi.onion would like to have a word with you.

Yes, vanity domains could be useful if you already have them.

[wandrien]

I hope there is some solution for turning URL into lowercase. If there's not, we would need to use some other solution.

Simple & silly solution: Just ignore the address case. The probability of two addresses matching case-insensitive but not totally equal is small enough to ignore it.

That requires implementing the case-insensitive matching on the tracker side as well.

[purplesyringa]

Not really. Just send the lower-cased address to trackers.

[purplesyringa]

offtopic: BTW, your idea about making a tracker to collect site list won't work, because ZeroNet uses the SHA1 of the address for announcing, not the address itself.

[wandrien]

offtopic: BTW, your idea about making a tracker to collect site list won't work, because ZeroNet uses the SHA1 of the address for announcing, not the address itself.

All of a sudden! On zero:// too?

[purplesyringa]

SHA1 is used for clearnet, SHA256 for zero://.

[wandrien]

Not really. Just send the lower-cased address to trackers.

So, looks like we should send sha sums of the both case-sesitive and lowercased addresses.

[purplesyringa]

So, looks like we should send sha sums of the both case-sesitive and lowercased addresses.

For backward compatibility?

[wandrien]

SHA1 is used for clearnet, SHA256 for zero://.

That's a great news, on the other side. So one have to know the actual address to visit a site. Trackers and DHT cannot be used to get access to new or private sites.

For backward compatibility?

Yes.

[purplesyringa]

One problem that arises when we make addresses case-insensitive is Bitcoin compatibility -- someone can accidentally transfer money to 1hello4uzjaletfx6nh3pmwfp3qbrbtf3d instead of 1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D.

[filips123]

@imachug Are that lowercase addresses actually valid Bitcoin addresses (because of invalid chars and checksum)? Won't wallets prevent people to send Bitcoin to invalid address?

I think that site address should only be shown in lowercase in URL. In the UI (sidebar...) and ZeroFrame commands (siteInfo) should still be in mixed-case.

[purplesyringa]

@imachug Are that lowercase addresses actually valid Bitcoin addresses (because of invalid chars and checksum)? Won't wallets prevent people to send Bitcoin to invalid address?

You're a genious, that's right.

However, we still have a small problem that you can't donate directly to site address anymore (though, that's somewhat a feature)

[filips123]

However, we still have a small problem that you can't donate directly to site address anymore

Could real site address still be displayed in UI, sidebar and ZeroFrame commands?

[purplesyringa]

Could real site address still be displayed in UI, sidebar and ZeroFrame commands?

Heck, you can actually recover the full address (case-sensitive) from the content.json signature! So it's possible.

[wandrien]

So, it becomes more and more like a workable solution.

What' worrying me most now is the cert-based model.

First, we have an optional .zeronet part to refer to the ZeroNet address space.

Second, we need a part to distinguish the cert addresses. I propose using .user, but it may be .cert, .id etc. (What's better?)

Third, the cert proveder itself. Here the problems begin. Since the provider names have the dot inside (zeroid.bit, kxoid.bit etc), the dot cannot be used to split the user and the provider parts without additional considerations.

We can arbitrarily discard suffix .bit from the provider names, but that raises the question why? And how should we handle providers with other suffixes, if any?

Next, where we should save the provider list. Should it be hardcoded, fetched from some site etc? Or we can just scan the network for widely used provider names and their public keys, and if there isn't any ambiguity or conflicts, use those names?

In this way, the plugin, implementing the addressing model, can automatically detect that zeroid.bit is a provider name, and the next part is a user name.

The latter looks good at the first glance, but I have some doubts about the security. Okay, lets say we have domain subdomain.geekless.zeroid.bit.user.zeronet (looks scary lol). It is parsed as:

• Subdomain subdomain, signed by:
• User geekless, signed by:
• Provider zeroid.bit.

What if someone adds a new provider and names it geekless.zeroid.bit? Now the domain is parsed as:

• User subdomain, signed by:
• Provider geekless.zeroid.bit.

And it poins to a different location.

We should check for provider names, that looks like a subdomain of other providers and most likely block the domain resolution for them. On the other hand, someone can use the provider name bit, which blocks the genuine providers.

[purplesyringa]

Can we use @ to separate user ID from the provider? In this case, we don't even need the .user/.cert/etc. part. That might look a bit better. E.g.: [email protected].

[wandrien]

[email protected] still points to zeroid.bit, as it's parsed on the browser side. It's not possible to force a browser sending a HTTP query with a host name containing @.

[purplesyringa]

Ok, that's a problem. We have - however, which is (probably?) disallowed in ZeroNet hostnames. So, subdomain.geekless-zeroid.bit may work?

[purplesyringa]

Or subdomain-geekless.zeroid.bit, which looks a bit better (and doesn't suffer from that "zeroid.bit" vs "geekless.zeroid.bit" provider problem).

[wandrien]

The both conflict with the Namecoin address space.

[wandrien]

We have - however, which is (probably?) disallowed in ZeroNet hostnames.

Allowed. For example, http://127.0.0.1:43110/zerome-reloaded.bit

[purplesyringa]

Oh, my bad, I looked through ZeroName and didn't find a site with a dash. Here's another idea then: your question was about how to distinguish subdomain by [email protected] vs. [email protected]. My point is that it makes little sense to make both A and x.A certificate providers (and x.A and A are owned by a single person), so we can just take the certificate provider with the smallest length (i.e.: is bit a certificate provider? no. is zeroid.bit a certificate provider? yes, stop here.)

[wandrien]

is zeroid.bit a certificate provider? yes, stop here.

Yeah, but my point is that the plugin should scan and detect cert providers automatically. (We can just scan data/users/content.json on all the downloaded sites.) So it has no internal knowledge of what is zeroid.bit and what is bit.

So, what should we do? I guess, if the plugin detects a conflict, it should just stop and report the issue to the user. The user have to manually blocklist bit as a fraud provider.

In this case, it's the same solution as for spammers and sites with inappropriate content -- blocklists. Sites, trying to fake a provider identity, should be considered as inappropriate and included in some blocklist for that reason.

Thinking about it, it looks like a good solution for me now. No one should have power to dictate terms to ZeroNet users. The ZeroNet distribution may have some reasonable defaults, but it's up to user to finally decide, what is trustful and what is fraud.

[purplesyringa]

Ok. So, what's the best solution then? Crawl all user content.json's to gather a cert_user_id <-> address mapping?

[wandrien]

Ok. So, what's the best solution then? Crawl all user content.json's to gather a cert_user_id <-> address mapping?

As the last resort, yes. For zeroid.bit, the database is located at the address of the provider key, so we can access it directly.

12F5SvxoPR128aiudte78h8pY7mobroG6V (kxoid.bit) is just an empty site now, redirecting to another location. I don't know what is a proper way to access its database, if any.

We should develop a uniform protocol for accessing the provider DB in the future.

[rllola]

In my opinion, the protocol handler cannot be considered as a proper solution, since 1) the protocol used by browser is actually HTTP, 2) Zeronet also makes use of the ws:// protocol under the hood (websocket connections). 3) there can be other widely used protocols in the future, which will also be supported by ZeroNet. (As discussed in #83 (comment).)
The issue is about the name resolution, and the protocol has litle or nothing to do with the name resolution.

.zeronet looks a bit overwhelmed, but .zero is already registered by ICANN. Despite the fact that ICANN can steal just any TLD name for its own purposes, I think we should do our best to avoid the name clash with the existing TLDs. At least, if the name conflict appears in the future, it will be possible to say that .zeronet is long in use and other applicants are playing foul game.

From my understanding, a protocol handler is an application that knows how to handle particular types of links. And it is not what we want ? I get your point on HTTP however I am not convinced that it is relevant (but I am not saying I can't be convinced...). Also I am interested in starting ZeroNet program using the protocol handler and adopting this standard would allow it. However I am aware that not everyone might be using ZeroNet this way. They might have a server running ZeroNet and they just need to register the browser which is possible too.

Regarding the HTTP argument, I am wondering that if the HTTP part isn't only the protocol use to 'consume' the content? Like we download a video using torrent application which is open with the magnet protocol handler but actually consume the video using a video player?

[purplesyringa]

There's a gopher plugin we've made together with krixano, and it worked rather well, so I'm sure that more protocols for consuming content will be added in the future.

[wandrien]

zero:// can be used to redirect the link to an OS-level handler to run a ZeroNet instance, which then opens the (appropriately modified) link in a browser.

But that goes beyond the scope of this proposal.

[rllola]

There's a gopher plugin we've made together with krixano, and it worked rather well, so I'm sure that more protocols for consuming content will be added in the future.

Nice! Do you have the link to repo? Have you rebuild ZeroNet in it?

[rllola]

zero:// can be used to redirect the link to an OS-level handler to run a ZeroNet instance, which then opens the (appropriately modified) link in a browser.

But that goes beyond the scope of this proposal.

Yeah I agree this is a bit out of scope. It is however not clear why you want to add the .zeronet if it is only to avoid the http://127.0.0.1:43110/ which redirect to ZeroNet if we can fix it at the OS-level ? Or I am missing a use case here ?

[purplesyringa]

Nice! Do you have the link to repo? Have you rebuild ZeroNet in it?

Here's a repo for Python 2 version: https://github.com/imachug/Plugin-Gopher

[filips123]

@imachug Will there be Python 3 version?

[purplesyringa]

@filips123 That project was somewhat a PoC, and we (krixano and me) have some more projects to do now, so I think that plugin isn't going to receive any updates. If someone likes the idea though, I'm ready for PRs.

[styromaniac]

The current system is fine. This idea is rather ridiculous and pointless.

[purplesyringa]

The current system is fine. This idea is rather ridiculous and pointless.

So, you don't think Namecoin centralization is a problem?

[styromaniac]

So, you don't think Namecoin centralization is a problem?

That assumes a bit much. Is there no alternative like .eth?

$185,000 is a hefty price, a few yearly salaries or bug bounties fitting into that bill. Not to mention it's centralized and clearnet reliant. Am I wrong?

If I am, maybe .zn is better for shortness/convenience?

I know you're more knowledgeable than I, but many of us are not understanding the idea well.

Can you make bullet points for all the benefits in OP? Your points are scattered between comments.

[filips123]

That assumes a bit much. Is there no alternative like .eth?

I'm currently working on ENS support so this will be supported in near future.

$185,000 is a hefty price, a few yearly salaries or bug bounties fitting into that bill. Not to mention it's centralized and clearnet reliant. Am I wrong?

You mean this for .zeronet TLD, right? I think that this is very big open source project. But it's not really needed. It's just to standardize things and prevent others from taking this TLD, like Amazon did with .zero?

If I am, maybe .zn is better for shortness/convenience?

It would conflict with two-tetter TLDs for countries.

[styromaniac]

Understood.

[filips123]

@HelloZeroNet @geekless It might be possible to register .zeronet TLD for as a special-use domain for free. See #2100 (comment) for details.

[KilowattJunkie]

I know I'm not a contributor so I hope I'm not overstepping my bounds, but I stumbled on this thread while looking at ZeroNet and I wanted to throw my two cents in.

I really think the additional TLD isn't the best solution, and is actually exacerbating the problem you're trying to solve (the central dependency on Namecoin). It seems that this problem actually originates from the current ZeroNet architecture that is mixing domain resolution and domain access concerns, rather than letting the resolution and protocol stacks do their jobs independently. By adding the new TLD you're maintaining that coupling and actually limiting the amount of ways a user can resolve a ZeroNet address. For example it would be great if website owners could add something like a ZERO record to their normal DNS records that would allow a typical ICANN TLD to be accessed via ZeroNet. In addition, if you maintain the current coupling, you'd be working against the resolution stack and preventing a lot of normal things like DHCP/locally defined search domains and host overrides, as well as creating tech debt if any future resolution protocols become popular. It would be better to design a spec for ZeroNet records instead, and then allow the upstreams (i.e. browser and DNS service maintainers) to implement it (or submit patches yourself).

As you noticed, the new TLD also breaks things like TLS, and I'm sure there will be other unknown effects if it's added. As a website owner I should (ideally) be able to serve the same certificate and site to both normal and ZeroNet users, or even mix the two (e.g. fall back on plain web content if it's not available on ZeroNet in a timely manner) without running into issues like cross site scripting and CORS. A better solution would separate the resolution concerns out, and it seems like adding the new protocol is the right way to go about it.

In my opinion, the protocol handler cannot be considered as a proper solution, since 1) the protocol used by browser is actually HTTP, 2) Zeronet also makes use of the ws:// protocol under the hood (websocket connections). 3) there can be other widely used protocols in the future, which will also be supported by ZeroNet. (As discussed in #83 (comment).)
The issue is about the name resolution, and the protocol has litle or nothing to do with the name resolution.

I actually disagree with this on two points. First, even though the browser is using HTTP, that HTTP is still being wrapped, which actually points to having a new protocol. Second, the protocol actually has a lot to do with resolution, for example using a file:// protocol in the browser affects how the browser resolves the url, and things like pop:// makes the resolution stack to look for MX records. Although we don't typically think of it this way in the web world, name resolution and protocol are actually pretty tightly coupled, we just ignore it in the browser since it's all HTTP anyway.

I do agree with the concerns regarding the extensibility of the zero:// protocol though, and having a protocol simply wrap HTTP does 'stink' a bit. My proposal would be that we create a few new protocols rather than putting them all under zero://, for example zhttp:// and zws:// for the two @geekless mentioned. This would allow us to show the user how they're accessing the site (i.e. HTTP{S} over ZeroNet) which kind of tidies up the wrapping issue, and also makes it so other protocols can be added later very easily. In addition, it allows us to keep the resolution separate from the protocol, so we can access any site we can resolve, whether it be zhttps://github.bit or zhttps://github.com. It also solves the domain case issue, as case insensitivity is defined per protocol, so we can assert that ZeroNet addresses are case sensitive. This would still be backwards compatible with current name resolution as Github.{bit, com} would point to the same ZeroNet address. We would just have to consider a URI in the form of zhttp://{some SHA1 hash without a TLD} as an address rather than a domain. It also solves the TLS issue since the domain won't change.

The only problem I see at a glance would be that the resolution stuff may be a bit tough to add at the browser level. I could see the Chromium maintainers not wanting to add it, but I could also see some maintainers of forks, like Brave and Dissenter, being happy to add ZeroNet integration directly (Dissenter already has webtorrent integration), so it may be feasible.

[filips123]

There is a new browser extension by @sprite-1 which adds support to access ZeroNet domains using URL prefixes or custom TLDs. There is also ZeroTalk topic about it.

Ways of accessing are described in its README. However, the extension doesn't load site to the original URL. Instead, it just redirects them to http://127.0.0.1:43110.

I think that ZeroNet should first standardize one specific way of accessing ZeroNet domains. Then this (or any other extension or another program) needs to be modified to use that specific way. It would also be good it could leave original URLs. Then this extension should be made "official" along with other programs for accessing ZeroNet domains.

---

There is also another extension which uses PAC file so URL can stay the same. However, it is only available for Chrome and abandoned. Some of its code could maybe also be reused for a new extension.

[filips123]

Mentioned sprite add-on tries to support all but that can cause more problems then it solves.

Why do you think so?

Because there is currently no standard, all options should be possible. When standard will be created, only is should be enabled.

[sprite-1]

As far as I know, the only thing my extension potentially screws up are *.bit domains on regular browsers but that's pretty much it

[filips123]

@sprite-1 Can you add configuration page to let users manage which keywords, addresses and TLDs should be rewritten? This would be useful if the user does not need all possibilities or you forgot some of them. It should have the following option:

• Keywords: [keyword] [address] (user chooses [keyword]) -> http://127.0.0.1:43110/[address] (example zn 1Name2NXVi1RDPDgf5617UoW7xA6YrhM9F)

• Keywords: [host]/[address] (user chooses [host]) -> http://127.0.0.1:43110/[address] (example http://zero/1Name2NXVi1RDPDgf5617UoW7xA6YrhM9F)

• Domain without stripped TLD: *.bit, *.yo, *.yu...

• Domain with stripped TLD: *.zero, *.zeronet...

[krzysztof113]

@filips123 Scenario: someone pastes link in reddit etc with http://mydomain.zeronetrocks but you don't have that particular plug-in that will redirect properly and you have to manually extract "mydomain".

[filips123]

@krzysztof113 This is not what that plugin is meant for. And how would you actually do this with a plugin?

This needs to be done with ZeroNet changes. Public ZeroNet instance should accept URL like talk.zeronetwork.bit.example.com where talk.zeronetwork.bit is ZeroNet domain and example.com is proxy URL. The instance should then extract ZeroNet domain, lookup site and serve it. This can't be done with plugin.

For local ZeroNet instances, talk.zeronetwork.bit.zeronet is enought. It should be handled by local ZeroNet instance and can be done with proxy PAC file, custom DNS or DoH server, system program or browser plugin. However, all cases would require ZeroNet changes to handle server on custom URLs.

See this issue, issues linked from this issue and issues that link this issue for details.

[sprite-1]

Can you add configuration page to let users manage which keywords, addresses and TLDs should be rewritten?

I've been meaning to do this but just haven't had the time yet lately so it's definitely something I want in there

[filips123]

I created a comment about different ways of accessing ZeroNet and ways of implementing that in #2100 (comment).