-
Notifications
You must be signed in to change notification settings - Fork 322
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
CIP-0139? | Universal Query Layer #869
base: master
Are you sure you want to change the base?
CIP-0139? | Universal Query Layer #869
Conversation
CIP-XXXX/README.md
Outdated
|
||
Response: | ||
|
||
- `TransactionUnspentOutput[]` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CIP-0116 defines this to include a TransactionOutput
with this schema: https://github.com/cardano-foundation/CIPs/blob/b81611632f9dcea0b87d7d96cf673a720c77e929/CIP-0116/cardano-babbage.json#L445C6-L445C23
I would like to point out that chain data APIs seemingly do not decode the datum by default, i.e. when responding with transaction outputs.
I just stumbled over this yesterday in Hydra, which uses the cardano-api
library to encode TxOut
s and that results in a decoded datum mapped to json equivalence. See also our (messy, sorry) api reference: https://hydra.family/head-protocol/unstable/api-reference/#schema-TxOut
Update README with Transports section and full list of methods
thanks @nazrhom - editors note to also tag you on discussions related to this CIP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @klntsky @nazrhom - marking Triage
so this is officially brought into the review process at next CIP meeting (https://hackmd.io/@cip-editors/100) and my vote would be that a CIP number gets assigned there.
In the meantime we have to remove the bits of the CIP template scaffolding identified below:
Thanks @rphair |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klntsky @nazrhom proposal well received & confirmed as candidate at last CIP meeting. Please remember to rename the proposal directory accordingly & update the README
link in the original posting. 🎉
one question @nazrhom ... I had assumed the .json
files here illustrative examples, but if they are implementation files (therefore likely to require maintenance beyond the CIP) the recommendation is to host them in a repository that you and/or implementors will maintain. Please confirm which category these are in (apologies if you've already done that & I missed it).
- [ ] There is at least one protocol adapter for any of the existing query layers that implements this spec, that can be run. | ||
- [ ] There is at least one offchain library that implements a provider interface for this CIP, effectively making it usable with the protocol adapter in production. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be at least two. To show actual adoption across tooling. Otherwise we rapidly end up with 10 different Universal Query Layer (cf famous XKCD I don't need to link to because everyone knows what I am referring to).
Also, given the pre-existence of well established API query layers in the ecosystem already, I would definitely consider gathering maintainers around a table to discuss this. Standardization will likely not happen unless the top players commit to it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes & please also @klntsky @nazrhom invite any potential implementors you are aware of to participate via the "table" at the CIP Discord > #query-layer-standard
(invite).
A transport-agnostic query layer specification for use in dApps and wallets.
See CPS-12 for motivation.
(rendered version)