This commit is contained in:
Yoji Shidara
2025-09-07 22:04:01 +09:00
committed by GitHub
parent 4c5d5fff99
commit 3a126a51a6
2 changed files with 5 additions and 5 deletions

8
53.md
View File

@@ -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
View File

@@ -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