mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-09-28 12:37:13 +02:00
Typos (#2054)
This commit is contained in:
8
53.md
8
53.md
@@ -10,7 +10,7 @@ This NIP introduces event kinds to advertise live spaces and the participation o
|
||||
|
||||
## Live Streaming
|
||||
|
||||
A special event with `kind:30311` "Live Streaming Event" is defined as an _addressable event_ whose tags advertise the content and participats of a live stream.
|
||||
A special event with `kind:30311` "Live Streaming Event" is defined as an _addressable event_ whose tags advertise the content and participants of a live stream.
|
||||
|
||||
Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
|
||||
|
||||
@@ -63,7 +63,7 @@ This feature is important to avoid malicious event owners adding large account h
|
||||
|
||||
### Live Chat Message
|
||||
|
||||
Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to.
|
||||
Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
@@ -249,9 +249,9 @@ Event management:
|
||||
```
|
||||
### Room Presence
|
||||
|
||||
New `kind: 10312` provides an event which signals presence of a listener.
|
||||
New `kind: 10312` provides an event which signals presence of a listener.
|
||||
|
||||
The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than
|
||||
The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than
|
||||
a given time window.
|
||||
|
||||
**This kind `10312` is a regular replaceable event, as such presence can only be indicated in one room at a time.**
|
||||
|
2
EE.md
2
EE.md
@@ -82,7 +82,7 @@ This is a concise overview of the security trade-offs and considerations of this
|
||||
|
||||
### Forward Secrecy and Post-compromise Security
|
||||
|
||||
- As per the MLS spec, keys are deleted as soon as they are used to encrypt or decrypt a message. This is usually handled by the MLS implementation library itself but attention needs to be paid by clients to ensure they're not storing secrets (expecially the [exporter secret](#group-events)) for longer than absolutely necessary.
|
||||
- As per the MLS spec, keys are deleted as soon as they are used to encrypt or decrypt a message. This is usually handled by the MLS implementation library itself but attention needs to be paid by clients to ensure they're not storing secrets (especially the [exporter secret](#group-events)) for longer than absolutely necessary.
|
||||
- This NIP maintains MLS forward secrecy and post-compromise security guarantees. You can read more about those in the MLS Architectural Overview section on [Forward Secrecy and Post-compromise Security](https://www.ietf.org/archive/id/draft-ietf-mls-architecture-15.html#name-forward-and-post-compromise).
|
||||
|
||||
### Leakage of various keys
|
||||
|
Reference in New Issue
Block a user