You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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.
The text was updated successfully, but these errors were encountered: