Skip to content
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

Can /r/inscription/ please return the inscription's current address? #3670

Open
ZedZeroth opened this issue Apr 23, 2024 · 8 comments
Open

Comments

@ZedZeroth
Copy link

Currently there are two bits of information provided on an inscription's /inscription page that are not included in the /r/inscription data:

  1. Parents: Being discussed here: Can using /r/inscription/ return the parent ID? #3309
  2. Address: This appears to have been removed from Recursive endpoint for retrieving details about an inscription #2628 but the rationale for the decision is unclear.

There are some references to address reuse concerns but it looks as though some of the discussion may have taken place elsewhere? Unless I've overlooked something. Either way, my two main points on this would be:

  1. I don't agree that address reuse should be a barrier to implementing this (assuming that's the reason it was removed). Firstly, we shouldn't be "nannying" what people do with their inscriptions. People are welcome to keep every inscription in a separate address for privacy reasons, but they are also welcome not to. Secondly, I think it's worth noting that (a) clearly the majority of people do not do this, (b) the ordinal-aware wallets are certainly not encouraging this, and (c) many people like showing off their inscriptions so I think privacy should of course be an option, but it should not be forced upon people.
  2. The use-cases for this feature would be phenomenal. Inscriptions could know if they were in the "same place" as other inscriptions, and interact accordingly. To me, the use-case question is like a game developer asking "Why would it be useful for a game sprite / character / NPC to know it's XYZ location?". Imagine what we would be missing if the last 50 years of games and simulations could not determine where things are in 2D/3D space?

I foresee this addition becoming a cornerstone of future complex ordinal mechanics should it be implemented.

Tagging @devords @raphjaph @wagedu @Vanniix as people I have noticed in related discussions.

Thanks :)

@literalmonkey
Copy link

i strongly agree with this. I made a post almost a year ago asking for it for gallery and artistic reasons amongst others.

And now with runes potentially being added as a recursive endpoint, simply having them in the same address to boost or change an inscription would be fantastic.

@ZedZeroth
Copy link
Author

Thanks :) Do you have a link to your original post? Also, where's the best place to read about the upcoming runes endpoints so that I can get a feel for what might be possible? I'd love to integrate runes with my responsive ordinals :)

@ep150de
Copy link

ep150de commented Apr 24, 2024 via email

@ZedZeroth
Copy link
Author

Thanks @ep150de :)

@ZedZeroth
Copy link
Author

I found an earlier discussion here: #3015

@raphjaph says "All the fields look except for maybe the owner_address since we don't want to encourage address reuse and stuff like that."

@raphjaph, with regards to my comments above (#3670 (comment)) are you able to go into more detail regarding what you see as the issue(s) with addresses being available via /r/inscription?

Thanks :)

@cryptoni9n
Copy link
Collaborator

If this is the same topic I'm thinking of, it has been addressed many times, including once by Casey in one of the coding clubs from a couple of months ago. Casey started the explanation by saying it was impossible to get the self-referential inscription ID in any other way than from the url. I might be able to dig up a clip, if necessary.

@ZedZeroth
Copy link
Author

ZedZeroth commented Apr 25, 2024 via email

@ZedZeroth
Copy link
Author

it was impossible to get the self-referential inscription ID in any other way than from the url

This isn't strictly true. I have inscribed two collections that refer to themselves by embedding the sat number within the inscription data. This method could be further optimised by modifying ord such that the inscribe function has a "--self" flag which automatically appends <script>self="sat_number:reinscription_point"</script> onto the inscription data. The IID can then be pulled from /r/sat/sat_number/at/reinscription_point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: To Do
Development

No branches or pull requests

5 participants