ZeroID-based domain names

[wandrien]

The current proof-of-concept implementation: https://github.com/geekless/ZeroNet/tree/IDName/plugins/IDName

• [x] Domains <id>.zeroid are resolved with the ZeroID cert database.

  • [ ] Cert sign verification is not yet implemented.
  • [ ] Support for any ID provider can be added in the same way, if it exports a machine-readable database. But now it is only ZeroID, so no code for managing toplevel domains is present.

• [x] Subdomains <anything>.<id>.zeroid are resolved with a table from <id>.zeroid/content.json

  • [ ] No indication for long-running operations in UI yet. (Modification of the core Zeronet engine is probably needed.)

• [ ] Domain cache is silly yet.

[wandrien]

Please continue here the discussion from PR #1683. @DaniellMesquita, @imachug, @Thunder33345

[wandrien]

@Thunder33345:

but i dont think the .id is perfect for services that dont ends with id, but again id should be good enough to indicate this is derived from ID registries

That would be nice, but we have a problem: .id is a TLD of Indonesia.

Although we don't have to follow ICANN rules as well as they don't have to follow our ones too, it would be good to maintain some level of compatibility. Theoretically, DNS domains can be used in ZeroNet as well. (Issue #104)

[wandrien]

@Thunder33345:

is it nessarily to visit my main domain to find the subdomain(which is listed in the contents.json)?

Since the only thing we know from the ZeroID database is your Bitcoin address, we have no other option except loading the data from that address. In my implementation, the resolver reads the domain_records field of /content.json to resolve subdomains.

There can be another option — the centralized domain database containing user-provided records, that works in the same way as ZeroTalk, ZeroBlog, ZeroMe and so on. It has the same drawbacks as those engines have: can be easily DoSed, the data can be censored by the site owner, no way to easily migrate out if the site becomes unmaintained.

[Thunder33345]

hmm that's what i feared if we need to also support clearnet domains we should follow ICANN

we might be able to do .z(ero)id since it's TLD for all registries ideally it should be as short as possible

or just roll with the fact that everytime we want to add a new id to support this we will make a new TLD

There can be another option — the centralized domain database containing user-provided records

i think crawling the root domain is an necessarily evil then

[wandrien]

i think crawling the root domain is an necessarily evil then

It's opposite for me.

Even the ZeroID database itself is not necessary to resolve the domain, so adding one more centralized entry in the system looks like bad idea. What you need to resolve a certificate into site, is certificate itself. It can be resolved not only with my resolver, but, for example, in the front-end, by the means of JS site engine. So asking the domain owner for subdomains is the most simple and reliable option.

IMO, ZeroTalk way to deal with user content dosn't scale in the long run, so I am against it being used in the domain system.

[danimesq]

Please add to the list KxoID

[wandrien]

@DaniellMesquita:

KxoID uses a different certificate registry format. We probably should ask Krixano to support the ZeroID-like one.

[danimesq]

@krixano

[Thunder33345]

Even the ZeroID database itself is not necessary to resolve the domain, so adding one more centralized entry in the system looks like bad idea. What you need to resolve a certificate into site, is certificate itself. It can be resolved not only with my resolver, but, for example, in the front-end, by the means of JS site engine. So asking the domain owner for subdomains is the most simple and reliable option.

that's what i meant in a sense it's the best option we had

wonder if krixano is interested in just making the crawler for their's id since they would be more familiar with their own system

[anoadragon453]

Would we not want to have .zeroid, .kxoid, etc? What if ZeroID and KxoID register the same domain bla.zid?

[anoadragon453]

Fwiw I do like this idea as the current DNS system relies on nofish's system staying up and publishing Namecoin blockchain changes to his zite, so it is quite brittle.

[ghost]

KxoID uses a different certificate registry format. We probably should ask Krixano to support the ZeroID-like one.

I'm wondering what I'd need to change for KxoId. I already add usernames, auth addresses, and signed certificates to the db.

[wandrien]

@krixano:

I'm wondering what I'd need to change for KxoId. I already add usernames, auth addresses, and signed certificates to the db.

ZeroID uses a key-value registry: http://127.0.0.1:43110/1iD5ZQJMNXu43w1qLB8sfdHVKppVMduGz/data/certs_1.json

Either we should support 2 different formats in the resolver or both providers should use the same.

[ghost]

Or these zites can create a config file (for example dns.json) that tells the plugin how to interpret the information.

My format is much less complicated than zeroid's, but zeroid's uses optional files. ZeroId's key is the username, and the value is the first part of the auth as well as the file in which the full certificate can be found for archived usernames. Recent ones are in one file with key as username and value as certificate.

[wandrien]

zeroid's uses optional files.

It is because when registering a new id, the front-end doesn't need the full certificate database, it only checks if that id is already registered using the shortened list in users*.json.

No doubt I can add the support of kxoid (probably I'll write the code tomorrow, if I'll have some time), but having 2 different formats in the core of the domain system is really not nice. What if soon we'll have to add 3rd and 4th?..

[danimesq]

@krixano I have some domains to send you:

krixano.bit kxoid.bit kxonet.bit

Please send me your Namecoin address.

If you don't want them now, I can keep what you don't want and manage the fees.

[ghost]

It is because when registering a new id, the front-end doesn't need the full certificate database, it only checks if that id is already registered using the shortened list in users*.json.

Well, my format would be much easier for new providers to support, and it's the simplest to think about when first writing a provider.

But, I suggest this:

Or these zites can create a config file (for example dns.json) that tells the plugin how to interpret the information.

That way providers can use whatever format they want and the plugin will just look at that dns.json file to see how to interpret the db.

[anoadragon453]

I'm slightly worried by the centralization this brings actually. What I mean by that is that if Krixano or anyone else disappears and lets their kxoid.bit domain expire, I can easily just nab it and redirect it to a malicious site which suddenly redirects all the *.*.kxoid's to other websites.

That means that this is all still dependent on the namecoin blockchain anyways, which seems a little pointless.

[purplesyringa]

I'm sorry to say that, but sounds like the only way is to make ICANN. I mean, if we don't expire the domains, one could easily squat them. Seems like manually validating all auth providers would solve this problem, though, given that .id.gitcenter doesn't look nice. (and won't work at all if Namecoin will stop being the only domain service).