NIPs nostr improvement proposals

NIP-87 - Ecash Mint Discoverability

Table of Contents

Ecash Mint Discoverability

draft optional

This NIP describes kind:38173, kind:38172 and kind:38000: a way to discover ecash mints, their capabilities, and people who recommend them.

Rationale

Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics. This NIP provides a simple way for users to discover ecash mints recommended by other users and to interact with them.

Parties involved

There are three actors to this workflow:

Events

Recommendation event

{
"kind": 38000,
"pubkey": <recommender-user-pubkey>,
"tags": [
["k", "38173"],
["d", "<d-identifier>"],
["u", <recommended-fedimint-invite-code>],
["a", "38173:fedimint-pubkey:<d-identifier>", "wss://relay1"]
],
"content": "I trust this mint with my life"
}

The recommendation event is a parameterized-replacable event so that a user can change edit their recommendation without creating a new event.

The d tag in kind:38000 is the kind:38173/kind:38172 event identifier this event is recommending, if no event exists, the d tag can still be calculated from the mint's pubkey/id. The k tag is the kind number that corresponds to the event kind that the user is recommending, in this case kind:38173 for fedimints and kind:38172 for cashu mints.

Optional u tags can be added to give a recommend way to connect to the mint. The value of the tag is the URL or invite code of the ecash mint. Multiple u tags can appear on the same kind:38000.

a tags are used to point to the kind:38173/kind:38172 event of the ecash mint. The first value of the tag is the kind:38173/kind:38172 event identifier, the second value of the tag is a relay hint. This is used to correctly point to the mint's kind:38173/kind:38172 event in case there are duplicates claiming to be the same mint.

The content can be used to give a review.

Ecash Mint Information

Cashu mints SHOULD publish kind:38172 events to announce their capabilities and how to connect to them.

For cashu mints, the u tag SHOULD be the URL to the cashu mint and it should list the nuts that the cashu mint supports.

The d tag SHOULD be the mint's pubkey (found when querying /v1/info), this way users can query by pubkey and find the mint announcement.

An n tag SHOULD be added to signify the network the cashu mint is on (either mainnet, testnet, signet, or regtest)

{
"kind": 38172,
"pubkey": "<application-pubkey>",
"content": "<optional-kind:0-style-metadata>",
"tags": [
["d", <cashu mint pubkey>],
["u", "https://cashu.example.com"],
["nuts", "1,2,3,4,5,6,7"],
["n", "mainnet"]
]
}

Fedimints SHOULD publish kind:38173 events to announce their capabilities and how to connect to them.

For fedimints, it should list all known fedimint invite codes in u tags and it should list the modules it supports.

The d tag SHOULD be the federation id, this way users can query by federation id and find the fedimint announcement.

An n tag SHOULD be added to signify the network the fedimint is on (either mainnet, testnet, signet, or regtest)

{
"kind": 38173,
"pubkey": "<application-pubkey>",
"content": "<optional-kind:0-style-metadata>",
"tags": [
["d", <federation-id>],
["u", "fed11abc.."],
["u", "fed11xyz.."],
["modules", "lightning,wallet,mint"],
["n", "signet"]
]
}

Example

User A recommends some mints

User A might be a user of a cashu mint. Using a client, user A publishes an event recommending the cashu mint they use.

{
"kind": 38000,
"tags": [
["u", "fed11abc..", "fedimint"],
["u", "https://cashu.example.com", "cashu"],
["a", "38173:fedimint-pubkey:<d-identifier>", "wss://relay1", "fedimint"],
["a", "38172:cashu-mint-pubkey:<d-identifier>", "wss://relay2", "cashu"]
],
...
}

User B finds a mint

User B wants to use an ecash wallet, they need to find a mint.

User B's wallet client queries for kind:38000 events, looking for recommendations for ecash mints.

["REQ", <id>, [{ "kinds": [38000], "authors": [<user>, <users-contact-list>], "#k": ["38173"] }]]

User B, who follows User A, sees that kind:38000 event and tries to connect to the corresponding mints.

Alternative query bypassing kind:38000

Alternatively, users might choose to query directly for kind:38173 for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.

["REQ", <id>, [{ "kinds": [38173], "authors": [...] }]]