Open elocremarc opened 1 month ago
I think I understand the purpose of this PR, if we add charms, old inscriptions can still associate an emoji with new charms. However, I'm not sure I can actually think of way in which this would be useful. Can you give an example?
@casey This is for a light ordinals explorer/viewer to traverse the family tree of an inscription. When you display the /r/inscription information you get the emojis but have to hardcode the updates.
Another option what if ord did some light onchain libraries in leu of recursive endpoints? This endpoint will have to be static anyway why not just do this onchain?
If this list changes ord could just reinscribe the new library sat. Then everyone can just subscribe to that sat get the new list. Then we don't need another endpoint.
Other useful stuff in a library you guys could inscribe. Could be converting between sat notation or other sat tools. We made the sat endpoint not take notation for simplicity but it would be nice to be able have a little library to use these notations onchain. People might not implement it correct etc...
TBH I am kinda on the fence on if this PR is worth doing a recursive endpoint for. I see both sides haha.
I will just inscribe this list myself and maintain it if I need to.
I think this is kind of reasonable, I don't hate it. The maps seems backwards to me though, it should map charm name to current emoji.
@casey ok made the changes and added to the new docs.
Any update on this?
Returns the currently supported charms and their associated names. Allows inscriptions to have forwards compatibility with any new charms added.