saving metadata natively inside inscriptions

[WinkyDev]

Thats an implementation of the Provenance problem that Casey has referred to in his blog. Pretty easy practice, by leveraging the native metadata of media files and documents, we can store metadata natively on the files without breaking the existing explorers and by keeping the original intent of inscriptions.

I and my company built a tool (https://digital-artifacts.io) for the community that attaches metadata to files that everyone in the community can use. basically, we are following the Exif format of metadata into images and embedding the "extra" metadata inside the "comments" bytes in a JSON format. That can be done for every media file and document file (with slight adjustments). Then the interpreter can extract that data and index it correctly. That opens multiple use cases:

1. Inscriptions Search engine
2. Authenticating (can be used by signing a message using the wallet and embedding it into the metadata).
3. Bridging the Web3.js ecosystem by adding signed messages into the file. bridging the gap between an Eth wallet address with its owned Inscription.
4. Automatic set-in collections
5. Enable royalties or other traits embedded based on the data stored in the inscriptions.

we created an explorer where you can see the file's metadata and already inscribed the first Inscription with metadata. https://digital-artifacts.io/explorer/fae44f24f33853dcc5dbff869992cfd5a7a1d21057634316fd13b8f513a639c3i0

We want to help make this change accessible directly from the Ordinals code. As it currently supports only :apng asc flac gif glb html jpg json mp3 mp4 pdf png stl svg txt wav webm webp yaml. We can create a standard for saving metadata on those files in a pretty straightforward way.

Lmk what you think! Best, Adir Buskila, Founder of Digital-Artifacts.io

[satoshi0770]

One issue i see is someone randomly adding metadata to their inscription saying its part of another collection or is done by another artist. This can be spam attacked thus causing any queries to be useless.

[roadbuilder]

I had thought of using EXIF data too, but it is more intensive to encode and extract; what I think should be done is to just have multiple files in the same inscription by setting the mime type to multipart/mixed; that way the images don't need to be tampered with, and can just put the metadata.json right after the image or audio, etc: https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

[WinkyDev]

One issue i see is someone randomly adding metadata to their inscription saying its part of another collection or is done by another artist. This can be spam attacked thus causing any queries to be useless.

We need to add signed message in the metadata to authenticate what ever we want(can be the collection owner signature or artist signature). That can be validated and can't be fake. That can also be a gas-free bridge into the web3.js ecosystem (which is already adopted) attaching signatures from other types of wallets(or blockchains). Long sorry short your concerns can be eliminated using signed messages

[WinkyDev]

I had thought of using EXIF data too, but it is more intensive to encode and extract; what I think should be done is to just have multiple files in the same inscription by setting the mime type to multipart/mixed; that way the images don't need to be tampered with, and can just put the metadata.json right after the image or audio, etc: https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

That's an interesting thought. You can also split it into 2 inscriptions:

1. With the media file
2. With the metadata that points to the media file.

That's very interesting because I was debating myself around that q "what will serve digital artifacts more?" And once I saw what happened with PDF files I understood that every file type has a different approach. But it's actually a game of hierarchy: Theory 1: If the metadata is an inscription itself(or a separate file), maybe we don't need to host the file itself on the Bitcoin Blockchain, and the metadata will be enough - and that is starting to look like ERC721 to me.

Or

Theory 2(which is what I believe the purpose of inscriptions): A metadata is a bye product of the file, and must be attached natively into it in order to exist on the highest standard. Even if you download the file, or use it anywhere, you will still have that metadata transparently following you embedded in the file. In the future imagine "blue tick" on Spotify songs that were downloaded from the Blockchain, or the artist icon on videos. It's kinda the same as separate files but it doesn't, because you must have the file as an Inscription, and then attach the metadata to him respectfully using the file format. You cant settle for just the metadata+ IPFS like what happened on erc721.

Although maybe if you are sending them both using the multipart/mixed might be enough. But for me I understand that Digital Artifacts is [file first->then metadata], and not [file1(content),file2( metadata)].

[tyjvazum]

I like the concept of a metadata field using JSON, but I think the approaches discussed so far are quite complicated compared to simply defining a metadata tag in the existing transaction structure. This is how the content_type and body tags are currently implemented, which encode the MIME type and file bytes respectively. I suggest making a PR to add this field using tag number 3, since even tag numbers are intended to break backward compatibility, and this is something that can be ignored by older clients.

[WinkyDev]

Continuing this conversation in case 783 https://github.com/casey/ord/issues/783

[nammaki]

Some sort of default metadata support would be amazing 🤩