Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
switch-900 opened this issue Feb 11, 2025 · 2 comments

Comments

@switch-900
Copy link

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
Copy link
Collaborator

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
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants