mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-13 23:39:08 -05:00
Merge branch 'nostr-protocol:master' into versatile-data
This commit is contained in:
tiltpapa
commit
153ba2a489
13
01.md
13
01.md
|
|
@ -14,7 +14,7 @@ Each user has a keypair. Signatures, public key, and encodings are done accordin
|
|||
|
||||
The only object type that exists is the `event`, which has the following format on the wire:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
|
|
@ -22,7 +22,7 @@ The only object type that exists is the `event`, which has the following format
|
|||
"kind": <integer between 0 and 65535>,
|
||||
"tags": [
|
||||
[<arbitrary string>...],
|
||||
...
|
||||
// ...
|
||||
],
|
||||
"content": <arbitrary string>,
|
||||
"sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
|
||||
|
|
@ -58,17 +58,16 @@ To prevent implementation differences from creating a different event ID for the
|
|||
|
||||
Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
...,
|
||||
"tags": [
|
||||
["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],
|
||||
["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"],
|
||||
["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],
|
||||
["alt", "reply"],
|
||||
...
|
||||
// ...
|
||||
],
|
||||
...
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -125,7 +124,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
|
|||
"ids": <a list of event ids>,
|
||||
"authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
|
||||
"kinds": <a list of a kind numbers>,
|
||||
"#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of event pubkeys etc>,
|
||||
"#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
|
||||
"since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
|
||||
"until": <an integer unix timestamp in seconds, events must be older than this to pass>,
|
||||
"limit": <maximum number of events relays SHOULD return in the initial query>
|
||||
|
|
|
|||
2
47.md
2
47.md
|
|
@ -17,7 +17,7 @@ This NIP describes a way for clients to access a remote Lightning wallet through
|
|||
* **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi). This app has access to the APIs of the wallets it serves.
|
||||
|
||||
## Theory of Operation
|
||||
1. **Users** who which to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application. The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means.
|
||||
1. **Users** who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application. The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means.
|
||||
|
||||
2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc. The **client(s)** should save this URI and use it later whenever the **user** makes a payment. The **client** should then request an `info` (13194) event from the relay(s) specified in the URI. The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.
|
||||
|
||||
|
|
|
|||
4
52.md
4
52.md
|
|
@ -38,7 +38,7 @@ The list of tags are as follows:
|
|||
The following tags are deprecated:
|
||||
* `name` name of the calendar event. Use only if `title` is not available.
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
|
|
@ -99,7 +99,7 @@ The list of tags are as follows:
|
|||
The following tags are deprecated:
|
||||
* `name` name of the calendar event. Use only if `title` is not available.
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
|
|
|
|||
10
72.md
10
72.md
|
|
@ -12,7 +12,7 @@ The goal of this NIP is to create moderator-approved public communities around a
|
|||
|
||||
`kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals.
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"created_at": <Unix timestamp in seconds>,
|
||||
"kind": 34550,
|
||||
|
|
@ -42,14 +42,14 @@ The goal of this NIP is to create moderator-approved public communities around a
|
|||
|
||||
Any Nostr event can be submitted to a community by anyone for approval. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval.
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"kind": 1,
|
||||
"tags": [
|
||||
["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
|
||||
],
|
||||
"content": "hello world",
|
||||
...
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ Community management clients MAY filter all mentions to a given `kind:34550` eve
|
|||
|
||||
The post-approval event MUST include `a` tags of the communities the moderator is posting into (one or more), the `e` tag of the post and `p` tag of the author of the post (for approval notifications). The event SHOULD also include the stringified `post request` event inside the `.content` ([NIP-18-style](18.md)) and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
|
||||
"kind": 4550,
|
||||
|
|
@ -70,7 +70,7 @@ The post-approval event MUST include `a` tags of the communities the moderator i
|
|||
["k", "<post-request-kind>"]
|
||||
],
|
||||
"content": "<the full approved event, JSON-encoded>",
|
||||
...
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -94,6 +94,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
| `42` | Channel Message | [28](28.md) |
|
||||
| `43` | Channel Hide Message | [28](28.md) |
|
||||
| `44` | Channel Mute User | [28](28.md) |
|
||||
| `1021` | Bid | [15](15.md) |
|
||||
| `1022` | Bid confirmation | [15](15.md) |
|
||||
| `1040` | OpenTimestamps | [03](03.md) |
|
||||
| `1063` | File Metadata | [94](94.md) |
|
||||
| `1311` | Live Chat Message | [53](53.md) |
|
||||
|
|
@ -136,6 +138,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
| `30015` | Interest sets | [51](51.md) |
|
||||
| `30017` | Create or update a stall | [15](15.md) |
|
||||
| `30018` | Create or update a product | [15](15.md) |
|
||||
| `30019` | Marketplace UI/UX | [15](15.md) |
|
||||
| `30020` | Product sold as an auction | [15](15.md) |
|
||||
| `30023` | Long-form Content | [23](23.md) |
|
||||
| `30024` | Draft Long-form Content | [23](23.md) |
|
||||
| `30030` | Emoji sets | [51](51.md) |
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user