I'm late to the party, but ethscriptions are really interesting. The possibility of having "contractless" functionality is the thing that really captures my imagination... it seems like you need not just data, but a way to describe its schema. Anyone working on this?

co-founder @chaindrop § software engineer § privacy wonk § music head § theoretical memeticist

Maybe dynamically typed JSON is sufficient? Or perhaps using JSON Schema would be simpler even if it's very verbose?

ultimately, what I'd like is that if "the application" lives off-chain while "the data" lives on-chain, applications should be able to introspect the data to know whether they can operate on it. This would allow standards to emerge.

You could definitely get that through structured JSON and it seems like some usages of ethscriptions are going down this path currently. Unfortunately, this means that you can't really have portions of your application on-chain though, since reading JSON from any EVM-compatible language would be prohibitively expensive

I'm seeing a lot of plain text ethscriptions coming through... currently there are a number that look like this: https://ethscriptions.com/ethscriptions/0xcc14844ea6b93e1ec40f552f4c71f6ef9b9263d39aaca3f44a809f27970e65d0

This format: `data:,1320.ethmap` which is just the data uri representation of the plain text "1320.ethmap". Riffing on this idea, one possible path forward would be to inject custom mime types for your protocol implementation, e.g. `data:myprotocol,<data>`... this would disambiguate compatible ethscriptions.

... that way your protocol contract could say: "okay, this ethscription is in my data format and I expect the bytes of the body to be in this format"... keeps the data on-chain and lets the schema be defined in a contract, in a format that's de-serializable on-chain as well.

Here's a little elaboration on the hex-encoded format I mentioned:

Here's a little elaboration on the hex-encoded format I mentioned: https://warpcast.com/mrmemes/0xa7d75a

I'm not convinced this is the right way, but as evidenced here, I'm very interested in figuring out where the dividing line between data, schema and application can be placed and how much of that makes sense to store on-chain in an inscribed transaction scenario.

I've been playing with hex-encoding data using a brief front matter that takes inspiration from the Foundry approach to ABI encoding, but by the time you encode the body to hex, append `data:application/octet-stream,` and then convert that all to hex, it ends up being pretty lengthy.