1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
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-replaceable 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": [...] }]]
```
|