{"id":"c38b5c034ef7e41f28e222dc84b4e62b2f3570414714cc7ca22dd6f3318e5052","pubkey":"2b39b4ffe62933df970e19366c22c1e092f953f83fcfed754e0f04d5a3b459f9","created_at":1780437255,"kind":30817,"tags":[["d","nip-87"],["title","NIP-87: Cashu and Fedimint Discoverability"],["summary","How an ecash mint announces itself and its capabilities, and how users recommend the mints they trust."],["s","draft"],["t","nostr"],["t","nip"],["k","38172","Cashu Mint Announcement"],["k","38173","Fedimint Announcement"],["alt","A specification: NIP-87: Cashu and Fedimint Discoverability"],["client","openspecs-import"],["published_at","1752664389"],["proxy","https://github.com/nostr-protocol/nips/blob/656cecc7c0a815b6a2b218d3b5d6f078b3f4dbab/87.md","web"],["x","469d8672359aaeb1ed0ef244088111be0e4dba68a679a8c46c6f7c4ebe5302c7"]],"content":"NIP-87\n======\n\nCashu and Fedimint Discoverability\n----------------------------------\n\n`draft` `optional`\n\nThis NIP describes `kind:38173`, `kind:38172` and `kind:38000`: a way to discover ecash mints, their capabilities, and people who recommend them.\n\n## Rationale\n\nNostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics.\nThis NIP provides a simple way for users to discover ecash mints recommended by other users and to interact with them.\n\n### Parties involved\n\nThere are three actors to this workflow:\n\n* An ecash mint operator, announces their mint and its capabilities.\n    * Publishes `kind:38173` or `kind:38172`, detailing how to connect to it and its capabilities.\n* user A, who recommends an ecash mint\n    * Publishes `kind:38000`\n* user B, who seeks a recommendation for an ecash mint\n    * Queries for `kind:38000` and, based on results, queries for `kind:38173`/`kind:38172`\n\n## Events\n\n### Recommendation event\n```json\n{\n  \"kind\": 38000,\n  \"pubkey\": <recommender-user-pubkey>,\n  \"tags\": [\n    [\"k\", \"38173\"],\n    [\"d\", \"<d-identifier>\"],\n    [\"u\", <recommended-fedimint-invite-code>],\n    [\"a\", \"38173:fedimint-pubkey:<d-identifier>\", \"wss://relay1\"]\n  ],\n  \"content\": \"I trust this mint with my life\"\n}\n```\n\nThe recommendation event is a parameterized-replaceable event so that a user can change edit their recommendation without creating a new event.\n\nThe `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.\nThe `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.\n\nOptional `u` tags can be added to give a recommend way to connect to the mint.\nThe value of the tag is the URL or invite code of the ecash mint.\nMultiple `u` tags can appear on the same `kind:38000`.\n\n`a` tags are used to point to the `kind:38173`/`kind:38172` event of the ecash mint.\nThe first value of the tag is the `kind:38173`/`kind:38172` event identifier, the second value of the tag is a relay hint.\nThis 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.\n\nThe content can be used to give a review.\n\n## Mint Information\n\nCashu mints SHOULD publish `kind:38172` events to announce their capabilities and how to connect to them.\n\nFor cashu mints, the `u` tag SHOULD be the URL to the cashu mint and it should list the nuts that the cashu mint supports.\n\nThe `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.\n\nAn `n` tag SHOULD be added to signify the network the cashu mint is on (either `mainnet`, `testnet`, `signet`, or `regtest`)\n\n```json\n{\n  \"kind\": 38172,\n  \"pubkey\": \"<application-pubkey>\",\n  \"content\": \"<optional-kind:0-style-metadata>\",\n  \"tags\": [\n    [\"d\", <cashu mint pubkey>],\n    [\"u\", \"https://cashu.example.com\"],\n    [\"nuts\", \"1,2,3,4,5,6,7\"],\n    [\"n\", \"mainnet\"]\n  ]\n}\n```\n\nFedimints SHOULD publish `kind:38173` events to announce their capabilities and how to connect to them.\n\nFor fedimints, it should list all known fedimint invite codes in `u` tags and it should list the modules it supports.\n\nThe `d` tag SHOULD be the federation id, this way users can query by federation id and find the fedimint announcement.\n\nAn `n` tag SHOULD be added to signify the network the fedimint is on (either `mainnet`, `testnet`, `signet`, or `regtest`)\n\n```json\n{\n  \"kind\": 38173,\n  \"pubkey\": \"<application-pubkey>\",\n  \"content\": \"<optional-kind:0-style-metadata>\",\n  \"tags\": [\n    [\"d\", <federation-id>],\n    [\"u\", \"fed11abc..\"],\n    [\"u\", \"fed11xyz..\"],\n    [\"modules\", \"lightning,wallet,mint\"],\n    [\"n\", \"signet\"]\n  ]\n}\n```\n\n* `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.)\n\n## Example\n\n### User A recommends some mints\nUser A might be a user of a cashu mint. Using a client, user A publishes an event recommending the cashu mint they use.\n\n```json\n{\n  \"kind\": 38000,\n  \"tags\": [\n    [\"u\", \"fed11abc..\", \"fedimint\"],\n    [\"u\", \"https://cashu.example.com\", \"cashu\"],\n    [\"a\", \"38173:fedimint-pubkey:<d-identifier>\", \"wss://relay1\", \"fedimint\"],\n    [\"a\", \"38172:cashu-mint-pubkey:<d-identifier>\", \"wss://relay2\", \"cashu\"]\n  ],\n  ...\n}\n```\n\n### User B finds a mint\nUser B wants to use an ecash wallet, they need to find a mint.\n\nUser B's wallet client queries for `kind:38000` events, looking for recommendations for ecash mints.\n\n```json\n[\"REQ\", <id>, [{ \"kinds\": [38000], \"authors\": [<user>, <users-contact-list>], \"#k\": [\"38173\"] }]]\n```\n\nUser B, who follows User A, sees that `kind:38000` event and tries to connect to the corresponding mints.\n\n### Alternative query bypassing `kind:38000`\nAlternatively, 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.\n\n```json\n[\"REQ\", <id>, [{ \"kinds\": [38173], \"authors\": [...] }]]\n```\n","sig":"13ea0d4b11bee14a6beff8ac2fdbc15544bba29a0e6611af3571b833b0cafa6c7b7f724a9584e4812fdb96789cf3cffe7c7d7b89c81afe95f7d85b36f5c9365d"}