ord
ord copied to clipboard
ordinals
Can using /r/inscription/ return the parent ID?
I found discussions about obtaining the parent ID in #2628 and #3015, but it seems like the issue hasn't been resolved. Even with the latest
/r/inscription/:inscription_id,
there's no way to retrieve the parent ID. Will there be any recursive endpoints added for this in the future?
Hi, just adding to the pro-parent discussion here.
The endpoint children is as useful for collections as parents would be for collabs. But I get that collections dominate the ordinals landscape. But from a neutral standpoint, If parent-child is THE provenance method, then parents should be as easily acessible as children . Actually doubly so, if provenance-proving is the aim. Currently, if I want to check that Mama is Baby's parent (aka prove Baby's provenance) I have to 1. Know Mama's ID (so, I'm already assuming she's a parent) and then 2. check the entire array of Mama's children and see if Baby's inscriptionID is in that array...
So, strictly speaking there is actually no way to "discover" provenance. Only descendance.
If I'm missing something obvious, which happens often, please lmk and sorry. Thanks in advance
Yes, we should add that
Great! If not too much, could you elaborate, pls? Just so I can adjust expectations :) Thanks!
Hi, can I piggyback this to request that "address" also be added? Currently I think "parents" and "address" are the only two bits of info present in the /inscription page data but missing from /r/inscription. They would both be very useful for all kinds of recursive wizardry but also it just makes sense to make everything available where possible. Thanks :)
Hi, can I piggyback this to request that "address" also be added? Currently I think "parents" and "address" are the only two bits of info present in the /inscription page data but missing from /r/inscription. They would both be very useful for all kinds of recursive wizardry but also it just makes sense to make everything available where possible. Thanks :)
Hi, ZZ. While I agree that both address and parents "being already there" should make both accessible via recursion, there are apparently concerns associated with making "address" accessible via recursion. I have seen none of those concerns raised by the Ord people when talking "parents".
So, if you want to start another Issue for "address" I'd be happy to give a thumbs up there. But I still think these are 2 different issues. I mean, this one's called "return the PARENT ID"
Thanks, mate. And lmk if you open the "address" issue :)
Thanks. There is some discussion here https://github.com/ordinals/ord/pull/2628 but I feel like I'm missing half the conversation. The address appears to have been deliberately removed from @devords's PR and there are some references to address reuse concerns but it doesn't seem very clear. Most people appear to be in support of address being added. Do you think it's best I just open a new address issue to try to figure out what happened? Thanks
I'm your mirror image, ZZ. That is the discussion I was referencing when I said I noticed some "concerns". But I never got an explanation/reason for "address" being abandoned. Or if/when it will be considered... That's why I think it's better to have separated Issues: to try to be able to get more specific answers. Although, so far "Yes, we should add that"
And actually... is address the "minting" one forever or does it get updated after transferring an inscription? If it only holds the original-minting one, I don't see much use for it :(
Thanks, agree it needs a separate issue. And no, it's the current address of the ordinal, and hence very interesting to me from a developmental perspective :)
+1 for parent discovery.
A use-case I'm interested in: Parent inscription is a collection.json file outlining collection metadata/script dependencies/params that all children can automatically inherit (via js) without the need to specify the parent ins/sat ID in each child. Good for generative recursive collections !+__+!
= less bytes per child inscription + re-useable load scripts that don't have any hardcoded sat IDs.
I'd also like to request this feature. I've built a generative collection where there are parent / children relationships, and in addition to validating the child actually does belong to a parent, I need to use the same deterministic randomization for both parent and child. The tricky part is the child delegates to the parent so I can't include the parent ID when inscribing the child.
I'd prefer to not fallback to a hack similar to the one mentioned by wagedu.
