mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-12-09 00:28:51 +00:00
Compare commits
4 Commits
nip60-rese
...
onion-rout
| Author | SHA1 | Date | |
|---|---|---|---|
|
7fc031151c | ||
|
|
086335713c | ||
|
|
5e2ad4b3bb | ||
|
|
b5774a1338 |
148
29.md
148
29.md
@@ -22,12 +22,6 @@ Relays are supposed to generate the events that describe group metadata and grou
|
||||
|
||||
A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
|
||||
|
||||
Group identifiers must be strings restricted to the characters `a-z0-9-_`.
|
||||
|
||||
When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions.
|
||||
|
||||
Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusiong and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
|
||||
|
||||
## The `h` tag
|
||||
|
||||
Events sent by users to groups (chat messages, text notes, moderation events etc) must have an `h` tag with the value set to the group _id_.
|
||||
@@ -42,30 +36,8 @@ This is a hack to prevent messages from being broadcasted to external relays tha
|
||||
|
||||
Relays should prevent late publication (messages published now with a timestamp from days or even hours ago) unless they are open to receive a group forked or moved from another relay.
|
||||
|
||||
## Group management
|
||||
|
||||
Groups can have any number of users with elevated access. These users are identified by role labels which are arbitrarily defined by the relays (see also the description of `kind:39003`). What each role is capable of not defined in this NIP either, it's a relay policy that can vary. Roles can be assigned by other users (as long as they have the capability to add roles) by publishing a `kind:9000` event with that user's pubkey in a `p` tag and the roles afterwards (even if the user is already a group member a `kind:9000` can be issued and the user roles must just be updated).
|
||||
|
||||
The roles supported by the group as to having some special privilege assigned to them should be accessible on the event `kind:39003`, but the relay may also accept other role names, arbitrarily defined by clients, and just not do anything with them.
|
||||
|
||||
Users with any roles that have any privilege can be considered _admins_ in a broad sense and be returned in the `kind:39001` event for a group.
|
||||
|
||||
## Unmanaged groups
|
||||
|
||||
Unmanaged groups are impromptu groups that can be used in any public relay unaware of NIP-29 specifics. They piggyback on relays' natural white/blacklists (or lack of) but aside from that are not actively managed and won't have any admins, group state or metadata events.
|
||||
|
||||
In `unmanaged` groups, everybody is considered to be a member.
|
||||
|
||||
Unmanaged groups can transition to managed groups, in that case the relay master key just has to publish moderation events setting the state of all groups and start enforcing the rules they choose to.
|
||||
|
||||
## Event definitions
|
||||
|
||||
These are the events expected to be found in NIP-29 groups.
|
||||
|
||||
### Normal user-created events
|
||||
|
||||
These events generally can be sent by all members of a group and they require the `h` tag to be present so they're attached to a specific group.
|
||||
|
||||
- *text root note* (`kind:11`)
|
||||
|
||||
This is the basic unit of a "microblog" root text note sent to a group.
|
||||
@@ -107,14 +79,6 @@ Similar to `kind:12`, this is the basic unit of a chat message sent to a group.
|
||||
|
||||
`kind:10` SHOULD use NIP-10 markers, just like `kind:12`.
|
||||
|
||||
- other events:
|
||||
|
||||
Groups may also accept other events, like long-form articles, calendar, livestream, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.
|
||||
|
||||
### User-related group management events
|
||||
|
||||
These are events that can be sent by users to manage their situation in a group, they also require the `h` tag.
|
||||
|
||||
- *join request* (`kind:9021`)
|
||||
|
||||
Any user can send one of these events to the relay in order to be automatically or manually added to the group. If the group is `open` the relay will automatically issue a `kind:9000` in response adding this user. Otherwise group admins may choose to query for these requests and act upon them.
|
||||
@@ -124,14 +88,11 @@ Any user can send one of these events to the relay in order to be automatically
|
||||
"kind": 9021,
|
||||
"content": "optional reason",
|
||||
"tags": [
|
||||
["h", "<group-id>"],
|
||||
["code", "<optional-invite-code>"]
|
||||
["h", "<group-id>"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The optional `code` tag may be used by the relay to preauthorize acceptances in `closed` groups, together with the `kind:9009` `create-invite` moderation event.
|
||||
|
||||
- *leave request* (`kind:9022`)
|
||||
|
||||
Any user can send one of these events to the relay in order to be automatically removed from the group. The relay will automatically issue a `kind:9001` in response removing this user.
|
||||
@@ -146,13 +107,9 @@ Any user can send one of these events to the relay in order to be automatically
|
||||
}
|
||||
```
|
||||
|
||||
### Group state -- or moderation
|
||||
|
||||
These are events expected to be sent by the relay master key or by group admins -- and relays should reject them if they don't come from an authorized admin. They also require the `h` tag.
|
||||
|
||||
- *moderation events* (`kinds:9000-9020`) (optional)
|
||||
|
||||
Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).
|
||||
Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action. The relay may discard the event after taking action or keep it as a moderation log.
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -167,20 +124,17 @@ Clients can send these events to a relay in order to accomplish a moderation act
|
||||
|
||||
Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
|
||||
|
||||
| kind | name | tags |
|
||||
| --- | --- | --- |
|
||||
| 9000 | `add-user` | `p` with pubkey hex and optional roles |
|
||||
| 9001 | `remove-user` | `p` with pubkey hex |
|
||||
| 9002 | `edit-metadata` | fields from `kind:39000` to be modified |
|
||||
| 9005 | `delete-event` | |
|
||||
| 9007 | `create-group` | |
|
||||
| 9008 | `delete-group` | |
|
||||
|
||||
It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.
|
||||
|
||||
### Group metadata events
|
||||
|
||||
These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
|
||||
| kind | name | tags |
|
||||
| --- | --- | --- |
|
||||
| 9000 | `add-user` | `p` (pubkey hex) |
|
||||
| 9001 | `remove-user` | `p` (pubkey hex) |
|
||||
| 9002 | `edit-metadata` | `name`, `about`, `picture` (string) |
|
||||
| 9003 | `add-permission` | `p` (pubkey), `permission` (name) |
|
||||
| 9004 | `remove-permission` | `p` (pubkey), `permission` (name) |
|
||||
| 9005 | `delete-event` | `e` (id hex) |
|
||||
| 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
|
||||
| 9007 | `create-group` | |
|
||||
| 9008 | `delete-group` | |
|
||||
|
||||
- *group metadata* (`kind:39000`) (optional)
|
||||
|
||||
@@ -188,8 +142,6 @@ This event defines the metadata for the group -- basically how clients should di
|
||||
|
||||
If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.
|
||||
|
||||
When this event is not found, clients may still connect to the group, but treat it as having a different status, `unmanaged`,
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 39000,
|
||||
@@ -210,29 +162,41 @@ When this event is not found, clients may still connect to the group, but treat
|
||||
|
||||
- *group admins* (`kind:39001`) (optional)
|
||||
|
||||
Each admin is listed along with one or more roles. These roles SHOULD have a correspondence with the roles supported by the relay, as advertised by the `kind:39003` event.
|
||||
Similar to the group metadata, this event is supposed to be generated by relays that host the group.
|
||||
|
||||
```jsonc
|
||||
Each admin gets a label that is only used for display purposes, and a list of permissions it has are listed afterwards. These permissions can inform client building UI, but ultimately are evaluated by the relay in order to become effective.
|
||||
|
||||
The list of capabilities, as defined by this NIP, for now, is the following:
|
||||
|
||||
- `add-user`
|
||||
- `edit-metadata`
|
||||
- `delete-event`
|
||||
- `remove-user`
|
||||
- `add-permission`
|
||||
- `remove-permission`
|
||||
- `edit-group-status`
|
||||
- `delete-group`
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": 39001,
|
||||
"content": "list of admins for the pizza lovers group",
|
||||
"tags": [
|
||||
["d", "<group-id>"],
|
||||
["p", "<pubkey1-as-hex>", "ceo"],
|
||||
["p", "<pubkey2-as-hex>", "secretary", "gardener"],
|
||||
// other pubkeys...
|
||||
],
|
||||
["p", "<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"],
|
||||
["p", "<pubkey2-as-hex>", "secretary", "add-user", "delete-event"]
|
||||
]
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
- *group members* (`kind:39002`) (optional)
|
||||
|
||||
It's a list of pubkeys that are members of the group. Relays might choose to not to publish this information, to restrict what pubkeys can fetch it or to only display a subset of the members in it.
|
||||
Similar to *group admins*, this event is supposed to be generated by relays that host the group.
|
||||
|
||||
Clients should not assume this will always be present or that it will contain a full list of members.
|
||||
It's a NIP-51-like list of pubkeys that are members of the group. Relays might choose to not to publish this information or to restrict what pubkeys can fetch it.
|
||||
|
||||
```jsonc
|
||||
```json
|
||||
{
|
||||
"kind": 39002,
|
||||
"content": "list of members for the pizza lovers group",
|
||||
@@ -241,48 +205,10 @@ Clients should not assume this will always be present or that it will contain a
|
||||
["p", "<admin1>"],
|
||||
["p", "<member-pubkey1>"],
|
||||
["p", "<member-pubkey2>"],
|
||||
// other pubkeys...
|
||||
],
|
||||
// other fields...
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- *group roles* (`kind:39003`) (optional)
|
||||
## Storing the list of groups a user belongs to
|
||||
|
||||
This is an event that MAY be published by the relay informing users and clients about what are the roles supported by this relay according to its internal logic.
|
||||
|
||||
For example, a relay may choose to support the roles `"admin"` and `"moderator"`, in which the `"admin"` will be allowed to edit the group metadata, delete messages and remove users from the group, while the `"moderator"` can only delete messages (or the relay may choose to call these roles `"ceo"` and `"secretary"` instead, the exact role name is not relevant).
|
||||
|
||||
The process through which the relay decides what roles to support and how to handle moderation events internally based on them is specific to each relay and not specified here.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 39003,
|
||||
"content": "list of roles supported by this group",
|
||||
"tags": [
|
||||
["d", "<group-id>"],
|
||||
["role", "<role-name>", "<optional-description>"],
|
||||
["role", "<role-name>", "<optional-description>"],
|
||||
// other roles...
|
||||
],
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
## Implementation quirks
|
||||
|
||||
### Checking your own membership in a group
|
||||
|
||||
The latest of either `kind:9000` or `kind:9001` events present in a group should tell a user that they are currently members of the group or if they were removed. In case none of these exist the user is assumed to not be a member of the group -- unless the group is `unmanaged`, in which case the user is assumed to be a member.
|
||||
|
||||
### Adding yourself to a group
|
||||
|
||||
When a group is `open`, anyone can send a `kind:9021` event to it in order to be added, then expect a `kind:9000` event to be emitted confirming that the user was added. The same happens with `closed` groups, except in that case a user may only send a `kind:9021` if it has an invite code.
|
||||
|
||||
### Storing your list of groups
|
||||
|
||||
A definition for `kind:10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
|
||||
|
||||
### Using `unmanaged` relays
|
||||
|
||||
To prevent event leakage, replay and confusion, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
|
||||
A definition for kind `10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
|
||||
|
||||
146
37.md
Normal file
146
37.md
Normal file
@@ -0,0 +1,146 @@
|
||||
NIP-37
|
||||
======
|
||||
|
||||
Event Publication Onion-routing
|
||||
-----------------
|
||||
|
||||
`draft` `optional`
|
||||
|
||||
This NIP defines a way to do onion-based routing for event publishing, optionally compensated with cashu where pubkeys (not necessarily relays) provide routing services.
|
||||
|
||||
## Announcement
|
||||
A pubkey announces itself as willing to route by publishing an ephemeral event `kind:20690` in their outbox relays. Announcers should republish a new ephemeral event every few minutes to indicate they are still willing to route and online. The refresh rate depends on the relays where they are publishing (usually ~5 minutes).
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 20690,
|
||||
"tags": [
|
||||
[ "relay", "wss://example1.com" ],
|
||||
[ "relay", "wss://example2.com" ],
|
||||
[ "fee", "1", "sat" ]
|
||||
],
|
||||
"content": "",
|
||||
"pubkey": <pubkey-of-router>
|
||||
}
|
||||
```
|
||||
|
||||
Tags:
|
||||
`relay` -- relay(s) where the pubkey will be listening for requests.
|
||||
`fee` -- an optional fee indicating how much money the pubkey demands to be paid.
|
||||
|
||||
## Routing request
|
||||
A sender publishes a series of `kind:2444` or `kind:20444` where the `payload` is the event that should be published by the pubkey of the current hop in the relays specified by the envelope. An optional proof can be included, this cashu proof is for the hop processing this route.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 20444,
|
||||
"content": nip44_encrypt("{
|
||||
'relays': [ 'wss://example1.com' ],
|
||||
'event': { 'id': ...., sig: ..., }, // event the current routing pubkey should publish
|
||||
'proof': <optional-unencoded-cashu-proof>,
|
||||
'mint': 'https://mint.com',
|
||||
'unit': 'sat'
|
||||
}")
|
||||
"tags": [
|
||||
[ "p", "pubkey-of-next-hop" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Event `kind:2444` has the exact same format as the `kind:20444`, the only difference being that it's not ephemeral, so it can be used to route events that are expected to take longer to route. `kind:2444` events SHOULD include an [[NIP-40]] `expiration` tag.
|
||||
|
||||
Routing pubkeys MUST look at the `created_at` of the event they need to publish and wait until at least that time before publishing. Using future `created_at`s allows the sender to increase their privacy by preventing timing analysis by mixing different time delays at each hop.
|
||||
|
||||
When a routing pubkey receives a routing request event it should decrypt the content, redeem the cashu and publish the event in the `event` field. If the cashu cannot be redeemed the routing pubkey MUST NOT publish the event. This is useful as a way to **cancel** a routing event where the sender uses a future `created_at` timestamps and chooses to cancel the publication.
|
||||
|
||||
## Constructing a route
|
||||
The sender:
|
||||
|
||||
1. looks for `kind:20400` announcements and assembles a path
|
||||
2. creates the event they want to publish and sign it with their normal pubkey
|
||||
|
||||
3. walks the path backwards (finish -> start), putting the event signed in the previous step in the `event` field of the `content` and the other fileds of the envelope
|
||||
4. encrypts to the current hop and signs -- both operations with a new disposable key and `p`-tags the current hop.
|
||||
3. repeat step #3 and #4 for the rest of the route until the first hop
|
||||
4. sender publishes the resulting event to one of the relays the first hop indicated it's active on
|
||||
|
||||
## Pseudocode implementation
|
||||
```ts
|
||||
// event to be published
|
||||
event = { "kind": 1, content: "This is an onion-routed event" }
|
||||
sign_event(event, my_private_key)
|
||||
outer_layer = assemble_onion_route(event, [ "pubkey-A", "pubkey-B", "pubkey-C" ])
|
||||
publish_event(outer_layer)
|
||||
|
||||
function assemble_onion_route(final_event, path) {
|
||||
current_event = final_event // Start with the event to be published by the final hop
|
||||
|
||||
// Walk the path backwards from "C" to "A"
|
||||
for hop_pubkey in reverse(path): // path = ["A", "B", "C"], reversed to ["C", "B", "A"]
|
||||
// Generate a new disposable key for this hop
|
||||
disposable_key = generate_disposable_key()
|
||||
|
||||
// Create the payload for this hop
|
||||
payload = {
|
||||
"event": current_event // The event for the hop to publish
|
||||
// ...
|
||||
}
|
||||
|
||||
// Encrypt the payload for the current hop
|
||||
encrypted_payload = nip44_encrypt(payload, hop_pubkey) // Encrypt with the hop's pubkey
|
||||
|
||||
// Create the routing event for this hop
|
||||
routing_event = {
|
||||
"kind": 20444, // Ephemeral routing request
|
||||
"content": encrypted_payload, // The encrypted payload for this hop
|
||||
"tags": [["p", hop_pubkey]] // Tag indicating the pubkey of the next hop
|
||||
}
|
||||
|
||||
// Sign the event with the disposable key for this hop
|
||||
sign_event(routing_event, disposable_key)
|
||||
|
||||
// Prepare for the next hop (wrap another layer)
|
||||
current_event = routing_event
|
||||
}
|
||||
|
||||
return current_event // Return the fully wrapped outermost event ready to be published
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## Example anatomy of a sequence of routing events
|
||||
|
||||
```jsonc
|
||||
{
|
||||
kind: 20444,
|
||||
content: nip44_encrypt({
|
||||
relays: [...],
|
||||
event: {
|
||||
"id": ...,
|
||||
"kind": 20444,
|
||||
"pubkey": "ephemeral-key-1",
|
||||
"sig": ...,
|
||||
content: nip44_encrypt({
|
||||
relays: [....],
|
||||
event: {
|
||||
"id": ....,
|
||||
"kind": 20444,
|
||||
"pubkey": "ephemeral-key-2",
|
||||
"sig": ...,
|
||||
"content": nip44_encrypt({
|
||||
relays: [ "wss://target-relay.com" ],
|
||||
event: {
|
||||
id: ...,
|
||||
"kind": 1,
|
||||
content: "This is an onion-routed event",
|
||||
"pubkey": "real-pubkey",
|
||||
"sig": ...,
|
||||
}
|
||||
})
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
85
46.md
85
46.md
@@ -4,10 +4,6 @@ NIP-46
|
||||
Nostr Remote Signing
|
||||
--------------------
|
||||
|
||||
## Changes
|
||||
|
||||
`remote-signer-key` is introduced, passed in bunker url, clients must differentiate between `remote-signer-pubkey` and `user-pubkey`, must call `get_public_key` after connect.
|
||||
|
||||
## Rationale
|
||||
|
||||
Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface.
|
||||
@@ -16,53 +12,51 @@ This NIP describes a method for 2-way communication between a remote signer and
|
||||
|
||||
## Terminology
|
||||
|
||||
- **user**: A person that is trying to use Nostr.
|
||||
- **client**: A user-facing application that _user_ is looking at and clicking buttons in. This application will send requests to _remote-signer_.
|
||||
- **remote-signer**: A daemon or server running somewhere that will answer requests from _client_, also known as "bunker".
|
||||
- **client-keypair/pubkey**: The keys generated by _client_. Used to encrypt content and communicate with _remote-signer_.
|
||||
- **remote-signer-keypair/pubkey**: The keys used by _remote-signer_ to encrypt content and communicate with _client_. This keypair MAY be same as _user-keypair_, but not necessarily.
|
||||
- **user-keypair/pubkey**: The actual keys representing _user_ (that will be used to sign events in response to `sign_event` requests, for example). The _remote-signer_ generally has control over these keys.
|
||||
- **Local keypair**: A local public and private key-pair used to encrypt content and communicate with the remote signer. Usually created by the client application.
|
||||
- **Remote user pubkey**: The public key that the user wants to sign as. The remote signer has control of the private key that matches this public key.
|
||||
- **Remote signer pubkey**: This is the public key of the remote signer itself. This is needed in both `create_account` command because you don't yet have a remote user pubkey.
|
||||
|
||||
All pubkeys specified in this NIP are in hex format.
|
||||
|
||||
## Initiating a connection
|
||||
|
||||
There are two ways to initiate a connection:
|
||||
To initiate a connection between a client and a remote signer there are a few different options.
|
||||
|
||||
### Direct connection initiated by _remote-signer_
|
||||
### Direct connection initiated by remote signer
|
||||
|
||||
_remote-signer_ provides connection token in the form:
|
||||
This is most common in a situation where you have your own nsecbunker or other type of remote signer and want to connect through a client that supports remote signing.
|
||||
|
||||
The remote signer would provide a connection token in the form:
|
||||
|
||||
```
|
||||
bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
|
||||
bunker://<remote-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
|
||||
```
|
||||
|
||||
_user_ pastes this token on _client_, which then uses the details to connect to _remote-signer_ via the specified relays. Optional secret can be used for single successfully established connection only, _remote-signer_ SHOULD ignore new attempts to establish connection with old optional secret.
|
||||
This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s). Optional secret can be used for single successfully established connection only, remote signer SHOULD ignore new attempts to establish connection with old optional secret.
|
||||
|
||||
### Direct connection initiated by the client
|
||||
|
||||
In this case, basically the opposite direction of the first case, _client_ provides a connection token (or encodes the token in a QR code) and _remote-signer_ initiates a connection via the specified relays.
|
||||
In this case, basically the opposite direction of the first case, the client provides a connection token (or encodes the token in a QR code) and the signer initiates a connection to the client via the specified relay(s).
|
||||
|
||||
```
|
||||
nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata in the form: {"name":"...", "url": "...", "description": "..."}>
|
||||
nostrconnect://<local-keypair-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata in the form: {"name":"...", "url": "...", "description": "..."}>
|
||||
```
|
||||
|
||||
## The flow
|
||||
|
||||
1. _client_ generates `client-keypair`. This keypair doesn't need to be communicated to _user_ since it's largely disposable. _client_ might choose to store it locally and they should delete it on logout;
|
||||
2. _client_ gets `remote-signer-pubkey` (either via a `bunker://` connection string or a NIP-05 login-flow; shown below);
|
||||
3. _client_ use `client-keypair` to send requests to _remote-signer_ by `p`-tagging and encrypting to `remote-signer-pubkey`;
|
||||
4. _remote-signer_ responds to _client_ by `p`-tagging and encrypting to the `client-pubkey`.
|
||||
1. Client creates a local keypair. This keypair doesn't need to be communicated to the user since it's largely disposable (i.e. the user doesn't need to see this pubkey). Clients might choose to store it locally and they should delete it when the user logs out.
|
||||
2. Client gets the remote user pubkey (either via a `bunker://` connection string or a NIP-05 login-flow; shown below)
|
||||
3. Clients use the local keypair to send requests to the remote signer by `p`-tagging and encrypting to the remote user pubkey.
|
||||
4. The remote signer responds to the client by `p`-tagging and encrypting to the local keypair pubkey.
|
||||
|
||||
### Example flow for signing an event
|
||||
|
||||
- `remote-signer-pubkey` is `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`
|
||||
- `user-pubkey` is also `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`
|
||||
- `client-pubkey` is `eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86`
|
||||
- Remote user pubkey (e.g. signing as) `fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52`
|
||||
- Local pubkey is `eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86`
|
||||
|
||||
#### Signature request
|
||||
|
||||
```js
|
||||
```json
|
||||
{
|
||||
"kind": 24133,
|
||||
"pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
|
||||
@@ -76,13 +70,13 @@ nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json
|
||||
created_at: 1714078911
|
||||
}>)]
|
||||
}),
|
||||
"tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote-signer-pubkey
|
||||
"tags": [["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]], // p-tags the remote user pubkey
|
||||
}
|
||||
```
|
||||
|
||||
#### Response event
|
||||
|
||||
```js
|
||||
```json
|
||||
{
|
||||
"kind": 24133,
|
||||
"pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
|
||||
@@ -90,7 +84,7 @@ nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json
|
||||
"id": <random_string>,
|
||||
"result": json_stringified(<signed-event>)
|
||||
}),
|
||||
"tags": [["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]], // p-tags the client-pubkey
|
||||
"tags": [["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]], // p-tags the local keypair pubkey
|
||||
}
|
||||
```
|
||||
|
||||
@@ -100,18 +94,20 @@ nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json
|
||||
|
||||
## Request Events `kind: 24133`
|
||||
|
||||
```js
|
||||
```jsonc
|
||||
{
|
||||
"id": <id>,
|
||||
"kind": 24133,
|
||||
"pubkey": <local_keypair_pubkey>,
|
||||
"content": <nip04(<request>)>,
|
||||
"tags": [["p", <remote-signer-pubkey>]],
|
||||
"tags": [["p", <remote_user_pubkey>]], // NB: in the `create_account` event, the remote signer pubkey should be `p` tagged.
|
||||
"created_at": <unix timestamp in seconds>
|
||||
}
|
||||
```
|
||||
|
||||
The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
|
||||
|
||||
```jsonc
|
||||
```json
|
||||
{
|
||||
"id": <random_string>,
|
||||
"method": <method_name>,
|
||||
@@ -129,16 +125,15 @@ Each of the following are methods that the client sends to the remote signer.
|
||||
|
||||
| Command | Params | Result |
|
||||
| ------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------- |
|
||||
| `connect` | `[<user_pubkey>, <optional_secret>, <optional_requested_permissions>]` | "ack" |
|
||||
| `connect` | `[<remote_user_pubkey>, <optional_secret>, <optional_requested_permissions>]` | "ack" |
|
||||
| `sign_event` | `[<{kind, content, tags, created_at}>]` | `json_stringified(<signed_event>)` |
|
||||
| `ping` | `[]` | "pong" |
|
||||
| `get_relays` | `[]` | `json_stringified({<relay_url>: {read: <boolean>, write: <boolean>}})` |
|
||||
| `get_public_key` | `[]` | `<user-pubkey>` |
|
||||
| `get_public_key` | `[]` | `<hex-pubkey>` |
|
||||
| `nip04_encrypt` | `[<third_party_pubkey>, <plaintext_to_encrypt>]` | `<nip04_ciphertext>` |
|
||||
| `nip04_decrypt` | `[<third_party_pubkey>, <nip04_ciphertext_to_decrypt>]` | `<plaintext>` |
|
||||
| `nip44_encrypt` | `[<third_party_pubkey>, <plaintext_to_encrypt>]` | `<nip44_ciphertext>` |
|
||||
| `nip44_decrypt` | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]` | `<plaintext>` |
|
||||
| `create_account` | `[<username>, <domain>, <optional_email>, <optional_requested_permissions>]` | `<newly_created_user_pubkey>` |
|
||||
|
||||
### Requested permissions
|
||||
|
||||
@@ -150,9 +145,9 @@ The `connect` method may be provided with `optional_requested_permissions` for u
|
||||
{
|
||||
"id": <id>,
|
||||
"kind": 24133,
|
||||
"pubkey": <remote-signer-pubkey>,
|
||||
"pubkey": <remote_signer_pubkey>,
|
||||
"content": <nip04(<response>)>,
|
||||
"tags": [["p", <client-pubkey>]],
|
||||
"tags": [["p", <local_keypair_pubkey>]],
|
||||
"created_at": <unix timestamp in seconds>
|
||||
}
|
||||
```
|
||||
@@ -189,6 +184,18 @@ Clients should display (in a popup or new tab) the URL from the `error` field an
|
||||
|
||||
|
||||
|
||||
## Remote Signer Commands
|
||||
|
||||
Remote signers might support additional commands when communicating directly with it. These commands follow the same flow as noted above, the only difference is that when the client sends a request event, the `p`-tag is the pubkey of the remote signer itself and the `content` payload is encrypted to the same remote signer pubkey.
|
||||
|
||||
### Methods/Commands
|
||||
|
||||
Each of the following are methods that the client sends to the remote signer.
|
||||
|
||||
| Command | Params | Result |
|
||||
| ---------------- | ------------------------------------------ | ------------------------------------ |
|
||||
| `create_account` | `[<username>, <domain>, <optional_email>, <optional_requested_permissions>]` | `<newly_created_remote_user_pubkey>` |
|
||||
|
||||
## Appendix
|
||||
|
||||
### NIP-05 Login Flow
|
||||
@@ -197,7 +204,7 @@ Clients might choose to present a more familiar login flow, so users can type a
|
||||
|
||||
When the user types a NIP-05 the client:
|
||||
|
||||
- Queries the `/.well-known/nostr.json` file from the domain for the NIP-05 address provided to get the user's pubkey (this is the `user-pubkey`)
|
||||
- Queries the `/.well-known/nostr.json` file from the domain for the NIP-05 address provided to get the user's pubkey (this is the **remote user pubkey**)
|
||||
- In the same `/.well-known/nostr.json` file, queries for the `nip46` key to get the relays that the remote signer will be listening on.
|
||||
- Now the client has enough information to send commands to the remote signer on behalf of the user.
|
||||
|
||||
@@ -209,9 +216,9 @@ In this last case, most often used to facilitate an OAuth-like signin flow, the
|
||||
|
||||
First the client will query for `kind: 31990` events that have a `k` tag of `24133`.
|
||||
|
||||
These are generally shown to a user, and once the user selects which remote signer to use and provides the `user-pubkey` they want to use (via npub, pubkey, or nip-05 value), the client can initiate a connection. Note that it's on the user to select the _remote-signer_ that is actually managing the `user-keypair` that they would like to use in this case. If the `user-pubkey` is managed on another _remote-signer_ the connection will fail.
|
||||
These are generally shown to a user, and once the user selects which remote signer to use and provides the remote user pubkey they want to use (via npub, pubkey, or nip-05 value), the client can initiate a connection. Note that it's on the user to select the remote signer that is actually managing the remote key that they would like to use in this case. If the remote user pubkey is managed on another remote signer, the connection will fail.
|
||||
|
||||
In addition, it's important that clients validate that the pubkey of the announced _remote-signer_ matches the pubkey of the `_` entry in the `/.well-known/nostr.json` file of the remote signer's announced domain.
|
||||
In addition, it's important that clients validate that the pubkey of the announced remote signer matches the pubkey of the `_` entry in the `/.well-known/nostr.json` file of the remote signer's announced domain.
|
||||
|
||||
Clients that allow users to create new accounts should also consider validating the availability of a given username in the namespace of remote signer's domain by checking the `/.well-known/nostr.json` file for existing usernames. Clients can then show users feedback in the UI before sending a `create_account` event to the remote signer and receiving an error in return. Ideally, remote signers would also respond with understandable error messages if a client tries to create an account with an existing username.
|
||||
|
||||
|
||||
97
55.md
97
55.md
@@ -53,8 +53,8 @@ val launcher = rememberLauncherForActivityResult(
|
||||
Toast.LENGTH_SHORT
|
||||
).show()
|
||||
} else {
|
||||
val result = activityResult.data?.getStringExtra("result")
|
||||
// Do something with result ...
|
||||
val signature = activityResult.data?.getStringExtra("signature")
|
||||
// Do something with signature ...
|
||||
}
|
||||
}
|
||||
)
|
||||
@@ -72,35 +72,6 @@ Set the Signer package name:
|
||||
intent.`package` = "com.example.signer"
|
||||
```
|
||||
|
||||
If you are sending multiple intents without awaiting you can add some intent flags to sign all events without opening multiple times the signer
|
||||
|
||||
```kotlin
|
||||
intent.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP or Intent.FLAG_ACTIVITY_CLEAR_TOP)
|
||||
```
|
||||
|
||||
If you are developing a signer application them you need to add this to your AndroidManifest.xml so clients can use the intent flags above
|
||||
|
||||
```kotlin
|
||||
android:launchMode="singleTop"
|
||||
```
|
||||
|
||||
Signer MUST answer multiple permissions with an array of results
|
||||
|
||||
```kotlin
|
||||
|
||||
val results = listOf(
|
||||
Result(
|
||||
package = signerPackageName,
|
||||
result = eventSignture,
|
||||
id = intentId
|
||||
)
|
||||
)
|
||||
|
||||
val json = results.toJson()
|
||||
|
||||
intent.putExtra("results", json)
|
||||
```
|
||||
|
||||
Send the Intent:
|
||||
|
||||
```kotlin
|
||||
@@ -130,10 +101,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **pubkey** in the result field
|
||||
- If the user approved intent it will return the **pubkey** in the signature field
|
||||
|
||||
```kotlin
|
||||
val pubkey = intent.data?.getStringExtra("result")
|
||||
val pubkey = intent.data?.getStringExtra("signature")
|
||||
// The package name of the signer application
|
||||
val packageName = intent.data?.getStringExtra("package")
|
||||
```
|
||||
@@ -153,10 +124,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **result**, **id** and **event** fields
|
||||
- If the user approved intent it will return the **signature**, **id** and **event** fields
|
||||
|
||||
```kotlin
|
||||
val signature = intent.data?.getStringExtra("result")
|
||||
val signature = intent.data?.getStringExtra("signature")
|
||||
// The id you sent
|
||||
val id = intent.data?.getStringExtra("id")
|
||||
val signedEventJson = intent.data?.getStringExtra("event")
|
||||
@@ -179,10 +150,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **result** and **id** fields
|
||||
- If the user approved intent it will return the **signature** and **id** fields
|
||||
|
||||
```kotlin
|
||||
val encryptedText = intent.data?.getStringExtra("result")
|
||||
val encryptedText = intent.data?.getStringExtra("signature")
|
||||
// the id you sent
|
||||
val id = intent.data?.getStringExtra("id")
|
||||
```
|
||||
@@ -229,10 +200,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **result** and **id** fields
|
||||
- If the user approved intent it will return the **signature** and **id** fields
|
||||
|
||||
```kotlin
|
||||
val plainText = intent.data?.getStringExtra("result")
|
||||
val plainText = intent.data?.getStringExtra("signature")
|
||||
// the id you sent
|
||||
val id = intent.data?.getStringExtra("id")
|
||||
```
|
||||
@@ -254,10 +225,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **result** and **id** fields
|
||||
- If the user approved intent it will return the **signature** and **id** fields
|
||||
|
||||
```kotlin
|
||||
val plainText = intent.data?.getStringExtra("result")
|
||||
val plainText = intent.data?.getStringExtra("signature")
|
||||
// the id you sent
|
||||
val id = intent.data?.getStringExtra("id")
|
||||
```
|
||||
@@ -277,10 +248,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **result** and **id** fields
|
||||
- If the user approved intent it will return the **signature** and **id** fields
|
||||
|
||||
```kotlin
|
||||
val relayJsonText = intent.data?.getStringExtra("result")
|
||||
val relayJsonText = intent.data?.getStringExtra("signature")
|
||||
// the id you sent
|
||||
val id = intent.data?.getStringExtra("id")
|
||||
```
|
||||
@@ -299,10 +270,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **result** and **id** fields
|
||||
- If the user approved intent it will return the **signature** and **id** fields
|
||||
|
||||
```kotlin
|
||||
val eventJson = intent.data?.getStringExtra("result")
|
||||
val eventJson = intent.data?.getStringExtra("signature")
|
||||
// the id you sent
|
||||
val id = intent.data?.getStringExtra("id")
|
||||
```
|
||||
@@ -313,9 +284,9 @@ To get the result back from Signer Application you should use contentResolver.qu
|
||||
|
||||
If the user did not check the "remember my choice" option, the pubkey is not in Signer Application or the signer type is not recognized the `contentResolver` will return null
|
||||
|
||||
For the SIGN_EVENT type Signer Application returns two columns "result" and "event". The column event is the signed event json
|
||||
For the SIGN_EVENT type Signer Application returns two columns "signature" and "event". The column event is the signed event json
|
||||
|
||||
For the other types Signer Application returns the column "result"
|
||||
For the other types Signer Application returns the column "signature"
|
||||
|
||||
If the user chose to always reject the event, signer application will return the column "rejected" and you should not open signer application
|
||||
|
||||
@@ -334,13 +305,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **pubkey** in the result column
|
||||
- Will return the **pubkey** in the signature column
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
if (index < 0) return
|
||||
val pubkey = it.getString(index)
|
||||
}
|
||||
@@ -359,13 +330,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **result** and the **event** columns
|
||||
- Will return the **signature** and the **event** columns
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
val indexJson = it.getColumnIndex("event")
|
||||
val signature = it.getString(index)
|
||||
val eventJson = it.getString(indexJson)
|
||||
@@ -385,13 +356,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **result** column
|
||||
- Will return the **signature** column
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
val encryptedText = it.getString(index)
|
||||
}
|
||||
```
|
||||
@@ -409,13 +380,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **result** column
|
||||
- Will return the **signature** column
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
val encryptedText = it.getString(index)
|
||||
}
|
||||
```
|
||||
@@ -433,13 +404,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **result** column
|
||||
- Will return the **signature** column
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
val encryptedText = it.getString(index)
|
||||
}
|
||||
```
|
||||
@@ -457,13 +428,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **result** column
|
||||
- Will return the **signature** column
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
val encryptedText = it.getString(index)
|
||||
}
|
||||
```
|
||||
@@ -481,13 +452,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **result** column
|
||||
- Will return the **signature** column
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
val relayJsonText = it.getString(index)
|
||||
}
|
||||
```
|
||||
@@ -505,13 +476,13 @@ If the user chose to always reject the event, signer application will return the
|
||||
)
|
||||
```
|
||||
- result:
|
||||
- Will return the **result** column
|
||||
- Will return the **signature** column
|
||||
|
||||
```kotlin
|
||||
if (result == null) return
|
||||
|
||||
if (result.moveToFirst()) {
|
||||
val index = it.getColumnIndex("result")
|
||||
val index = it.getColumnIndex("signature")
|
||||
val eventJson = it.getString(index)
|
||||
}
|
||||
```
|
||||
|
||||
213
60.md
213
60.md
@@ -1,213 +0,0 @@
|
||||
# NIP-60
|
||||
## Cashu Wallet
|
||||
`draft` `optional`
|
||||
|
||||
This NIP defines the operations of a cashu-based wallet.
|
||||
|
||||
A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.
|
||||
|
||||
The purpose of this NIP is:
|
||||
* ease-of-use: new users immediately are able to receive funds without creating accounts with other services.
|
||||
* interoperability: users' wallets follows them across applications.
|
||||
|
||||
This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet.
|
||||
|
||||
# Event Kinds
|
||||
- `kind:37375` contains relevant info for a wallet. Clients **SHOULD** check the current info event when loading the wallet.
|
||||
- `kind:7373` wallet's reserved proofs. The proofs **MUST** be nip44-encrypted with the user's private key.
|
||||
- `kind:7374` tracks pending quotes from a mint. This event **MAY** be used to keep track of the quote ID and its expiration.
|
||||
- `kind:7375` represents the wallet's unspent proofs. The proofs **MUST** be nip44-encrypted with the user's private key.
|
||||
- `kind:7376` provides the wallet's transaction history. The history is provided only for informational purposes and is not part of the wallet state.
|
||||
|
||||
## Wallet Event
|
||||
```jsonc
|
||||
{
|
||||
"kind": 37375,
|
||||
"content": nip44_encrypt([
|
||||
[ "balance", "100", "sat" ],
|
||||
[ "privkey", "hexkey" ] // explained in NIP-61
|
||||
]),
|
||||
"tags": [
|
||||
[ "d", "my-wallet" ],
|
||||
[ "mint", "https://mint1" ],
|
||||
[ "mint", "https://mint2" ],
|
||||
[ "mint", "https://mint3" ],
|
||||
[ "name", "my shitposting wallet" ],
|
||||
[ "unit", "sat" ],
|
||||
[ "description", "a wallet for my day-to-day shitposting" ],
|
||||
[ "relay", "wss://relay1" ],
|
||||
[ "relay", "wss://relay2" ],
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The wallet event is a parameterized replaceable event `kind:37375`.
|
||||
|
||||
Tags:
|
||||
* `d` - wallet ID.
|
||||
* `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
|
||||
* `relay` - Relays where the wallet and related events can be found. -- one ore more relays SHOULD be specified. If missing, clients should follow [[NIP-65]].
|
||||
* `unit` - Base unit of the wallet (e.g. "sat", "usd", etc).
|
||||
* `name` - Optional human-readable name for the wallet.
|
||||
* `description` - Optional human-readable description of the wallet.
|
||||
* `balance` - Optional best-effort balance of the wallet that can serve as a placeholder while an accurate balance is computed from fetching all unspent proofs.
|
||||
* `privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's nostr private key** -- This is only used when receiving funds from others, described in NIP-61.
|
||||
|
||||
Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content` field.
|
||||
|
||||
### Deleting a wallet event
|
||||
Due to PRE being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
|
||||
|
||||
## Token Event
|
||||
Token events are used to store proofs of a wallet.
|
||||
|
||||
There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 7375,
|
||||
"content": nip44_encrypt({
|
||||
"mint": "https://stablenut.umint.cash",
|
||||
"proofs": [
|
||||
{
|
||||
"id": "005c2502034d4f12",
|
||||
"amount": 1,
|
||||
"secret": "z+zyxAVLRqN9lEjxuNPSyRJzEstbl69Jc1vtimvtkPg=",
|
||||
"C": "0241d98a8197ef238a192d47edf191a9de78b657308937b4f7dd0aa53beae72c46"
|
||||
}
|
||||
]
|
||||
}),
|
||||
"tags": [
|
||||
[ "a", "37375:<pubkey>:my-wallet" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
`.content` is a [[NIP-44]] encrypted payload storing the mint and the unencoded proofs.
|
||||
* `a` an optional tag linking the token to a specific wallet.
|
||||
|
||||
### Spending proofs
|
||||
When one or more proofs of a token are spent, the token event should be [[NIP-09]]-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event.
|
||||
|
||||
### Reserving proofs
|
||||
A wallet can reserve proofs by deleting them from a `kind:7375` event and creating a `kind:7373` event. `kind:7373` and `kind:7375` events have the same structure.
|
||||
|
||||
## Spending History Event
|
||||
Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 7376,
|
||||
"content": nip44_encrypt([
|
||||
[ "direction", "in" ], // in = received, out = sent
|
||||
[ "amount", "1", "sat" ],
|
||||
[ "e", "<event-id-of-spent-token>", "<relay-hint>", "created" ],
|
||||
]),
|
||||
"tags": [
|
||||
[ "a", "37375:<pubkey>:my-wallet" ],
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
* `direction` - The direction of the transaction; `in` for received funds, `out` for sent funds.
|
||||
* `a` - The wallet the transaction is related to.
|
||||
|
||||
Clients MUST add `e` tags to create references of destroyed and created token events along with the marker of the meaning of the tag:
|
||||
* `created` - A new token event was created.
|
||||
* `destroyed` - A token event was destroyed.
|
||||
* `redeemed` - A [[NIP-61]] nutzap was redeemed.
|
||||
|
||||
All tags can be [[NIP-44]] encrypted. Clients SHOULD leave `e` tags with a `redeemed` marker unencrypted.
|
||||
|
||||
Multiple `e` tags can be added to a `kind:7376` event.
|
||||
|
||||
# Flow
|
||||
A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [[NIP-65]] relays.
|
||||
|
||||
## Fetch wallet and token list
|
||||
From those relays, the client should fetch wallet and token events.
|
||||
|
||||
`"kinds": [37375, 7375], "authors": ["<my-pubkey>"]`
|
||||
|
||||
## Fetch proofs
|
||||
While the client is fetching (and perhaps validating) proofs it can use the optional `balance` tag of the wallet event to display a estimate of the balance of the wallet.
|
||||
|
||||
## Spending token
|
||||
If Alice spends 4 sats from this token event
|
||||
```jsonconc
|
||||
{
|
||||
"kind": 7375,
|
||||
"id": "event-id-1",
|
||||
"content": nip44_encrypt({
|
||||
"mint": "https://stablenut.umint.cash",
|
||||
"proofs": [
|
||||
{ "id": "1", "amount": 1 },
|
||||
{ "id": "2", "amount": 2 },
|
||||
{ "id": "3", "amount": 4 },
|
||||
{ "id": "4", "amount": 8 },
|
||||
]
|
||||
}),
|
||||
"tags": [
|
||||
[ "a", "37375:<pubkey>:my-wallet" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Her client:
|
||||
* MUST roll over the unspent proofs:
|
||||
```jsonconc
|
||||
{
|
||||
"kind": 7375,
|
||||
"id": "event-id-2",
|
||||
"content": nip44_encrypt({
|
||||
"mint": "https://stablenut.umint.cash",
|
||||
"proofs": [
|
||||
{ "id": "1", "amount": 1 },
|
||||
{ "id": "2", "amount": 2 },
|
||||
{ "id": "4", "amount": 8 },
|
||||
]
|
||||
}),
|
||||
"tags": [
|
||||
[ "a", "37375:<pubkey>:my-wallet" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
* MUST delete event `event-id-1`
|
||||
* SHOULD create a `kind:7376` event to record the spend
|
||||
```jsonconc
|
||||
{
|
||||
"kind": 7376,
|
||||
"content": nip44_encrypt([
|
||||
[ "direction", "out" ],
|
||||
[ "amount", "4", "sats" ],
|
||||
[ "e", "<event-id-1>", "<relay-hint>", "destroyed" ],
|
||||
[ "e", "<event-id-2>", "<relay-hint>", "created" ],
|
||||
]),
|
||||
"tags": [
|
||||
[ "a", "37375:<pubkey>:my-wallet" ],
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Redeeming a quote (optional)
|
||||
When creating a quote at a mint, an event can be used to keep the state of the quote ID, which will be used to check when the quote has been paid. These events should be created with an expiration tag [[NIP-40]] matching the expiration of the bolt11 received from the mint; this signals to relays when they can safely discard these events.
|
||||
|
||||
Application developers are encouraged to use local state when possible and only publish this event when it makes sense in the context of their application.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 7374,
|
||||
"content": nip44_encrypt("quote-id"),
|
||||
"tags": [
|
||||
[ "expiration", "<expiration-timestamp>" ],
|
||||
[ "mint", "<mint-url>" ],
|
||||
[ "a", "37375:<pubkey>:my-wallet" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Appendix 1: Validating proofs
|
||||
Clients can optionally validate proofs to make sure they are not working from an old state; this logic is left up to particular implementations to decide when and why to do it, but if some proofs are checked and deemed to have been spent, the client should delete the token and roll over any unspent proof.
|
||||
|
||||
## Appendix 2: Validating relays
|
||||
Clients might want to optionally check that the relays the user chooses to store the proofs respond well to [[NIP-09]] event deletion requests and, periodically, check that the different relays are consistent with the state they report. These checks are left up to particular implementations to decide when and why to do them.
|
||||
132
61.md
132
61.md
@@ -1,132 +0,0 @@
|
||||
# NIP-61:
|
||||
## Nut Zaps
|
||||
|
||||
A Nut Zap is a P2PK cashu token where the payment itself is the receipt.
|
||||
|
||||
# High-level flow
|
||||
Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
|
||||
|
||||
## Alice nutzaps Bob
|
||||
1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
|
||||
2. She mints a token at that mint (or swaps some tokens she already had in that mint) p2pk-locked to the pubkey Bob has listed in his `kind:10019`.
|
||||
3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
|
||||
|
||||
## Bob receives the nutzap
|
||||
1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
|
||||
2. Bob's client swaps the token into his wallet.
|
||||
|
||||
# Nutzap informational event
|
||||
```jsonc
|
||||
{
|
||||
"kind": 10019,
|
||||
"tags": [
|
||||
[ "relay", "wss://relay1" ],
|
||||
[ "relay", "wss://relay2" ],
|
||||
[ "mint", "https://mint1", "usd", "sat" ],
|
||||
[ "mint", "https://mint2", "sat" ],
|
||||
[ "pubkey", "<p2pk-pubkey>" ]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
`kind:10019` is an event that is useful for others to know how to send money to the user.
|
||||
|
||||
* `relay` - Relays where the user will be reading token events from. If a user wants to send money to the user, they should write to these relays.
|
||||
* `mint` - Mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
|
||||
* `pubkey` - Pubkey that SHOULD be used to P2PK-lock receiving nutzaps. If not present, clients SHOULD use the pubkey of the recipient. This is explained in Appendix 1.
|
||||
|
||||
## Nutzap event
|
||||
Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the pubkey the recipient indicated in their `kind:10019` event or to the recipient pubkey if the `kind:10019` event doesn't have a explicit pubkey.
|
||||
|
||||
Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
|
||||
|
||||
```jsonc
|
||||
{
|
||||
kind: 9321,
|
||||
content: "Thanks for this great idea.",
|
||||
pubkey: "sender-pubkey",
|
||||
tags: [
|
||||
[ "amount", "1" ],
|
||||
[ "unit", "sat" ],
|
||||
[ "proof", "{\"amount\":1,\"C\":\"02277c66191736eb72fce9d975d08e3191f8f96afb73ab1eec37e4465683066d3f\",\"id\":\"000a93d6f8a1d2c4\",\"secret\":\"[\\\"P2PK\\\",{\\\"nonce\\\":\\\"b00bdd0467b0090a25bdf2d2f0d45ac4e355c482c1418350f273a04fedaaee83\\\",\\\"data\\\":\\\"02eaee8939e3565e48cc62967e2fde9d8e2a4b3ec0081f29eceff5c64ef10ac1ed\\\"}]\"}" ],
|
||||
[ "u", "https://stablenut.umint.cash", ],
|
||||
[ "e", "<zapped-event-id>", "<relay-hint>" ],
|
||||
[ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nut zap
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
* `.content` is an optional comment for the nutzap
|
||||
* `amount` is a shorthand for the combined amount of all outputs. -- Clients SHOULD validate that the sum of the amounts in the outputs matches.
|
||||
* `unit` is the base unit of the amount.
|
||||
* `proof` is one ore more proofs p2pk-locked to the pubkey the recipient specified in their `kind:10019` event.
|
||||
* `u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
|
||||
* `e` zero or one event that is being nutzapped.
|
||||
* `p` exactly one pubkey, specifying the recipient of the nutzap.
|
||||
|
||||
WIP: Clients SHOULD embed a DLEQ proof in the nutzap event to make it possible to verify nutzaps without talking to the mint.
|
||||
|
||||
# Sending a nutzap
|
||||
|
||||
* The sender fetches the recipient's `kind:10019`.
|
||||
* The sender mints/swaps ecash on one of the recipient's listed mints.
|
||||
* The sender p2pk locks to the recipient's specified pubkey in their
|
||||
|
||||
# Receiving nutzaps
|
||||
|
||||
Clients should REQ for nut zaps:
|
||||
* Filtering with `#u` for mints they expect to receive ecash from.
|
||||
* this is to prevent even interacting with mints the user hasn't explicitly signaled.
|
||||
* Filtering with `since` of the most recent `kind:7376` event the same user has created.
|
||||
* this can be used as a marker of the nut zaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
|
||||
|
||||
Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.
|
||||
|
||||
`{ "kinds": [9321], "#p": "my-pubkey", "#u": [ "<mint-1>", "<mint-2>"], "since": <latest-created_at-of-kind-7376> }`.
|
||||
|
||||
Upon receiving a new nut zap, the client should swap the tokens into a wallet the user controls, either a [[NIP-60]] wallet, their own LN wallet or anything else.
|
||||
|
||||
## Updating nutzap-redemption history
|
||||
When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nut zap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.
|
||||
|
||||
Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 7376,
|
||||
"content": nip44_encrypt([
|
||||
[ "direction", "in" ], // in = received, out = sent
|
||||
[ "amount", "1", "sat" ],
|
||||
[ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
|
||||
]),
|
||||
"tags": [
|
||||
[ "a", "37375:<pubkey>:my-wallet" ], // an optional wallet tag
|
||||
[ "e", "<9321-event-id>", "relay-hint", "redeemed" ], // nutzap event that has been redeemed
|
||||
[ "p", "sender-pubkey" ] // pubkey of the author of the 9321 event (nutzap sender)
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Events that redeem a nutzap SHOULD be published to the sender's [[NIP-65]] relays.
|
||||
|
||||
## Verifying a Cashu Zap
|
||||
* Clients SHOULD check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
|
||||
* Clients SHOULD check that the token is locked to the pubkey the user has listed in their `kind:10019`.
|
||||
|
||||
## Final Considerations
|
||||
|
||||
1. Clients SHOULD guide their users to use NUT-11 (P2PK) compatible-mints in their `kind:10019` event to avoid receiving nut zaps anyone can spend
|
||||
|
||||
2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
|
||||
|
||||
3. A nut zap MUST be sent to a mint the recipient has listed in their `kind:10019` event or to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.
|
||||
|
||||
## Appendix 1: Alternative P2PK pubkey
|
||||
Clients might not have access to the user's private key (i.e. NIP-07, NIP-46 signing) and, as such, the private key to sign cashu spends might not be available, which would make spending the P2PK incoming nutzaps impossible.
|
||||
|
||||
For this scenarios clients can:
|
||||
|
||||
* add a `pubkey` tag to the `kind:10019` (indicating which pubkey senders should P2PK to)
|
||||
* store the private key in the `kind:37375` event in the nip44-encrypted `content` field.
|
||||
|
||||
This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.
|
||||
@@ -5,8 +5,6 @@ reverse chronological order.
|
||||
|
||||
| Date | Commit | NIP | Change |
|
||||
| ----------- | --------- | -------- | ------ |
|
||||
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [NIP-71](71.md) | some tags were replaced with `imeta` tag |
|
||||
| 2024-10-15 | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [NIP-71](71.md) | `kind: 34237` was dropped |
|
||||
| 2024-10-07 | [7bb8997b](https://github.com/nostr-protocol/nips/commit/7bb8997b) | [NIP-55](55.md) | some fields and passing data were changed |
|
||||
| 2024-08-18 | [3aff37bd](https://github.com/nostr-protocol/nips/commit/3aff37bd) | [NIP-54](54.md) | content should be Asciidoc |
|
||||
| 2024-07-31 | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [NIP-45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
|
||||
|
||||
10
README.md
10
README.md
@@ -73,8 +73,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
- [NIP-57: Lightning Zaps](57.md)
|
||||
- [NIP-58: Badges](58.md)
|
||||
- [NIP-59: Gift Wrap](59.md)
|
||||
- [NIP-60: Cashu Wallet](60.md)
|
||||
- [NIP-61: Nutzaps](61.md)
|
||||
- [NIP-64: Chess (PGN)](64.md)
|
||||
- [NIP-65: Relay List Metadata](65.md)
|
||||
- [NIP-70: Protected Events](70.md)
|
||||
@@ -142,13 +140,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `5000`-`5999` | Job Request | [90](90.md) |
|
||||
| `6000`-`6999` | Job Result | [90](90.md) |
|
||||
| `7000` | Job Feedback | [90](90.md) |
|
||||
| `7373` | Reserved Cashu Wallet Tokens | [60](60.md) |
|
||||
| `7374` | Pending minting quotes | [60](60.md) |
|
||||
| `7375` | Cashu Wallet Tokens | [60](60.md) |
|
||||
| `7376` | Cashu Wallet History | [60](60.md) |
|
||||
| `9000`-`9030` | Group Control Events | [29](29.md) |
|
||||
| `9041` | Zap Goal | [75](75.md) |
|
||||
| `9321` | Nutzap | [61](61.md) |
|
||||
| `9467` | Tidal login | [Tidal-nostr] |
|
||||
| `9734` | Zap Request | [57](57.md) |
|
||||
| `9735` | Zap | [57](57.md) |
|
||||
@@ -163,7 +156,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `10007` | Search relays list | [51](51.md) |
|
||||
| `10009` | User groups | [51](51.md), [29](29.md) |
|
||||
| `10015` | Interests list | [51](51.md) |
|
||||
| `10019` | Nutzap Mint Recommendation | [61](61.md) |
|
||||
| `10030` | User emoji list | [51](51.md) |
|
||||
| `10050` | Relay list to receive DMs | [51](51.md), [17](17.md) |
|
||||
| `10063` | User server list | [Blossom][blossom] |
|
||||
@@ -216,8 +208,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `31990` | Handler information | [89](89.md) |
|
||||
| `34235` | Video Event | [71](71.md) |
|
||||
| `34236` | Short-form Portrait Video Event | [71](71.md) |
|
||||
| `34237` | Video View Event | [71](71.md) |
|
||||
| `34550` | Community Definition | [72](72.md) |
|
||||
| `37375` | Cashu Wallet Event | [60](60.md) |
|
||||
| `39000-9` | Group metadata events | [29](29.md) |
|
||||
|
||||
[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
|
||||
|
||||
Reference in New Issue
Block a user