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
```json
{
  "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`)

```json
{
  "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`)

```json
{
  "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.

```json
{
  "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.

```json
["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.

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