mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 08:25:53 -05:00
nchat
This commit is contained in:
parent
fade0164f5
commit
765a18c810
5
17.md
5
17.md
|
@ -123,6 +123,11 @@ This NIP offers the following privacy and security features:
|
||||||
|
|
||||||
The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.
|
The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.
|
||||||
|
|
||||||
|
## NIP-19 entity
|
||||||
|
To create an `nchat` link:
|
||||||
|
- `kind`: `17`
|
||||||
|
- `special`: one or more pubkeys concatenated
|
||||||
|
|
||||||
## Implementation
|
## Implementation
|
||||||
|
|
||||||
Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.
|
Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.
|
||||||
|
|
3
19.md
3
19.md
|
@ -36,6 +36,7 @@ These are the possible bech32 prefixes with `TLV`:
|
||||||
- `nevent`: a nostr event
|
- `nevent`: a nostr event
|
||||||
- `naddr`: a nostr _replaceable event_ coordinate
|
- `naddr`: a nostr _replaceable event_ coordinate
|
||||||
- `nrelay`: a nostr relay (deprecated)
|
- `nrelay`: a nostr relay (deprecated)
|
||||||
|
- `nchat`: a nostr chat conversation
|
||||||
|
|
||||||
These possible standardized `TLV` types are indicated here:
|
These possible standardized `TLV` types are indicated here:
|
||||||
|
|
||||||
|
@ -44,6 +45,7 @@ These possible standardized `TLV` types are indicated here:
|
||||||
- for `nprofile` it will be the 32 bytes of the profile public key
|
- for `nprofile` it will be the 32 bytes of the profile public key
|
||||||
- for `nevent` it will be the 32 bytes of the event id
|
- for `nevent` it will be the 32 bytes of the event id
|
||||||
- for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For normal replaceable events use an empty string.
|
- for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For normal replaceable events use an empty string.
|
||||||
|
- for `nchat`, see chat nip for details.
|
||||||
- `1`: `relay`
|
- `1`: `relay`
|
||||||
- for `nprofile`, `nevent` and `naddr`, _optionally_, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
|
- for `nprofile`, `nevent` and `naddr`, _optionally_, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
|
||||||
- this may be included multiple times
|
- this may be included multiple times
|
||||||
|
@ -53,6 +55,7 @@ These possible standardized `TLV` types are indicated here:
|
||||||
- `3`: `kind`
|
- `3`: `kind`
|
||||||
- for `naddr`, the 32-bit unsigned integer of the kind, big-endian
|
- for `naddr`, the 32-bit unsigned integer of the kind, big-endian
|
||||||
- for `nevent`, _optionally_, the 32-bit unsigned integer of the kind, big-endian
|
- for `nevent`, _optionally_, the 32-bit unsigned integer of the kind, big-endian
|
||||||
|
- for `nchat`, the NIP number of the chat.
|
||||||
|
|
||||||
## Examples
|
## Examples
|
||||||
|
|
||||||
|
|
5
28.md
5
28.md
|
@ -133,6 +133,11 @@ Clients MAY hide event 42s for users other than the user who sent the event 44.
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
|
## NIP-19 entity
|
||||||
|
To create an `nchat` link:
|
||||||
|
- `kind`: `28`
|
||||||
|
- `special`: `id` from `kind: 40`
|
||||||
|
|
||||||
## Relay recommendations
|
## Relay recommendations
|
||||||
|
|
||||||
Clients SHOULD use the relay URLs of the metadata events.
|
Clients SHOULD use the relay URLs of the metadata events.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user