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
It would be helpful to make TX ID a parameter for returning metadata as well as slot+tx_id as a filter.
Why is it a good idea?
Transaction ID is known before hand where slot isn't. Consumers working based on transaction IDs can retrieve the metadata without also having to work out the slot when their transaction landed.
What is the current alternative and why is it not good enough?
Currently we need slot number and transaction ID for filtering which means even if the transaction ID is known and would only return one metadata field anyway, slot ID is always needed.
The text was updated successfully, but these errors were encountered:
Transaction ID is known before hand where slot isn't.
It depends by who 😉. Kupo doesn't know your transaction id beforehand, but it does know slots.
This is something I already thought of actually as a possible API. The only downside would be that Kupo would only be able to fetch metadata of transaction that it has indexed (more specifically, outputs of the said transaction). That is maybe not too big of a limitation after all.
That is maybe not too big of a limitation after all.
It'd be great it it's not such a big limitation; e.g. maybe there's a suitably graceful API response.
Maybe others are using a similar approach where they know the tag they're indexing on and the Tx IDs that they're posting with that tag for near real-time access to the metadata.
Rn. It's also not such a big deal to do this with the two API calls just a bit slower.
What is your idea? Provide a use case.
It would be helpful to make TX ID a parameter for returning metadata as well as slot+tx_id as a filter.
Why is it a good idea?
Transaction ID is known before hand where slot isn't. Consumers working based on transaction IDs can retrieve the metadata without also having to work out the slot when their transaction landed.
What is the current alternative and why is it not good enough?
Currently we need slot number and transaction ID for filtering which means even if the transaction ID is known and would only return one metadata field anyway, slot ID is always needed.
The text was updated successfully, but these errors were encountered: