2.2 KiB
NIP-100 WebRTC
draft
optional
author:jacany
This NIP defines how to do WebRTC communication over nostr
Defining Rooms
Rooms are essentially the space that you will be connected to. This must be defined by a r
tag following the pubkey of the person you are connected to or some other identifier (maybe a lobby id for a joinable voice channel, etc.)
Encryption
The content
field and r
tag of types offer
, answer
, and candidate
should be encrypted, similarly to NIP-04
.
Clients MUST listen for the p
tag containing their pubkey so they know that event is intended for them
⚠️ content
FIELDS SHOULD BE JSON STRINGIFIED, AND THEN ENCRYPTED. ⚠️
Broadcasting that you are present
Announces that you are here, and ready to connect to others. The connection ID is inferred from the provided pubkey.
{
"kind": 25050,
"pubkey": "<sender pubkey>",
"tags": [
["type", "connect"],
["r", "<plaintext room id>"]
]
}
Closing
{
"kind": 25050,
"pubkey": "<sender pubkey>",
"tags": [
["type", "disconnect"],
["r", "<plaintext room id>"]
]
}
Offering to connect
Used when responding to a type:connect
. Offering to connect to that peer.
{
"kind": 25050,
"pubkey": "<sender pubkey>",
"tags": [
["type", "offer"],
["p", "<reciever pubkey>"],
["r", "<encrypted room id>"]
],
"content": {
"offer": "<offer>",
"type": "offer"
}
}
Answering an Offer
{
"kind": 25050,
"pubkey": "<sender pubkey>",
"tags": [
["type", "answer"],
["p", "<reciever pubkey>"],
["r", "<encrypted room id>"]
],
"content": {
"sdp": "<sdp>",
"type": "answer"
}
}
Broadcasting ICE Candidate
{
"kind": 25050,
"pubkey": "<sender pubkey>",
"tags": [
["type", "candidate"],
["p", "<reciever pubkey>"],
["r", "<encrypted room id>"]
],
"content": {
"candidate": "<sdp>",
<misc>
}
}
Essentially, just directly feed what comes out of the WebRTC functions straight into the content
field after encrypting it.