nips
nips copied to clipboard
nostr-protocol
NIP-87: Ecash Mint Discoverability
This is mostly just a fork of NIP-89 but changing the wording about application handling to about discovering ecash mints.
Hopefully this can help cashu/fedimint apps discover mints to connect to.
just a question. Can we make this generic for any outside application can use? NIP-89 is Nostr specific Apps and NIP-87 is rest of the world? Can potentially used by App Store, AI agents, and any other non nostr Apps.
just a question. Can we make this generic for any outside application can use? NIP-89 is Nostr specific Apps and NIP-87 is rest of the world? Can potentially used by App Store, AI agents, and any other non nostr Apps.
Oh I can't wait to bike shed this for 12 months and make no progress on it.
If there were an e-cash specific nostr event kind, you could just use NIP 89. You could even make up a fake kind and use that to signal ecash mint support.
If there were an e-cash specific nostr event kind, you could just use NIP 89. You could even make up a fake kind and use that to signal ecash mint support.
need a way to pass around fedimint invite codes/cashu urls, you can't encode that in an event kind
I see, maybe this is different enough from NIP 89 to warrant a new nip. You could add a new mint_url tag or something though.
You could add a new mint_url tag or something though.
that is what the u tag is for. Needs to be a single letter so it is indexed by relays
I don't see why not use NIP-89 and add some extra tags in there. NIP-89 is already being used for multiple weird things that aren't Nostr clients properly, like DVMs and custodial bunker signer servers.
I don't see why not use NIP-89 and add some extra tags in there. NIP-89 is already being used for multiple weird things that aren't Nostr clients properly, like DVMs and custodial bunker signer servers.
DVMs and nsec bunkers fit well into NIP-89 because they are nostr native, they can just say they handle a specific event kind. This doesn't work as well for this use case because we'd have to assign a fake kind number to represent this which is ends up being basically the same as this, creating a new kind number
After implementing this made some changes:
- split cashu and fedimint events, don't see the point in making them the same, normally you are going to query for one or the other
- made it so the
dtag on the announcement event should have meaning (federation id or cashu pubkey) - cleaned up some text
Maybe we should make this into a big "discoverability" NIP and have a table like in NIP-51 with all the possible kinds of things that can be discovered? Starting with Cashu and Fedimint but then it could have other stuff, I have some in my mind already. This could actually be big.
I like the 'd' tag as cashu pubkey which should be constant for any mint. Starting to work on this to create mint review site for cashu.network assuming this will be merged shortly.
I like the 'd' tag as cashu pubkey which should be constant for any mint. Starting to work on this to create mint review site for cashu.network assuming this will be merged shortly.
What is the reasoning for that, if it's just a fixed value then it doesn't really have any meaning. May as well assign meaning to it.
What is the reasoning for that, if it's just a fixed value then it doesn't really have any meaning. May as well assign meaning to it.
Just in response to this comment, I've learned it's best to keep d tags meaningless. Any semantic piece of information can change, even a pubkey.
What is the reasoning for that, if it's just a fixed value then it doesn't really have any meaning. May as well assign meaning to it.
Just in response to this comment, I've learned it's best to keep d tags meaningless. Any semantic piece of information can change, even a pubkey.
Good point. But it is optional to use a pubkey or any other unique identifier. It is up to the event creator to use or not use it. In the case of cashu mint, if you change the pubkey the entire mint stops working. Pls keep it the same 'd' tag @benthecarman
Should there ideally only be one info event for each mint, and should that only be published by the mint operator? Is there any way to verify the key publishing the event is related to the mint? What if I really like a mint, but there is no info event for it, how do I recommend it?
does this NIP consider the use case where an ecash user wants to be paid in ecash and wants others to know that these are the federations that they want to receive ecash from? like if i want to pay someone in ecash, can i take someone's npub and query for these event kinds and get the federations i can go join and generate ecash for to send to the person and pay them?
or is it more general just "here i recommend these federations"?
or is this just for federations themselves to advertise their mint? or both?
Should there ideally only be one info event for each mint, and should that only be published by the mint operator? Is there any way to verify the key publishing the event is related to the mint? What if I really like a mint, but there is no info event for it, how do I recommend it?
Yes. Cashu mint info endpoint has a field called nostr with npub. This npub should match the info event publisher npub. Otherwise we will not even show that as available mint on the mint review site. [ "nostr", "npub..." ]
but there is no info event for it, how do I recommend it? - it is up to the mint operator to publish the event. if the mint operator wants to keep the mint private, then user cannot recommend it..
or is this just for federations themselves to advertise their mint? or both?
Both
or is it more general just "here i recommend these federations"?
yes. This NIP is just for information about the mint and reviews/recommendations from other users. The use case you are mentioning should be implemented by the wallet providers.
Yes. Cashu mint info endpoint has a field called nostr with npub. This npub should match the info event publisher npub. Otherwise, we will not even show that as available mint on the mint review site. [ "nostr", "npub..." ]
This is reasonable, it should be explicit in the nip.
This NIP is just for information about the mint and reviews/recommendations from other users.
To enhance the "just for information", what do you think about including some extra metadata about the recommendation? Possibly a review (ie. "This mint is awesome!") in the content field of the 18173 and a "stars" tag to rate the overall quality of the mint? I'm thinking in terms of how can clients have more data to rank the mints, rather than just a simple recommendation.
If this extra metadata is included, then recommendation events should be limited to one mint per event.
wants others to know that these are the federations that they want to receive ecash from
Wallet can also simply swap for a trusted mint once payment is received
Wallet can also simply swap for a trusted mint once payment is received
yes but intra-mint ecash payments saves the user a swap fee so having a good protocol to advertise to others which mint is preferred for receiving can sometimes be cheaper for both sender and receiver?
i wonder if this NIP can be used to this kind of preference communication or if a separate dedicated one is better
Maybe we should make this into a big "discoverability" NIP and have a table like in NIP-51 with all the possible kinds of things that can be discovered? Starting with Cashu and Fedimint but then it could have other stuff, I have some in my mind already. This could actually be big.
Great idea. Lots of things feel like they fit in NIP-89, I had the same with DVMs (NIP-90); the same thing that happened with NIP-51 and we ended up overloading that one senseless.
A general discoverability NIP that doesn't try to shoehorn into "applications" is a great idea.
Updated to be more extendable and to do away with the list of recommendations and instead be a single event for each recommendation with a corresponding k and d tag pointing to the thing you are recommending. This should make it easier for clients to not accidentally overwrite people's recommendation list as well as make it simpler to find recommendations for things you are looking for.
I think there needs to be a way to remove recommendations as well as remove listing a mint in general. Does this NIP support that?
edit: nevermind, looks like it's supported on bitcoinmints.com already