mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-13 23:39:08 -05:00
NIP-87: Ecash Mint Discoverability
This commit is contained in:
benthecarman
parent
b224f6d05d
commit
c6bfb1888b
142
87.md
Normal file
142
87.md
Normal file
|
|
@ -0,0 +1,142 @@
|
|||
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": [...] }]]
|
||||
```
|
||||
|
|
@ -74,6 +74,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
- [NIP-75: Zap Goals](75.md)
|
||||
- [NIP-78: Application-specific data](78.md)
|
||||
- [NIP-84: Highlights](84.md)
|
||||
- [NIP-87: Ecash Mint Discoverability](87.md)
|
||||
- [NIP-89: Recommended Application Handlers](89.md)
|
||||
- [NIP-90: Data Vending Machines](90.md)
|
||||
- [NIP-92: Media Attachments](92.md)
|
||||
|
|
@ -139,6 +140,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
| `10030` | User emoji list | [51](51.md) |
|
||||
| `10096` | File storage server list | [96](96.md) |
|
||||
| `13194` | Wallet Info | [47](47.md) |
|
||||
| `18173` | Ecash Mint Recommendation | [87](87.md) |
|
||||
| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] |
|
||||
| `22242` | Client Authentication | [42](42.md) |
|
||||
| `23194` | Wallet Request | [47](47.md) |
|
||||
|
|
@ -173,6 +175,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
| `31925` | Calendar Event RSVP | [52](52.md) |
|
||||
| `31989` | Handler recommendation | [89](89.md) |
|
||||
| `31990` | Handler information | [89](89.md) |
|
||||
| `38172` | Cashu Mint Announcement | [87](87.md) |
|
||||
| `38173` | Fedimint Announcement | [87](87.md) |
|
||||
| `34550` | Community Definition | [72](72.md) |
|
||||
| `39000-9` | Group metadata events | [29](29.md) |
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user