-
Notifications
You must be signed in to change notification settings - Fork 328
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-0107? | URI Scheme - Block and transaction objects #635
CIP-0107? | URI Scheme - Block and transaction objects #635
Conversation
This CIP extends CIP-0013 with two new authorities, and enabling a simple and canonical reference to 5 new objects or locations on the Cardano blockchain
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.
@Quantumplation I am really happy to see this presented, especially with concurrent discussion of #625 highlighting that objects should be possible to reference independently of query providers (cc @klntsky).
@Quantumplation on agenda for quick Triage assessment in next CIP meeting on 12 December, if you can make it (this is our last CIP meeting for 4 weeks): https://hackmd.io/@cip-editors/78 |
Co-authored-by: Robert Phair <[email protected]>
@rphair I am planning on being there for the CIP-0100 approval 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.
This looks great, easy, and clear to me at first reading. See no reason why it should not be adopted. :)
Co-authored-by: Adam Dean <[email protected]>
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.
@Quantumplation you are all set to rename the directory to CIP-0107
and update your "Rendered" link accordingly 🎉 ...
Done and Done. |
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.
@Quantumplation given that a new span of URI protocols + a containing CPS (#841) are now moving ahead together, I would happily approve & merge this as soon as we settle the question about whether & how the ?height=
query is used as per currently unresolved discussions:
#635 (comment)
#635 (comment)
I would prefer a consensus to keep height=
in the syntax, despite its lack of cryptographic certainty, since I believe it would likely be a popular choice when this URI syntax becomes more generally adopted.
Specifically, I would not want to be the one to be explain to members of the public why they couldn't use it (in historical and/or governance contexts as I argued for in #635 (comment)) when it is meaningful for a far greater time span (in hindsight, forever) than its period of uncertainty (contemporary with its creation).
In any case as soon as there is a consensus about height=
, and the CIP is updated according to that consensus, I'm ready to approve this. Adding to CIP meeting 9 days from now (https://hackmd.io/@cip-editors/91) to make sure this is progressed & maybe even merge if the way is cleared in the ensuring discussion here. cc @Crypto2099
CIP-0107/README.md
Outdated
|
||
Examples: | ||
``` | ||
web+cardano://block/c6a8976125193dfae11551c5e80a217403d953c08ebbd69bba904d990854011f |
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.
(1 of 2) If height=
is preserved in the query part of the URI syntax documented below, an example should be added here.
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.
p.s. should be considered along with @Crypto2099's #635 (comment).
|
||
``` | ||
blockref = "//block" query | ||
query = ( "?block=" block_hash | "?height=" block_height) |
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.
(2 of 2) If height=
is eliminated due to reservations about immutability (as per the previous & current discussion), it should be removed here.
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.
@Quantumplation revisiting this CIP was favourable at the editors' meeting tonight & we're looking forward to merging as soon as @Crypto2099 commits final adjustments including resolving the dialogue above (I'm ready to approve it after those update(s)).
Per last meeting (# 91), expecting some final updates to this PR & likely merge by next meeting, so marking |
In the pull request, it is probably a good idea to update the reference to this proposal within CIP-100 - here. |
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 am happy to see this one FINALLY get merged if @Quantumplation can take a quick glance at the last outstanding/remaining issues (examples and minor cross-linking suggestions).
Co-authored-by: Ryan <[email protected]>
Co-authored-by: Adam Dean <[email protected]>
@Crypto2099 I just applied the two suggestions; were there others you were thinking of? I haven't been able to keep up with this super well. |
Looks like everything outstanding/pending has been resolved so I think this one is ready to merge IMO @Ryun1 @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.
Thanks @Crypto2099 @Quantumplation for pushing this one through. 👏
This CIP extends CIP-0013 with two new authorities, and enabling a simple and canonical reference to 5 new objects or locations on the Cardano blockchain.
In particular, this will be useful in CIP-100, where we want to allow users to make references to on-chain transactions, blocks, and metadata, or store the transaction metadata within the same transaction.
Rendered