I’m happy to have found this EIP; it’s an idea I was thinking should be created, and glad to see that it’s had great progress made!
As an artist and developer, I’m keenly interested in the image/SVG handling. Sounds like handling of URLs ending in
.svg is in progress but not quite implemented yet? From my experience exploring existing smart contracts that do on-chain image-generation, for
bytes returns, there’s a few ways they format the results:
The “Raw String” style would need a suffix on it in the Web3 URL, or would have to use some form of “magic bytes” processing to guess at the file format (which would likely have varying levels of success being automatic). Data-URL-formatted strings could be automatically unwound by the gateway server and have a good level of confidence in what format the output is supposed to be (for standard mediatypes). This would help many different output types, including text formats (e.g. Autoglyphs web3://0xd4e4078ca3495de5b1d4db434bebc5a986197782/draw/100)
The “Token URI” format is a special case that I’m not sure if the Web3 URL gateway wants to be able to support? In general it’s a question of if the gateway structure wants to be able to unwind JSON-structured results programmatically? If the request ends in “
/100.json”, it’s clear the request is desiring JSON as a response. But if the request ends with “
/100.svg”, but the smart contract returns a string that has a data URL prefix indicating it’s JSON, the gateway could parse the JSON, and return just the
image property of the JSON object?
Or, to be more specific, the Web3 URL format could create a specific way to indicate a specific property of a JSON result is desired? Some possible URL formats for “sending argument ‘100’ results in a string output that is JSON-encoded. Grab the ‘image’ property of that JSON object and return it, formatted as an SVG”:
That first format treats JSON files as if they were folders in a file hierarchy, which seems to fit with the other goals of this initiative?
One other thing to consider is using the
Accept HTTP header as a way to deduce the request’s intent, and also as a way to determine desired failback methods. A request that comes with a header of
Accept: image/svg+xml, application/json;q=0.9, text/html;q=0.8, */*;q=0.5
is then very clear that it desires SVG data primarily, but if the gateway cannot serve that, JSON is second-choice, followed by HTML, and it failing all that, it would accept any other format the gateway can serve. That behavior is less to do with the URL itself, so not sure if that should be part of this standard, or a different standard on gateway behavior? The “Accept HTTP Header” is usually described as part of how the
http:// schema is defined, so in that case it would fit that it should be called out in this standard that defines the
web3:// schema how it handles request headers, and not just the URL itself?
A method of string encoding that is promoted by the IPFS ecosystem (which many Ethereum projects use, but I haven’t seen any smart contracts use this style of string encoding in their output) is using a “Multibase” identifier.
Multibase as a protocol allows for specifying Base-64-encoding (“m” prefix), as well as JSON-formatted payload (Multicodec
0x0200 prefix), so could be another text format to auto-detect and parse.