Closed casey closed 1 year ago
interesting. are you imagining that this would be an extra metadata field in the envelope header?
@rot13maxi Yah, that's right.
One complication is that the envelope header expects only single data pushes for field values, and a single data push is limited by taproot to 520 bytes, so by default it would be impossible to create titles longer than 520 bytes. This is probably fine, since 520 characters for a title seems like plenty.
Could you use the filename as the title?
Then, if someone downloads the image, it could have same filename as original upload.
eg. foo.png --> title = "foo" --> someone downloads image on ordinals.com and filename is "foo.png"
@batcavekid The filename might be something random or weird, and people might not realize that they're including it in an inscription. The title might also contain spaces, slashes, or other special characters that you don't want in filenames.
- An inscription can include an additional field in the envelope header called the "title"
- The value of this field should be UTF-8 encoded text
- The title is displayed below the inscription on the /inscription page
In addition to titles, I'm thinking of using this for #943. It's really common for NFT standards to allow for machine readable metadata that contains things like traits and rarity. If we allow multiple inscriptions on the same sat, you can put the inscription proper in the first inscription, and then put the traits and other metadata in a second inscription with the title
metadata
with typeapplication/json
. Block explorers can then look for this additional inscription and use its contents as metadata.We could also consider using a different field for #943. As an alternative, we could have a "name" field, and have it be different than a "title". Title might be for human readable titles, and "name" could be more like a filename. This would also allow giving inscriptions nice filenames when downloaded.
Wait, so is this already implemented? any example of how to do this?
If unimplemented, please support it 🚀
I think this is covered by metadata.
In addition to titles, I'm thinking of using this for #943. It's really common for NFT standards to allow for machine readable metadata that contains things like traits and rarity. If we allow multiple inscriptions on the same sat, you can put the inscription proper in the first inscription, and then put the traits and other metadata in a second inscription with the title
metadata
with typeapplication/json
. Block explorers can then look for this additional inscription and use its contents as metadata.We could also consider using a different field for #943. As an alternative, we could have a "name" field, and have it be different than a "title". Title might be for human readable titles, and "name" could be more like a filename. This would also allow giving inscriptions nice filenames when downloaded.