Add Metadata and mime type to the output of /r/children/<INSCRIPTION_ID>/inscriptions

[switch-900]

Adding metadata and MIME types to /r/children/<INSCRIPTION_ID>/inscriptions can really simplify setting up and preloading content within inscriptions. Quick access to all the children's metadata makes it easier for users to search through their collections and get more out of the data. Plus, having the MIME type handy means you can preload containers and load inscriptions without the hassle of fetching and checking them every time.

[raphjaph]

The metadata is in CBOR so it's difficult to map that to a clean JSON response. That's the reason for having the seperate /r/metadata endpoint that returns the pure hex-encoded CBOR.

How does having the MIME type help preloading containers? Don't you need to go to the /content anyways to load anything?

[switch-900]

Hey, I get what you're saying. Adding metadata and MIME type to /r/children//inscriptions would make it easier to set up and preload content in inscriptions. You would instantly know what kind of content you're dealing with whether it's an image, video or something else which makes it super quick to decide how to handle or display it. Plus it could be used to help filter out what should or shouldn’t be loaded based on its type.

Optimised Preloading and Caching, knowing the MIME type in advance allows preloading based on content type. This can optimize resource loading and caching.

UI and UX Enhancements: Immediate access to the MIME type lets us generate previews or apply the right styling and processing rules on the fly.
Quick access to all the children's metadata also makes searching through collections a breeze, really getting the most out of the data.

That said, I understand that the metadata is in CBOR and converting it into clean JSON can be a bit of a pain so just server it as CBOR and we can deal with it like that. If adding metadata directly to /r/children/<INSCRIPTION_ID>/inscriptions is too tricky, maybe we could add a couple of new endpoints:
/r/children/metadata
/r/children/metadata/
This way, clients could still quickly fetch the children's metadata in neat JSON, making searching and handling the data much easier while keeping the MIME type handy for optimized container preloading.

What do you think?

[switch-900]

Yo @raphjaph what were your thoughts on this? The content type is no big issues but adding the metadata in this way could have some really good benefits for those who use metadata.

[raphjaph]

Can you give me an example of an inscription you want to write that you can't do now without this recursive endpoint?

[switch-900]

Hey Raph check out this: (skip ahead to around 10min) https://www.youtube.com/watch?v=5dArdq0BGfg this is a video of an inscription i have been working on, it helps to see the vision. Being able to pull all the childrens metadata would enable me to add markers throught the metadata so that we would only pull the relevent child in to the experience. This is obviously one example, another would be an art collection where a parent could be an art gallery and it could pull in all of its children in to the gallery and then utalise the metadata in the parent application to be displayed next to each art peice. This isn't about enabling new types of inscriptions, but rather improving efficiency for applications that work with collections containing metadata. It would reduce API calls and simplify client-side code, especially for applications that need to filter or categorise collections based on attributes.

[switch-900]

Hey Raph, what's your thoughts on this. It seems to me this would be an easy win. It would make metadata much more functional and usable.