rmrk-team/rmrk-spec

RIP-002: Embedded NFT content

Swader opened this issue · 4 comments

Swader commented

RIP Summary

There is currently a hard dependency on the metadata field to find out information about an NFT. This RIP proposes to add a native field to NFT entities that could hold the representative data verbatim and would make the metadata field optional. Additionally, several protocols are suggested as official types of data to be held, also upgrading the metadata field.

RIP Details

We propose adding a new data field to the Entity. The data field is to be composed of:

  • protocol (see Protocols below)
  • data
  • type (mime type)

We also propose adding the same data field to EntityMetadata.

If present in the Entity, that data takes precedence. Metadata is always secondary - on-chain information is prioritized as canonical at all times.

Protocols

Protocol Mime default Description
ipfs image/png Points to a directly interpretable resource, be it audio, video, code, or something else
http(s) image/html Points to a directly interpretable resource, be it audio, video, code, or something else (not recommended for use)
p5 application/javascript Processing.js code
js application/javascript Plain JS code
html text/html HTML code, no need for <html> and <body>, can support dependencies but it's up to the author to prevent the dependencies from disappearing
svg image/svg+xml SVG image data
bin n/a binary, directly interpretable

Examples

A binary video

data: {
  "protocol": "bin",
  "data": "AAAAIGZ0eXBpc29tAAACAGlzb21pc28yYXZjMW1wNDEAAAAIZnJlZQAQC0ttZGF0AQIUGRQmM...",
  "type": "video/mp4"
}

JavaScript

data: {
  "protocol": "js",
  "data": "alert(\"Hello World\")",
  "type": "application/javascript"
}

The above, when interpreted, should immediately pop up a "Hello World" message.

Open questions

  • what about JS dependencies in js mode? Do we support defining deps somehow, or should this be up to the developer / artist entirely?

Prior work (optional)

Inspired by ArtBlocks' ability to have code-based NFTs.

Impact

This is a major change, so a major version bump is recommended.

Implementers:

  • SHOULD prevent auto-render and auto-play of non-media resources, and in some cases of media resources, to protect end users from cross site scripting, crash attacks (malicious NFTs), and other nefarious actors.
  • SHOULD expect the mime type to be there, but if missing, default to one common for the protocol, e.g. use application/javascript is mime type is missing but protocol is js.
wheresaddie commented

for the protocols-- http(s) specifically, interpretable resource- these will be dependent on running in the browser/http or do we need to account for specific file types/openGL et all for the NFTs to successfully be parsed?

Swader commented

These are just URIs, and their type will be defined in the type as mimetype, so it should easily support everything, and the final rendering will then depend on what a browser can do (no telling where, e.g. openGL in-browser rendering might be in 10 years).

  • 👍1
wheresaddie commented

webGL is a pretty decent alternative for in-browser openGL and yes, see your point +1

Swader commented

Closed in #7