Charms info recursive /r/charms

[elocremarc]

Returns the currently supported charms and their associated names.
Allows inscriptions to have forwards compatibility with any new charms added.

[casey]

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?

[elocremarc]

@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.

[casey]

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.

[elocremarc]

@casey ok made the changes and added to the new docs.

[casey]

Nice, see comments!

[casey]

This can be:

  async fn charms() -> ServerResult<Json<BTreeMap<Charm, &'static str>>> {

charm implements serialize by delegating to Display, which is what is used in to_string.

[casey]

Suggested change

	Latest charms.
	Latest charms.

[casey]

I'm not sure why we use -s and -H "Accept: application/json" for our curl examples. I don't think any of the recursive endpoints require the Accept header, and the -s will only suppress errors, which isn't useful.

Suggested change

	### Example
	```bash
	curl -s \
	http://0.0.0.0:80/r/charms
	```
	```json
	{
	"coin": "🪙",
	"uncommon": "🌱",
	"rare": "🧿",
	"epic": "🪻",
	"legendary": "🌝",
	"mythic": "🎃",
	"nineball": "9️⃣",
	"reinscription": "♻️",
	"cursed": "👹",
	"unbound": "🔓",
	"lost": "🤔",
	"vindicated": "❤️‍🔥",
	"burned": "🔥"
	}
	```
	</details>
	### Example
	```bash
	curl http://0.0.0.0:80/r/charms

{
  "coin": "🪙",
  "uncommon": "🌱",
  "rare": "🧿",
  "epic": "🪻",
  "legendary": "🌝",
  "mythic": "🎃",
  "nineball": "9️⃣",
  "reinscription": "♻️",
  "cursed": "👹",
  "unbound": "🔓",
  "lost": "🤔",
  "vindicated": "❤️‍🔥",
  "burned": "🔥"
}

```

[casey]

Suggested change

	let charms_response =
	server.get_json::<serde_json::Map<String, serde_json::Value>>("/r/charms");
	let charms_response =
	server.get_json::<BTreeMap<String, String>>("/r/charms");

[casey]

And then assert_eq against a BTreeMap built from the actual charms.

[raphjaph]

Any update on this?