memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
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?
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
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.
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
Maybe dynamically typed JSON is sufficient? Or perhaps using JSON Schema would be simpler even if it's very verbose?
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
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.
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
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
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
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
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
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.
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
... 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.
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
Here's a little elaboration on the hex-encoded format I mentioned: https://warpcast.com/mrmemes/0xa7d75a
1 reply
0 recast
0 reaction
memes du monde 🎩 pfp
memes du monde 🎩
@mrmemes.eth
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.
0 reply
0 recast
0 reaction