mirror of
https://github.com/nostr-protocol/nips.git
synced 2026-07-22 07:48:25 +00:00
nip29: audio/video live spaces (#2238)
This commit is contained in:
40
29.md
40
29.md
@@ -44,6 +44,20 @@ The roles supported by the group as to having some special privilege assigned to
|
||||
|
||||
Users with any roles that have any privilege can be considered _admins_ in a broad sense and be returned in the `kind:39001` event for a group.
|
||||
|
||||
## Live audio/video (AV) spaces
|
||||
|
||||
Groups may indicate they support live audio and/or video chat by means of a [LiveKit](https://docs.livekit.io/transport/) server by having the tag `livekit` in the group announcement event. An empty `supported_kinds` tag should be used if the group doesn't support text messages, only live AV chat. This setup allows for both Discord-style independent AV rooms and text rooms and Telegram-style single-roomgroup with support for both text and AV.
|
||||
|
||||
Upon seeing a `livekit` tag in a group, clients that want to take part in the AV space should call the [token endpoint](https://docs.livekit.io/frontends/build/authentication/endpoint/) at the relay path `/.well-known/nip29/livekit/<group-id>` with a [NIP-98](98.md)-style `Authorization` header to get back the LiveKit JWT and the URL of the LiveKit server and proceed with the stardard LiveKit flow there.
|
||||
|
||||
The `Authorization` event should be of kind `27235` and contain a tag `["u", "https://relay.tld/.well-known/nip29/livekit/<group-id>"]`.
|
||||
|
||||
Relays should enforce access control at the LiveKit JWT creation time according to the group settings.
|
||||
|
||||
Relays MUST set the `sub` property on the issued JWT (called "identity" in the standard LiveKit libraries) such that the initial 64 characters correspond to the lowercase hex public key of the Nostr user. The same user can be issued multiple JWTs and join the same LiveKit room multiple times, so relays are expected to appending a random identifier to those 64 characters.
|
||||
|
||||
In order to inform clients about relay support for AV (so they can display that option for users when creating or editing groups) relays should serve a status code `204` at `https://relay.tld/.well-known/nip29/livekit`.
|
||||
|
||||
## Event definitions
|
||||
|
||||
These are the events expected to be found in NIP-29 groups.
|
||||
@@ -140,7 +154,8 @@ If the group is forked and hosted in multiple relays, there will be multiple ver
|
||||
["picture", "https://pizza.com/pizza.png"],
|
||||
["about", "a group for people who love pizza"],
|
||||
["private"],
|
||||
["closed"]
|
||||
["closed"],
|
||||
["supported_kinds", "9", "11"]
|
||||
]
|
||||
// other fields...
|
||||
}
|
||||
@@ -151,6 +166,8 @@ If the group is forked and hosted in multiple relays, there will be multiple ver
|
||||
- `restricted` indicates that only members can _write_ messages to the group. Omitting this tag indicates that anyone can send messages to the group.
|
||||
- `hidden` indicates that relays should hide group metadata from non-members. Omitting this tag indicates that anyone can request group metadata events.
|
||||
- `closed` indicates that join requests are ignored. Omitting this tag indicates that users can expect join requests to be honored.
|
||||
- `livekit` indicates that a group supports LiveKit-powered media rooms (live audio/video).
|
||||
- `supported_kinds` is a list of stringified kinds numbers the group supports. When not specified all kinds are assumed to be supported. It can contain no items, in which case no kinds are supported (this is the case for AV-only groups, for example).
|
||||
|
||||
- *group admins* (`kind:39001`) (optional)
|
||||
|
||||
@@ -213,6 +230,27 @@ The process through which the relay decides what roles to support and how to han
|
||||
}
|
||||
```
|
||||
|
||||
- *livekit participants* (`kind:39004`) (optional)
|
||||
|
||||
This is an event that MAY be published by the relay informing users and clients about who is live in an AV room.
|
||||
|
||||
This should be updated whenever a new user leaves or joins a group, clients are expected to be actively subscribed to it.
|
||||
|
||||
The event MUST contain zero or more `participant` tags with the participant's public key as lowercase hex.
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"kind": 39004,
|
||||
"content": "",
|
||||
"tags": [
|
||||
["d", "<group-id>"],
|
||||
["participant", "<pubkey>"],
|
||||
// other participants...
|
||||
],
|
||||
// other fields...
|
||||
}
|
||||
```
|
||||
|
||||
## Implementation quirks
|
||||
|
||||
### Checking your own membership in a group
|
||||
|
||||
Reference in New Issue
Block a user