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

Recursive Address /r/address/:address #3892

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

elocremarc
Copy link
Contributor

This PR will add the ability for an inscription to know runes balances, sat balances, Inscriptions and outputs for any address recursively.

Note:
This will need #3891 for an inscription to find an address to query this endpoint with.

@lifofifoX
Copy link
Collaborator

If we truly desire rune-aware inscriptions, it might be worth upgrading the Rune protocol to make them inscription aware and allow deposits/withdrawals of Runes to/from an inscription.

For example, add an inscription flag to the Edict struct, requiring it to be set for both deposits and withdrawals, indicating that the balance should go to the first inscription in the edict output. The balance could then be exposed via /r/inscription endpoint.

@ameenwire100
Copy link

Nice work

@raphjaph
Copy link
Collaborator

I don't think it makes sense right now because the address index is extremely new and untested. Creating a heavy dependency on it through a recursive endpoint would not be ideal. Have you built the address index and tried playing around with this endpoint?

@switch-900
Copy link

This should be looked at properly, the the possibilities of this are very valuable to the building community.

@raphjaph raphjaph marked this pull request as draft September 3, 2024 16:28
@matthewvollmer
Copy link

matthewvollmer commented Sep 25, 2024

Hey, have you all considered if this makes sense, now that the address index has been out for a bit?
I have some use cases for this that I would love to use!

Currently, I have a collection (BTC Substance) that detects if the owning wallet owns multiple pieces in the collection, and updates the art to reflect this. Currently, I have to manually call /r/inscription/ on each inscription in the collection to get the address info, and compare it to the owner address.

The collection is only 100 pieces, so it's somewhat feasible to do 100 async calls while loading the art. But it seems infeasible to scale this approach for larger collections. For my 5k collection, I would love to just be able to call /r/address/ once to get this info!

I personally think that if this was available, other artists would find ways to incorporate ownership-awareness into their code.

I acknowledge that having inscriptions rely on the address inscription would increase the difficulty of people running their own node, and the strain on marketplaces. But I think it also offers a lot of opportunity in terms of art&tech.

Thanks so much for your consideration!
~MDV

@elocremarc
Copy link
Contributor Author

@raphjaph

I don't think it makes sense right now because the address index is extremely new and untested.....Have you built the address index and tried playing around with this endpoint?

How about now?

When you wrote this originally I was struggling to sync it. However since that big index update I have been able to keep my address index at chain tip relatively easily no issues. Is there still more optimization you are working on for the address index or do you think we are finally ready?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants