-
Notifications
You must be signed in to change notification settings - Fork 325
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).
CIP-XXXX/README.md
Outdated
- [ ] 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).
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.
@rphair Yeah the files are meant to be examples of how the specification can be implemented across different transports. Other than possibly the OpenAPI one (which can be used to e.g. generate an sdk), they are meant to be for guidance in implementing the spec, so I think it makes sense for them to live in this repo, but I can also move them elsewhere if you think its best. |
@nazrhom yes, examples generally live in the CIP folder so the way you have it now is best I think. |
Hey @rphair can I also change the folder name to be CIP-0139? |
I also wanted to mention that this CIP builds on top of CIP-0116 which defines a JSON encoding for Cardano types. As part of this work we have updated CIP-0116 to include a schema for conway (as the cip predates it). We have a PR open for that and would appreciate any review and feedback on that as well |
yes please, as requested in #869 (comment) 😅 |
A transport-agnostic query layer specification for use in dApps and wallets.
See CPS-12 for motivation.
(rendered version)