diff options
| author | Yoji Shidara <dara@shidara.net> | 2025-09-07 22:04:01 +0900 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-09-07 06:04:01 -0700 |
| commit | 3a126a51a65bcf97a335a6897574254c92334cec (patch) | |
| tree | b3f3a7c080a4d67616a4896355d86c7c3401f381 | |
| parent | 4c5d5fff99993c5334c81475ab149895af884d04 (diff) | |
Typos (#2054)
| -rw-r--r-- | 53.md | 8 | ||||
| -rw-r--r-- | EE.md | 2 |
2 files changed, 5 insertions, 5 deletions
| @@ -10,7 +10,7 @@ This NIP introduces event kinds to advertise live spaces and the participation o | |||
| 10 | 10 | ||
| 11 | ## Live Streaming | 11 | ## Live Streaming |
| 12 | 12 | ||
| 13 | 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. | 13 | 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. |
| 14 | 14 | ||
| 15 | 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. | 15 | 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. |
| 16 | 16 | ||
| @@ -63,7 +63,7 @@ This feature is important to avoid malicious event owners adding large account h | |||
| 63 | 63 | ||
| 64 | ### Live Chat Message | 64 | ### Live Chat Message |
| 65 | 65 | ||
| 66 | 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. | 66 | 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. |
| 67 | 67 | ||
| 68 | ```jsonc | 68 | ```jsonc |
| 69 | { | 69 | { |
| @@ -249,9 +249,9 @@ Event management: | |||
| 249 | ``` | 249 | ``` |
| 250 | ### Room Presence | 250 | ### Room Presence |
| 251 | 251 | ||
| 252 | New `kind: 10312` provides an event which signals presence of a listener. | 252 | New `kind: 10312` provides an event which signals presence of a listener. |
| 253 | 253 | ||
| 254 | The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than | 254 | The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than |
| 255 | a given time window. | 255 | a given time window. |
| 256 | 256 | ||
| 257 | **This kind `10312` is a regular replaceable event, as such presence can only be indicated in one room at a time.** | 257 | **This kind `10312` is a regular replaceable event, as such presence can only be indicated in one room at a time.** |
| @@ -82,7 +82,7 @@ This is a concise overview of the security trade-offs and considerations of this | |||
| 82 | 82 | ||
| 83 | ### Forward Secrecy and Post-compromise Security | 83 | ### Forward Secrecy and Post-compromise Security |
| 84 | 84 | ||
| 85 | - 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. | 85 | - 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. |
| 86 | - 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). | 86 | - 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). |
| 87 | 87 | ||
| 88 | ### Leakage of various keys | 88 | ### Leakage of various keys |