Allow using other domain resolver plugins along with Zeroname

[wandrien]

Fixes several closely related bugs in Zeroname Plugin, those prevent correct work of other domain resolvers:

1. get(), isDomain(): when an address doesn't look like a valid domain, pass control to the next plugin in a chain.

2. Move the .bit-domain matching logic to a separate method isBitDomain().

3. get(), need(): use isBitDomain(), not isDomain() to check if domain resolving is needed in order to not interfere with other domain resolvers.

4. Also rewrite isAddress() to make it look similar to the new implementation of isDomain().

[danimesq]

It allows creating a plugin for Emercoin

[danimesq]

How it works (upcoming NameID plugin)

When accessing kaffie.zeroid, it points to the zite that haves the same identy address of user "kaffie".

How NameID's subdomain works

Simply put those records on content.json:

"domain_records": {
"blog.kaffie.zeroid": "address",
"id.kaffie.zeroid": "address",
"search.kaffie.zeroid": "address"
},

@April93
Will you use it?

[purplesyringa]

Though, it will probably be kaffie@zeroid.bit, not kaffie.zeroid.bit because it'll be a subdomain, and not kaffie.zeroid because zeroid is not a valid cert provider.

[danimesq]

@imachug

Though, it will probably be kaffie@zeroid.bit, not kaffie.zeroid.bit because it'll be a subdomain, and not kaffie.zeroid because zeroid is not a valid cert provider.

You didn't understood how NameID works

[purplesyringa]

Let me bring another example. gitcenter.kaffie. 1st, kaffie.bit is auth provider but not the site of auth provider. So somehow (how?) ZeroNet should guess it's id.kaffie.bit. 2nd, there isn't one database on KaffieID. So does it mean that NameID won't work with KaffieID?

[danimesq]

Not possible to use KaffieID, because the names aren't unique

[Thunder33345]

the using names as domain thing will be hardcoded to only support zeroid and nothing more regardless if registry is unique or not

say i have thunder33345.zeroid
how would i "point" my username to a site??
the file has to be stored on somewhere that everyone mutually agreed to be able to obtain
example would be zeroid registry, or else users still will need the raw address to connect first

we could try to conserve space the rest of the subdomain can be stored on the root domain's
but that means now if i want to visit test.thunder33345.zeroid, i also have to download my main site, effectively forcing users to download it to resolve the subdomains which probably isnt a good idea either

example: say i found a link foo.bar.zeroid
my client need to still find a site to obtain the address of foo.bar.zeroid

[HelloZeroNet]

The zeroid provider name can be anything, it doesn't have to be live site, but I think it's pretty offtopic here.

[wandrien]

Not sure why we are discussing the IDName stuff in that pull request, but...

@imachug:

Though, it will probably be kaffie@zeroid.bit, not kaffie.zeroid.bit because it'll be a subdomain, and not kaffie.zeroid because zeroid is not a valid cert provider.

The .bit suffix should be avoided, since it is related to the Namecoin address space. So kaffie.zeroid.bit is an impossible option.

kaffie@zeroid.bit could be an option, hmmm...

My first thought was to use .zeroid.bit suffixes, but I gave up that idea, as it brings ambiguity to the domain space.

not kaffie.zeroid because zeroid is not a valid cert provider.

There is no direct connection between the provider name and the top-level domain name. It should be a subject of agreement. If you recognize .zeroid domain names as provided by that specific provider, and I do the same, we can refer to those domains in unambiguous way.

@Thunder33345:

the using names as domain thing will be hardcoded to only support zeroid and nothing more regardless if registry is unique or not

Any trusted ID provider, that exports its database in a machine-readable way, can be easily supported. I see no reasons why it shouldn't be done.

say i have thunder33345.zeroid. how would i "point" my username to a site??

Your cert address is your site address. You don't have to do any additional "pointing".

but that means now if i want to visit test.thunder33345.zeroid, i also have to download my main site, effectively forcing users to download it to resolve the subdomains which probably isnt a good idea either

Do you have any other ideas, how it should be done?

[wandrien]

@imachug:

Trying to recall, why I gave up user@zeroid.bit domains too.

The .bit suffix gives the false impression, that the domain belongs to the Namecoin space and can be misleading. It is better to distinguish domain types by their last part. It's more clear for human beings and it also simplifies the code.

By the way, the current implementation of Zeroname still isn't compatible with such domains, as it uses regexp (.*?)([A-Za-z0-9_-]+\.bit)$.

What is your opinion?

[Thunder33345]

Your cert address is your site address. You don't have to do any additional "pointing".

You meant by my public address? Thunder33345@zeroid.bit (1AHEQxyRG9s6owyJHShB4U4rg9GL5FMX5K), so what about subdomain.thunder33345.zero.id???
so 1AHE... will be my root, but what about the "subdomain" is it nessarily to visit my main domain to find the subdomain(which is listed in the contents.json)?

also very offtopic but whoever come up with this, props to you wonder why we havent figure we could utilize that for a long time

maybe zero.id?
any host like xko.id, polar.id
i think using a unified TLD will make things easier when others want to integrate with their plugins
we could have either use

• .zeroid

others would have to make their own TLD for each user registry which might get messy

• .zero.id

id as TLD anyone can use (servicename).id
probably need community consensus to merge/add their own service to the plugin
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

also should we move into another issue? might be counting as issue hijacking