nips/87.md

NIP-87

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:

• An ecash mint operator, announces their mint and its capabilities.
  • Publishes kind:38173 or kind:38172, detailing how to connect to it and its capabilities.
• user A, who recommends an ecash mint
  • Publishes kind:38000
• user B, who seeks a recommendation for an ecash mint
  • Queries for kind:38000 and, based on results, queries for kind:38173/kind:38172

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"]
  ]
}

• content is an optional metadata-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the kind:38173 is not a normal user. If content is empty, the kind:0 of the pubkey should be used to display mint information (e.g. name, picture, web, LUD16, etc.)

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": [...] }]]