Skip to content

Conversation

@nand2
Copy link
Contributor

@nand2 nand2 commented Oct 13, 2023

Hi!
Ok here is a PR where I extracted the web3:// execution engine, put it on https://github.com/web3-protocol/web3protocol-go and then reuse it on the gateway project.

Here are some things:

  • The conf is slightly changed, mainly all chain ids which were strings are now integers.
  • SimpleNameService : I did not find anything about that so I dropped it, but is it still something actively supported, and if yes, can you show me what it is?
  • Tests: I have worked on making them work all. Some comments:
    • I have removed some which were internal to the protocol (e.g. auto mode arg parsing)
    • Non-standard ERC-4804, with hosts such as "/concat.w3q->(string)/" : I have disabled
    • The package now use a up-to-date go-ethereum dependency, and they recently are now using "input" instead of "data" in the JSON-RPC call (apparently "data" was kind of supported but was not the standard). Cf ethclient: use 'input', not 'data' as field for transaction input ethereum/go-ethereum#28078 As a consequence, several tests to blockchains ids 1666600000, 1666700000, 100001, 1088, 599, 84531 fails because their RPCs does not recognize "data". Commented.
    • Tests to chain 110001 are timeout-ing, commented.

Lastly, I haven't supported yet the ?mime.type= and .mime.content= flags, will do so soon after, will be quick.

But first, do you have comments on the PR as it is now?

Regarding /concat.w3q->(string) URLs, if you still want to support them, I can do a bit a code to translate them in proper web3:// URLs before feeding them to the new engine.

@qizhou qizhou requested review from qzhodl and syntrust October 16, 2023 00:49
}

// Setup name address cache to 10 minutes, hardocded
web3pConfig.NameAddrCacheDurationInMinutes = 10
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we want to hardcode the cache duration?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess not :) I just copy/pasted the existing hardcoded value from main.go:139
I will add an option to be loaded from the config file.

return "", false, fmt.Errorf("invalid subdomain")
}
full := strings.Join(pieces[0:2], ":")
name := pieces[0]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar logic shows multiple times, we may consider to wrap it as an internal function

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I'll see if I can cleanup handleSubdomain() a bit

@qzhodl
Copy link

qzhodl commented Oct 16, 2023

  • SimpleNameService : I did not find anything about that so I dropped it, but is it still something actively supported, and if yes, can you show me what it is?

Seems no dApps are using the SimpleNameService right now. SimpleNameService was a simple name service used by chainId 3333. So I think we can remove that from the gateway.

@qzhodl
Copy link

qzhodl commented Oct 16, 2023

Regarding /concat.w3q->(string) URLs, if you still want to support them, I can do a bit a code to translate them in proper web3:// URLs before feeding them to the new engine

If what you mean is the old return way for "->" instead of "returns", there is only one dApp "W3Blog" which is using it. We can definitely change the code of W3Blog to deprecate this old calling version.

@nand2
Copy link
Contributor Author

nand2 commented Oct 18, 2023

Regarding /concat.w3q->(string) URLs, if you still want to support them, I can do a bit a code to translate them in proper web3:// URLs before feeding them to the new engine

If what you mean is the old return way for "->" instead of "returns", there is only one dApp "W3Blog" which is using it. We can definitely change the code of W3Blog to deprecate this old calling version.

Ok! And Qi Zhou is also voting on removing support for this old calling version, so I'll remove the commented tests.

@nand2
Copy link
Contributor Author

nand2 commented Oct 18, 2023

Ok I have used the cacheDurationMinutes flag, removed some commented tests for the old format (e.g. /concat.w3q->(string)), and factorized a bit with hostChangeChainShortNameToId.

It still remains for me to add support for the extra ERC ?mime.type= and mime.content= flags.

@syntrust
Copy link
Collaborator

Hi Nand,

This is really a considerable amount of change with many details that must have taken a lot of effort, especially since you have to go over the test cases one by one. And I can see a lot of improvements have been made such as making chainId integers, upgrading go-ethereum dependency, and some deprecations, etc., which I believe are the right things to do.
However, I may need some big picture about the split, like the principal about which parts are moved to the engine and which are left. I suppose those rules defined in EIPs are engine parts in general? Do you have any details to add? Any changes of logic made to the engine part in the new repo? Is there any other example that uses the engine?

// {100001, "0xc2f21F8F573Ab93477E23c4aBB363e66AE11Bac5.w3qkc.io", "/greet?returns=(string)", "[\"Hello QKC\"]", http.StatusOK},
// {100001, "w3qkc.io", "/0xc2f21F8F573Ab93477E23c4aBB363e66AE11Bac5/greet?returns=(string)", "[\"Hello QKC\"]", http.StatusOK},
// }

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we support the cases of subdomain like in line 267, 269, etc?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, I have commented them temporarily and forgot about them. I just made them work.

@nand2
Copy link
Contributor Author

nand2 commented Oct 26, 2023

Hi!

Thanks, yes sorry I guess I should have added more details!
So, yes the main idea is to separate the code executing the web3:// URL itself as defined in the EIPs, from the rest.
The "engine" interface is (via the function client.FetchUrl) :

  • Input: URL string
  • Output: output bytes, HTTP headers, HTTP status code

What remains in web3url-gateway is the http server itself, the gateway URL to web3:// URL translation (mostly done via the handleSubdomain function), the non-web3:// elements (BTC ordinal support), stats gathering and config support.

Coming back to the engine (web3protocol-go), I have taken the code from the gateway, and reworked it so that the 3 main execution steps are separated, in a way that can be easily tested :

  1. URL parsing : determine what needs to be called (that includes resolve mode checking and domain name resolution)
  2. Main contract call
  3. Post processing of the data returned by the main contract
    The other implementation in javascript use a very similar approach.

The tests at https://github.com/web3-protocol/web3protocol-tests have been put in toml files, and are made to be used by various implementations : this golang implementation, and very soon https://github.com/web3-protocol/web3protocol-js

Other place using this golang engine : right now only the tests (https://github.com/web3-protocol/web3protocol-go/blob/main/web3protocol_test.go ), I'll add a curl-like app soon. The javascript engine is used by a curl-like app and the EVM browser My hope is that others apps wanting to read web3:// URLs will either use this golang engine, or the JS version.

Changes of logic : there are very slight changes, it aims at supporting ERC-6860, the ERC that Qi Zhou and I are working on which clarifies and formalize ERC-4804 and make the following changes:

  • On auto mode, integers returned (via ?returns=(int)) are no longer returned as integer string ("200") but as hex strinbg ("0xc8")
    It also adds:
  • On auto mode, support for all solidity types
    I have also corrected tiny bugs here and there, and added more checks, otherwise things should work as it used to work.

…se the default one from the golang http server.
@nand2
Copy link
Contributor Author

nand2 commented Oct 26, 2023

Ok I just made all tests pass by adding the ERC-7087 mime.type/mime.config support ; also corrected the way multiple ?returns args is supposed to be handled (the last one should be taken, instead of returning an error).

@qzhodl qzhodl mentioned this pull request Nov 6, 2023
@qzhodl
Copy link

qzhodl commented Nov 6, 2023

Too much changes are involved, I think it will be great to setup a gateway in the server to test the existing websites to see if they are broken, @syntrust

@syntrust
Copy link
Collaborator

syntrust commented Nov 6, 2023

Too much changes are involved, I think it will be great to setup a gateway in the server to test the existing websites to see if they are broken, @syntrust

Yes before merging to the main branch, I may need some time to deploy the branch to a test server for a sanity test in case there are any broken links, especially for the web pages deployed in the early days.
@nand2 @qzhodl

@nand2
Copy link
Contributor Author

nand2 commented Dec 15, 2023

The last commit bump the web3protocol-go to v0.1.0, which add tiny changes (one being support of tuples in ?return=).

@syntrust
Copy link
Collaborator

syntrust commented Jan 2, 2024

This PR has been deployed to a test server for a bunch of sanity tests. The tests cover ethstorage.io (https://eth-store.w3eth.io/#/) and all links and dApps on https://w3url.w3eth.io/ (w3link.io) . All works well except links like

https://web3q.io/file.w3q/0x6d4a199f603b084a2f1761dc9f322f92e68bfd5e/demo.png

where

  1. web3q.io will no longer supported so we need to replace it with w3link.io
  2. the "path" format should be replaced with subdomain format

We may need to make some changes to dApps (qrobot, w3box, etc. ) using this kind of link.

@syntrust
Copy link
Collaborator

syntrust commented Jan 2, 2024

@syntrust syntrust merged commit b763014 into ethstorage:main Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants