Add support for ENS

[filips123]

I added support for Ethereum Name Service (ENS). This is part of #2049.

The plugin first tries to connect to different local and public Ethereum providers. It takes the first working provider from each category. When a domain is requested, it tries to resolve it with all providers.

It will first use the result from cache (if available and not outdated). Then will try result from the first available provider (and update cache). If no provider gets a result, the domain does not exist and 404 is returned. If a domain is in the cache (but outdated) and the provider has an error, it will use a value from the cache.

Supported networks:

1. Local providers
2. Mainnet
3. Ropsten
4. Rinkeby
5. Goerli

Note that Web3.py requires Python 3.6 while ZeroNet also supports Python 3.4 so users of old Python version probably won't be able to use ZeroNet unless they disable this plugin. CI will also fail because of this on Python 3.4 and 3.5 tests.

Also, Web3.py is defined as an additional dependency in plugin's requirements.txt and it needs to be installed manually. Also, some missing Python wheels can be installed (if needed) from here. Ideally, all additional requirements should be bundled in ZeroBundle. CI currently fails because of this because web3 module is not installed.

Also, this depends on ethereum/web3.py#1396 and ethereum/web3.py#1411. Until then, my temporary patch can be used for testing.

[purplesyringa]

Please add web3 to root requirements.txt.

@HelloZeroNet I'm not sure what's ZeroNet's policy on plugin requirements. I'd recommend either making such plugins disabled by default (adding a runtime check for requirement existence) or adding the requirements to root requirements.txt.

[HelloZeroNet]

The problem is the web3 package has tons of requirements (23MB in total) and the binary dependencies does not have compiled modules for windows (or other platforms). So adding to the root requirements is not really a good idea.
So it should be disabled by default and I also recommend to add a check for web3 package in init.py to avoid startup errors if the package is not avalible

[filips123]

@HelloZeroNet What if plugin loader would check if plugin needs additional dependencies from requirements.txt file and if that dependencies are installed and not load plugin if they aren't.

Also, that binary dependencies are problem but it can be partially solved with installing them from thrid-party (which I linked in earlier comment).

For dependencies size, this could maybe be solved with special lightweight version of Web3.py which would contain only parts required by ENS. But I'm not sure how much benefit would be from that and this is also very hard to do.

[rllola]

Should it really be added to the repo ? Should the repo be only restricted to what is required so we can keep this as small as possible ?

[filips123]

@rllola I don't know. But ENS support, as well as support for other DNS systems, could be one of the main parts of ZeroNet in the future. So they should probably be enabled by default.

Also, the repository already contains some plugins that are not really required, but still useful. And if ENS plugin is only installed, but not enabled, it doesn't need installed dependencies so size could be small.

---

Solution for this could be to store plugins in different repositories (except for low-level networking and other strictly required plugins) and automatically install them on the first startup. This could also be integrated with the new plugin management system. This would still support all features, but keep repository small.

[purplesyringa]

Solution for this could be to store plugins in different repositories (except for low-level networking and other strictly required plugins) and automatically install them on the first startup. This could also be integrated with the new plugin management system. This would still support all features, but keep repository small.

💯 This sounds like implementing PyPI in ZeroNet!

[filips123]

@imachug Yes, something like this. And it could maybe even use some parts of PIP and PyPI for this.

[rllola]

I am more for a plugin store. I also believe some plugins should be removed. Some are not up-to-date and can be unsafe to use.

Also your plugin use third-party providers like infura. Could you code something like for Zeroname ? You register all the Zeronet addresses registered in a merger site ?

[filips123]

@rllola

I am more for a plugin store. I also believe some plugins should be removed. Some are not up-to-date and can be unsafe to use.

I agree with that, but this could be a complicated process so it should be done later in (near) future. Until then, this and other important plugins (PeerMessage, BackgroundProcessing) should probably be merged into the repository.

Also your plugin use third-party providers like infura. Could you code something like for Zeroname ? You register all the Zeronet addressed registered in a merger site ?

Using Infura (or local RPC/IPC provider if available) is the only easy option. Also, users can use their own ETH node with ZeroNet which is the most decentralized way available. Alternatively, if they don't trust Infura, they can also specify other providers.

Also, how should that Zeroname-like site look like? If it would be like Zeroname, the owner of that site would have full access to modify or delete all domains so it would be again centralized.

[rllola]

Until then, this and other important plugins (PeerMessage, BackgroundProcessing) should probably be merged into the repository.

I don't use them. Is there people using those plugins ? Why the rush to have them in the repo ? Would it not be better to take the time and wait to have it done properly instead ?

Using Infura (or local RPC/IPC provider if available) is the only easy option. Also, users can use their own ETH node with ZeroNet which is the most decentralized way available. Alternatively, if they don't trust Infura, they can also specify other providers.

If it is the only option to have a third-party is it really worth it ? People are already not using Namecoin node to resolve .bit and it easier to have it work than Ethereum. I don't even think people are using the SPV node with it even if it compatible now.

Also, how should that Zeroname-like site look like? If it would be like Zeroname, the owner of that site would have full access to modify or delete all domains so it would be again centralized.

Yeah that's how it works for .bit domain name and people are a bit pissed about that. It is still censorship resistant but it is like every site... the owner can modify the content.

The latest might be better than giving away your information to a third-party ? And if people don't trust it they can have their own node ? I would say add SPV support but is it possible with Ethereum ?

[filips123]

I don't use them. Is there people using those plugins ?

PeerMessage plugin is really useful and it is already used by some big sites, like KxoID and other real-time communication sites. @imachug can probably give you more examples of usage and details about it.

If it is the only option to have a third-party is it really worth it ? People are already not using Namecoin node to resolve .bit and it easier to have it work than Ethereum.

People may already have full-node Ethereum wallet installed, which can be used with this plugin.

Yeah that's how it works for .bit domain name and people are a bit pissed about that.

Some users don't like this because @HelloZeroNet has whole control for it and some already proposed to move to something else. So using it also for ETH wouldn't be really step-forward. It would be better to sue some other solution.

And if people don't trust it they can have their own node ?

Yes, the local node is used if available. But if not, it currently uses Infura.

[rllola]

PeerMessage plugin is really useful and it is already used by some big sites, like KxoID and other real-time communication sites. @imachug can probably give you more examples of usage and details about it.

Happy to see new stuff!

Some users don't like this because @HelloZeroNet has whole control for it and some already proposed to move to something else. So using it also for ETH wouldn't be really step-forward. It would be better to sue some other solution.

Your plugin doesn't fix it instead your are using a third party by default which can be censored, is centralized and can collect data. And you will be confronted to the same problem as the plugin to use Namecoin full node or SPV already exist but people don't use it because they don't know how to or has too much steps. The optimal approach would be to have SPV protocol inside the plugin but I don't think it is possible with Ethereum. It will come for namecoin soon hopefully if someone feels like coding it 😄

Having to use a third-party feels like a step-backward. It should not be the default. And also are you not using DNS server to resolve infuria domain name too ?

[purplesyringa]

Until then, this and other important plugins (PeerMessage, BackgroundProcessing) should probably be merged into the repository.

Adding PeerMessage might be a good idea (check how many threads saying "Why KxoID doesn't work" are there on ZeroTalk), but BackgroundProcessing is something I'm still worried about -- it might be better to avoid it for now as we have plugins.

Happy to see new stuff!

Now, PeerMessage is the only way to send messages between peers faster than one per 30 seconds. That's it. Whatever you want to make --a chat, a blockchain (ehh), a federated client-server architecture (I don't know whether it has a name; basically, it's when a client connects to several servers instead of a single one, or to a random server, something liek that), etc.

[filips123]

@imachug I just got one idea. Could PeerMessage be used for decentralized ENS support that would work something like KxoID.

[github-zeronet]

I like the goal of this plugin.

As a user, I'd like to see descriptions for plug-ins. If it will clearnet, that needs to be clear before a user enables it. Ideally, a list of user-configurable sites it communicates with.

[filips123]

How to register ZeroNet ENS domain

Using ENS Manager website

This is not available until ensdomains/ui#23 is merged and released!

1. Open ENS Manager website.

2. Buy domain if you don't have it already.

3. Make sure that your domain is using public resolver with support for EIP 1577.

4. Under records section, click + button. Set record type to "content". Set record value to zeronet://YOUR-SITE-ADDRESS.

5. Save changes and wait until the transaction is confirmed.

6. Your website should be accessible from http://127.0.0.1:43110/your-domain.eth.

Using Web3.py library

This is a temporary workaround until ENS Manager is supported.

1. Clone filips123/web3.py@patch-for-zeronet and go into it:

git clone https://github.com/filips123/web3.py.git --branch patch-for-zeronet
cd web3.py

2. Install Web3.py dependencies as specified here.

3. Run this Python script (and edit it before) from the environment where you have dependencies installed:

import web3 import IPCProvider, HTTPProvider
from ens import ENS

# Connect to your Web3 provider
# Chose only one of the providers and edit it with connection details
provider = HTTPProvider('http://127.0.0.1:8545')
provider = IPCProvider("~/Library/Ethereum/geth.ipc")

# Create ENS connection
ns = ENS(provider)

# Set up content hash
# Make sure that your domain is using EIP 1577 compatible resolver
content = {
    'type': 'zeronet',
    'hash': 'YOUR-SITE-ADDRESS',
}
ns.setup_content('your-domain.eth', content)

4. Your website should be accessible from http://127.0.0.1:43110/your-domain.eth.

---

This should be steps to register ZeroNet ENS domain. However, I haven't completely tested them yet, so please don't do them on mainnet to avoid losing ETH with a gas fee in case if you need to change things multiple times.

[d14na]

This is a temporary workaround until ENS Manager is supported.

oh wow! @filips123 ur the man. will try this over the weekend

[filips123]

I updated this plugin with most things that have already been added to DNS plugin. I also added plugin dependency installation to CI, but there are still some problems.

• Python 3.4 and 3.5 tests are failing because Web3.py is compatible only with Python 3.6+.

• Python 3.8 tests are failing because cytoolz is currently not compatible with Python 3.8 (Fails to build on Python 3.8 pytoolz/cytoolz#136). Update: Fixed.

• But I don't know why did Python 3.6 and 3.7 (update: and 3.8) tests fail. @HelloZeroNet @imachug Do you know what is this and how to fix it? I found Segmentation fault in running tests on TravisCI pysal/splot#47. From CI log, I can see:

src/Test/TestConnectionServer.py::TestConnection::testPing[ipv4] /home/travis/.travis/functions: line 109:  4666 Aborted                 (core dumped) python -m pytest src/Test --cov=src --cov-config src/Test/coverage.ini
The command "python -m pytest src/Test --cov=src --cov-config src/Test/coverage.ini" exited with 134.

Because of that, I also didn't bundle dependencies along with source code yet.

[purplesyringa]

@filips123 is that the only blocking problem?

[filips123]

Few of problems are lack of Python 3.4 and 3.5 support (if this actually is a problem...) and that CI failures.

Another problems are relying on centralized Ethereum nodes (if user does not have local node) and quite heavy dependencies. But this can't be really easily fixed and are maybe not so important...

[filips123]

I added strace to failed command to Travis CI build.

Complete strace output, of Python 3.7 build, is here. I also formatted last error traceback from strace output which is here.

It appears that problems are caused in gevent, urllib3 and ssl modules. But I don't know what exactly it is.