RFC Proposal: Hidden Metadata via x-meta for Ethscriptions #1
Description
Currently, Ethscription-based protocols (like TIC) expose their metadata directly in the JSON payload. This makes it impossible for users to post visual or media content (like an image) as a seamless, standalone inscription while still embedding structured metadata for indexing and protocol logic.
Problem
We want to let users post Ethscriptions that look like simple, standalone media, while still allowing protocol-aware clients to read structured metadata (like a topic field) that associates the inscription with a thread, comment, or other entity.
Example: A user wants to post an image “replying” to another ethscription. The image should look like an independent ethscription, but it still needs to carry the topic reference for proper threading.
Proposed Approach
Add metadata in the parameters section of the Ethscription’s data URI, using a generic x-meta MIME parameter that stores base64-encoded JSON.
This allows hidden metadata while maintaining compatibility with any system that already renders or handles standard data URIs.
data:image/png;x-meta=<base64-json>;base64,<payload>
Example
data:image/png;x-meta=eyJwcm90b2NvbCI6IlRJQyIsInRvcGljIjoiMHgxMjMuLi4ifQ;base64,iVBORw0KGgo...
Decoded metadata:
{
"protocol": "tic",
"topic": "0x123...",
"type": "reaction"
}x-meta: a standardized parameter that can carry arbitrary JSON metadata- The JSON should always include a
protocolkey (e.g."tic") - The JSON must be base64-encoded
- Unknown parameters are ignored by compliant renderers, so the content still displays as a normal Ethscription image, video, or text
Summary
This proposal introduces a simple convention for hidden metadata in Ethscriptions:
- The metadata is stored in a
x-metaMIME parameter as base64 JSON - The JSON includes a
protocolkey (e.g.,"protocol": "TIC") - The content remains valid and visually identical to standard data URIs