Open filips123 opened 5 years ago
I'm currently creating a plugin that supports ENS. Note that it might take some time because Web3.py library currently doesn't support a new ENS contenthash
format. It needs to be supported in order to allow linking ZeroNet sites from ENS domains. See ethereum/web3.py#1397 for details.
@HelloZeroNet I also have a few questions.
In ENS, links to websites are specified in contenthash
record. It uses protocol://address
format (see this domain's content record for details).
I need to decide which protocol
name will I use for ZeroNet. This protocol
name then also needs to be added to some other packages in order to be properly supported. See this pull requests (multiformats/js-multiaddr#89, pldespaigne/content-hash#24, ensdomains/ui#13, MetaMask/metamask-extension#6869) how Onion support was added to ENS as there should be something similar for ZeroNet.
I think that zero://
protocol won't be good for this as it is already used for trackers. It would be better to use a new protocol scheme to avoid confusion. That new protocol scheme should then specifically be used to specify the address of the ZeroNet site in ENS and other domain systems. I will use zeronet://
as that protocol scheme. Do you think this is OK?
Also, as you can see in linked PRs for Onion support, I also need to specify which encoding and format should be used. What should I use for ZeroNet there?
I think it could make sense to use zeronet:// as it refers to the client name (it's also easier to search this way) and zero:// can refer to the transport protocol.
I also think that. But which encoding and format should be used (see previously linked PRs)? Base58?
Yes, it's standard bitcoin address (old-style), so it's encoded using base58
It's not necessarily my business which naming systems you want to use, but please do reach out to me if there are deficiencies in Namecoin that you perceive as relevant to a desire to use other naming systems. There's historically been an unfortunate lack of communication between ZeroNet and Namecoin (other than the quite-productive discussions that happen whenever we run into each other at conferences), and I'd definitely like to improve that situation. I can't fix issues if I don't know they exist.
It's not necessarily my business which naming systems you want to use, but please do reach out to me if there are deficiencies in Namecoin that you perceive as relevant to a desire to use other naming systems.
Personally, I'd say that it's kind of a pain to actually get some namecoins compared to, say, zilliqa or ethereum (though the fees on eth are another matter)
There should be support for more domain name systems. Some of them are more decentralised, some of them are less, but it would still be good if more would be supported.
Ideally, each system should have it's own plugin (to provide support to disable only one), but some of them may share some code. All of them should be enabled by default (to reach more users) but it should be possible to disable them.
This are some ideas I have: