Recursive endpoint for retrieving details about an inscription

[lifofifoX]

This should be useful for a variety of use cases.

[elocremarc]

We should add sat and output I have been wanting these forever.
Sat
Output

We should add output so we can eventually do a output recursive endpoint. This would have tons of uses. You could do dynamic content like a website that you can update based on coin control. Having an inscription aware of what output its on is how you would do start this.

Address would also play into cool stuff combined with output it gets us close to be able to port over openordex and make an inscription be a PSBT marketplace of itself.

Other more whimsical uses of output is an inscription that changes as it moves.

Sat would also play super well when combined with child and the sat recursive endpoint.

[lifofifoX]

I wanted to keep the response as minimal as possible, as we can always add stuff. But probably never remove. Happy to add whatever we want, if there's consensus. Output sounds good to me!

Re: sat, I think that'd require sat index, no? That's why I didn't add it.

[elocremarc]

Re: sat, I think that'd require sat index, no? That's why I didn't add it.

Yeah but were already crossing that bridge with sat endpoint. So it would return null probably if no sat index.
Also this would be super powerful with the child endpoint to then go into that with the sat endpoint.

[elocremarc]

if there's consensus. Output sounds good to me!

@rot13maxi and I were talking on the sat endpoint spaces the other day about how we really want to get to the point where we can start making crazy cool inscriptions that get us closer to calling data on the bitcoin node. Been wanting to see if we can get openordex onto an inscription since it came out. Knowing an inscriptions output is invaluable for this kinda stuff.

[lifofifoX]

I'll work on adding output to JSON.

Still not convinced about sat. My gut feeling is that we should refrain from adding recursive endpoints that rely on a full sat index. The risk is creating two classes of inscriptions, especially as the index grows larger and slower with every block.

We can achieve most of the things with /children recursive endpoint that would be made possible with sat endpoint. Agree that sat endpoint would make it much easier as there are no sit ups involved in figuring out the inscription id. But it also comes at a cost and maybe something we can punt on in favor of /children.

[owenstrevor]

Would be awesome to add the Sat Endpoint. IMO the Sat Endpoint is the most important endpoint for Ordinals right now. With the Sat Endpoint, you can futureproof your collection so that you can access all of the endpoints that come out in the future, and then you can lock down your work by burning the sat. This would probably also give the devs some breathing room from people wanting stuff right away because they can just add the Sat Endpoint and then get the endpoint they need when it's fully ready.

[lifofifoX]

I'm curious to know what thing is possible with sat endpoint that's not possible with a children endpoint?

[lifofifoX]

@elocremarc Added satpoint to response JSON.

[elocremarc]

I'm curious to know what thing is possible with sat endpoint that's not possible with a children endpoint?

Sat is more controlled by creator and child can be collector basically. However you could make the sat endpoint work for a collector if you reference the sat that an inscription is being inscribed to. With sat you can know what the sat is prior to inscribing. However if you want to know the sat in some future child its good to have it here in this endpoint because it might not be known ahead of time.

Also you might not always want to reinscribe a sat and might want this ability in a child instead.

[casey]

Almost there! See comments.

[elocremarc]

@casey don't we wanna add the sat number in this endpoint? This is very useful combined with the child endpoint or doing the sat endpoint on children you might not know the sat number for prior to inscribing like with batch inscriptions.

[lifofifoX]

@elocremarc @casey I am planning to work on this again this week. Let me know and I can add whatever other keys to JSON.

[elocremarc]

Been making some onchain inscription viewers I think having parent would also be super helpful here. Then you can traverse up and down the family tree.
example: if you are on some inscription then you can see the siblings with the /children endpoint. Or find the ancestor.

Let me know and I can add whatever other keys to JSON.

My vote adding the sat_number and parent to the JSON

[owenstrevor]

@casey don't we wanna add the sat number in this endpoint? This is very useful combined with the child endpoint or doing the sat endpoint on children you might not know the sat number for prior to inscribing like with batch inscriptions.

YES PLEASE. Right now we have to inscribe the sat number itself, either in the individual inscription metadata or in a separate "lookup table" inscription afterwards. The former is not really possible with bulk inscriptions without more customization to ord. Both are hacky solutions where truth is what the dev wrote and not Bitcoin. Essential for our "holder-permissioned" sat endpoint upgrade model: https://ninjalerts.gitbook.io/bitcoin-ordinals-pizza-ninjas/upgradability

[raphjaph]

Is this ready for review? @devords

[lifofifoX]

@raphjaph Going to working on the requested changes today!

[lifofifoX]

@raphjaph I think I addressed all of the comments, except address one.

• Added charms and output
• Made sat optional

Still holding out some hope for including address. It'll unlock so many use cases! I am curious if there's some way without having to compromise on address reuse. Maybe the address could be hashed?

[raphjaph]

What use cases does address unlock?

[lifofifoX]

@raphjaph The primary one I'm interested in is using address for randomization seed for generative art, where rarity would be tied to an address. Moving inscription to a new address would generate a new output. But moving it back to the previous address would then generate the output you had before.

Additionally, you can also do soulbound'esq inscriptions where the inscription behaves different when it's held by a specific owner.

[lifofifoX]

@raphjaph Removed the address

[ZedZeroth]

@devords Thank you for raising this. I've been thinking about such endpoints since mid-2023 and how much this kind of self-data would benefit the inscription ecosystem. I didn't realise that it was already in progress until @gmart7t2 pointed me here. I would like inscriptions be able to reference their own:

1. Inscription ID
2. Sat number
3. UTXO location
4. Address location
5. Metadata

It looks as though some of these are being pushed through soon? Could you clarify which ones are currently looking likely to be included and then I may respond with some arguments for including the others? :)

[ZedZeroth]

@raphjaph The primary one I'm interested in is using address for randomization seed for generative art, where rarity would be tied to an address. Moving inscription to a new address would generate a new output. But moving it back to the previous address would then generate the output you had before.

Additionally, you can also do soulbound'esq inscriptions where the inscription behaves different when it's held by a specific owner.

Yes 100% this!

[ZedZeroth]

@raphjaph I think I addressed all of the comments, except address one.

* Added charms and output

* Made sat optional

Still holding out some hope for including address. It'll unlock so many use cases! I am curious if there's some way without having to compromise on address reuse. Maybe the address could be hashed?

Is this just a general "reusing bitcoin addresses is bad" argument, or is there something more specific to ordinals/inscriptions? Thanks

[ep150de]

I also have Gen art that depends on the art changing based on the address that holds the inscription.Since a majority use wallets like xverse, unisat, etc. Which uses a constant static receiving address, we need to open the possibility to take advantage of this for creative features such as dynamic art based on the address of the holder that owns it.Sent via the Samsung Galaxy Note20 Ultra 5G, an AT&T 5G smartphone -------- Original message --------From: ZedZeroth ***@***.***> Date: 2/18/24 04:46 (GMT-08:00) To: ordinals/ord ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [ordinals/ord] Recursive endpoint for retrieving details about an inscription (PR #2628) @raphjaph The primary one I'm interested in is using address for randomization seed for generative art, where rarity would be tied to an address. Moving inscription to a new address would generate a new output. But moving it back to the previous address would then generate the output you had before. Additionally, you can also do soulbound'esq inscriptions where the inscription behaves different when it's held by a specific owner. Yes 100% this! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jerryfane]

Address is cool to implement some onchain subscription mechanism

[casey]

Looks good to me!

[casey]

Looks good to me!

[raphjaph]

Let's go!

[lifofifoX]

This will be a fun one! Thank you @casey and @raphjaph 🙏

[ZedZeroth]

Thanks for this. I think I am going to map out what inscriptions can currently access, and what they can't, and then push for "full inter-ordinal operability" where possible. It looks like a sat/inscription's current address is the only major one missing though? I have some further ideas but they may be more technically challenging/prohibitive to include. Huge progress with this has been made in the last six months though, it's fantastic for building :)