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

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

Closed
callebtc opened this issue Nov 11, 2023 · 7 comments · Fixed by #175
Closed

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

callebtc opened this issue Nov 11, 2023 · 7 comments · Fixed by #175

Comments

@callebtc
Copy link
Contributor

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

@Egge21M
Copy link
Contributor

Egge21M commented Jun 24, 2024

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

@callebtc
Copy link
Contributor Author

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.

@thesimplekid thesimplekid changed the title NUT-09: Mint should announce multiple endpoints that it is reachable from NUT-06: Mint should announce multiple endpoints that it is reachable from Jun 26, 2024
@callebtc
Copy link
Contributor Author

callebtc commented Oct 6, 2024

Self-bump

@prusnak
Copy link
Collaborator

prusnak commented Oct 10, 2024

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
Copy link
Contributor Author

callebtc commented Oct 10, 2024

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 prusnak mentioned this issue Oct 11, 2024
2 tasks
@prusnak
Copy link
Collaborator

prusnak commented Oct 11, 2024

PR in #175

@ok300
Copy link
Contributor

ok300 commented Nov 2, 2024

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

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 a pull request may close this issue.

4 participants