NUT-06: Mint should announce multiple endpoints that it is reachable from

[callebtc]

Mint should announce https / Tor addresses in the info response at which it is reachable from.

[Egge21M]

Can we use https://github.com/nostr-protocol/nips/pull/1110 as a way for a mint to announce changes to their npub?

1. Client connects to mint
2. Clients retrieves nostr pubkey from /info
3. Client periodically checks the pubkey on nostr for updates

[callebtc]

Can we use nostr-protocol/nips#1110 as a way for a mint to announce changes to their npub?

1. Client connects to mint
2. Clients retrieves nostr pubkey from /info
3. Client periodically checks the pubkey on nostr for updates

That sounds like a good idea but I think it would be an overkill right now. If we go further down the nostr route, the mint should probably announce a lot more than just the mint URLs (whole info endpoint for example, and keys etc). Since the chance of your DNS getting rugged is really small, I wouldn't consider this a pressing issue right now though.

[callebtc]

Self-bump

[prusnak]

Adding multiple URLs to the config and to the /info response is trivial.

But how should a cashu token behave if there are multiple URLs defined for a mint?

Should we bake all URLs into the cashu tokens? 🤔 The m field - mint URL - currently does not support a list. Maybe it should?

[callebtc]

But how should a cashu token behave if there are multiple URLs defined for a mint?

Should we bake all URLs into the cashu tokens? 🤔 The m field - mint URL - currently does not support a list. Maybe it should?

Good question, I think we can get away with a single URL for now. Wallets that know multiple endpoints (or fetch the info) can choose a transport they like when they receive a token. The URL in the token should always be assumed be reachable.

A simple list in the info endpoint should do the job for now.

[prusnak]

PR in https://github.com/cashubtc/nuts/pull/175

[ok300]

Wallets that know multiple endpoints (or fetch the info) can choose a transport they like when they receive a token. The URL in the token should always be assumed be reachable.

Doesn't this make Offline Receive trickier? The receiver might only fetch the info much later, when the baked mint URL may not be reachable.

Even for the happy case (Online Receive), both the sender and receiver have to make an extra mint call for each transfer. The sender has to make sure the chosen URL is active just before sending the token, the receiver has to fetch and store the mint alternate URLs just after receiving.

From a mint POV, the new field incentivizes a more liberal attitude around changing hosts. It assumes wallets know how to reach it, so can can experiment with more exotic domains. Domains don't have to be rugged to be removed from the list, it could just be the mint operator found a fancier domain name and is saving costs by removing an older one.

---

Overall I don't think it's a good idea. It appears to make mints more resilient, but actually introduces new assumptions, shifts the protocol towards more "chattiness" (more dependency on network calls) and weakens the Offline Receive case.

ISTM the same benefit can already be achieved with what we have now, without changing the mint info response (#175) :

• if a mint wants to be reachable via multiple URLs, it can already do so
• if Alice (sender) bakes a token using mint URL A, then Carol (the receiver) can already redeem it at the mint's URL B, because it can identify it's the same mint by the keyset ID
• if the mint wants to advertise its several URLs, it can do so in the existing mint info fields, like description or description_long
• even if the mint doesn't do this, its alternate URLs can still be easily discoverable: any mint aggregator website (like bitcoinmints) can identify which URLs point to the same mint by checking the keyset IDs: same IDs on both URLs => same mint