I’d love to get this conversation going again! Fully onchain websites powered by ENS would be so great.
1 Like
Under the interpretation that the contenthash is “how to render my ENS as a website”:
I’m a fan of having two codecs:
(1) URL
uvarint(codec1) + <url as utf8 bytes>
(RFC-3986 might not be necessary, as the gateway or client still has to parse it, and no restrictions makes it future proof)
(2) Data URL
uvarint(codec2) + byte(length mime) + <mime bytes as ascii> + <bytes of data>
As a URL:
(1) is literal
(2) is data:$MIME;base64,${btoa($DATA)}
As a website: https://$NAME.limo/$PATH
(1) HTTP 307 + [Location: $URL/$PATH]
(2) HTTP 200 + [Content-type: $MIME, Content-Transfer-Encoding: binary] + $DATA
Note: $PATH is ignored (see below)
Note: The gateway would likely put limits on how big of a file you can serve.
.limo already supports this, but gateways should be encouraged to support ENSIP-10 and enable CCIP-Read.
Example: "https://raffy.chainbound.eth.limo"
→ contenthash("raffy.chainbound.eth")
→ evm-gateway to Base Mainnet
→ (2) text/html <html>chonk</html>
→ HTTP 307
→ see "chonk" in browser
(2) is still pretty limited as it can only host a single file but I think that’s a good start.
An IPFS contenthash allows vitalik.eth/a/b. Possible solutions:
- Reversed path components as namespace:
b.a.vitalik.eth - Resolver profile:
vitalik.eth/a/b→website("vitalik.eth", "a/b")
As I mentioned above, I plan to submit an update to ENSIP-7 which includes all the protocols with examples and links.
2 Likes
After thinking about this some more, we should clarify this part of the protocol too.
.limo and others do a good job of translating https://$NAME.limo/$PATH into httpURLFromContenthash(resolver.contenthash($NAME)) + $PATH
where $PATH is /path + ?querystring
This is not specified in ENSIP-7 nor are there examples like https://[vitalik.eth].limo/[general/2022/12/05/excited.html]
For (1) URL — the HTTP 307 should append the $PATH.
For (2) Data URL — contenthash() doesn’t have an additional parameter to supply the $PATH when the contenthash codec supports it.
Maybe? we need a third option (3) which is just <uvarint(codec3)> and this indicates that to resolve the contenthash, you call a new function: contenthash(bytes32 node, string calldata relativeURI, bytes memory context) with CCIP-Read enabled.
GET https://raffy.eth.limo/chonk?moo → contenthash("raffy.eth","/chonk?moo", bytes("http.get"))
Or instead of a placeholder contenthash, if supportsInterface(IHTTPResolver), you never call contenthash() and instead call something like http(bytes32 node, string calldata method, string calldata relativeURI).