encryption draft

This commit is contained in:
Jack Chakany 2023-03-14 12:04:37 -04:00 committed by GitHub
parent 85d20a02a3
commit 47a8995bce
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

18
100.md
View File

@ -6,6 +6,12 @@ This NIP defines how to do WebRTC communication over nostr
## Defining Rooms ## 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.) 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 ### Broadcasting that you are present
Announces that you are here, and ready to connect to others. Announces that you are here, and ready to connect to others.
The connection ID is inferred from the provided pubkey. The connection ID is inferred from the provided pubkey.
@ -15,7 +21,7 @@ The connection ID is inferred from the provided pubkey.
"pubkey": "<sender pubkey>", "pubkey": "<sender pubkey>",
"tags": [ "tags": [
["type", "connect"], ["type", "connect"],
["r", "<room id>"] ["r", "<plaintext room id>"]
] ]
} }
``` ```
@ -27,7 +33,7 @@ The connection ID is inferred from the provided pubkey.
"pubkey": "<sender pubkey>", "pubkey": "<sender pubkey>",
"tags": [ "tags": [
["type", "disconnect"], ["type", "disconnect"],
["r", "<room id>"] ["r", "<plaintext room id>"]
] ]
} }
``` ```
@ -41,7 +47,7 @@ Used when responding to a `type:connect`. Offering to connect to that peer.
"tags": [ "tags": [
["type", "offer"], ["type", "offer"],
["p", "<reciever pubkey>"], ["p", "<reciever pubkey>"],
["r", "<room id>"] ["r", "<encrypted room id>"]
], ],
"content": { "content": {
"offer": "<offer>", "offer": "<offer>",
@ -58,7 +64,7 @@ Used when responding to a `type:connect`. Offering to connect to that peer.
"tags": [ "tags": [
["type", "answer"], ["type", "answer"],
["p", "<reciever pubkey>"], ["p", "<reciever pubkey>"],
["r", "<room id>"] ["r", "<encrypted room id>"]
], ],
"content": { "content": {
"sdp": "<sdp>", "sdp": "<sdp>",
@ -75,7 +81,7 @@ Used when responding to a `type:connect`. Offering to connect to that peer.
"tags": [ "tags": [
["type", "candidate"], ["type", "candidate"],
["p", "<reciever pubkey>"], ["p", "<reciever pubkey>"],
["r", "<room id>"] ["r", "<encrypted room id>"]
], ],
"content": { "content": {
"candidate": "<sdp>", "candidate": "<sdp>",
@ -84,4 +90,4 @@ Used when responding to a `type:connect`. Offering to connect to that peer.
} }
``` ```
Essentially, just directly feed what comes out of the WebRTC functions straight into the `content` field. It makes things cleaner and easier. Essentially, just directly feed what comes out of the WebRTC functions straight into the `content` field after encrypting it.