### Concrete WebSocket Connection Example

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

An example URI for connecting to a SaltyRTC server, demonstrating the required path and optional parameters.

```text
wss://example.com:8765/debc3a6c9a630f27eae6bc3fd962925bdeb63844c09103f609bf7082bc383610\
?afc0a7bf3e2e3c2a7e5baf1d4b4be10d4f8aab4e2e3c2a7e5baf1d4b4be10d4\
#23b76e5a...
```

--------------------------------

### Reliable/Ordered Mode Chunking Example

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Chunking.md

Illustrates chunking a byte sequence in reliable/ordered mode with a chunk size of 6. The first chunk includes a short header and partial data, while the second chunk contains the remaining data and the end-of-message flag.

```text
- First chunk:  `0b00000110 || 0x0102030405`
- Second chunk: `0b00000111 || 0x060708`
```

--------------------------------

### SaltyRTC 'key' Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

This is an example of the 'key' message structure. The 'key' field contains the public key of the client's session key pair. The message must be NaCl public-key encrypted.

```json
{
  "type": "key",
  "key": b"bbbf470d283a9a4a0828e3fb86340fcbd19efe75f63a2e51ad0b16d20c3a0c02"
}
```

--------------------------------

### Unreliable/Unordered Mode Chunking Example

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Chunking.md

Demonstrates chunking a byte sequence in unreliable/unordered mode with a chunk size of 12 and a message ID of 42. Each chunk includes a long header with the message ID and serial number, followed by data. The last chunk indicates the end of the message.

```text
- First chunk:  `0b00000000 || 0x0000002a || 0x00000000 || 0x010203`
- Second chunk: `0b00000000 || 0x0000002a || 0x00000001 || 0x040506`
- Third chunk:  `0b00000001 || 0x0000002a || 0x00000002 || 0x0708`
```

--------------------------------

### Server Control Message: 'new-initiator'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Server → all responders: notifies that a new initiator authenticated on the path.

```json
{ "type": "new-initiator" }
```

--------------------------------

### WebRTC 'offer' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The initiator sends an SDP offer to establish a WebRTC connection.

```json
{
  "type": "offer",
  "offer": {
    "type": "offer",
    "sdp": "v=0\r\no=- 461234 2 IN IP4 127.0.0.1\r\n..."
  }
}
```

--------------------------------

### Server Control Message: 'new-responder'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Server → initiator: notifies that a new responder authenticated on the same path.

```json
{ "type": "new-responder", "id": 4 }
```

--------------------------------

### Server Hello Message

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

The server sends this message after a client connects. It contains a new public key for the session. The client must validate the key size and optionally check it against the server's permanent key.

```json
{
  "type": "server-hello",
  "key": b"debc3a6c9a630f27eae6bc3fd962925bdeb63844c09103f609bf7082bc383610"
}
```

--------------------------------

### Commit and Tag Release with GPG

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Releasing.md

Stage specification files, perform a signed commit, and create a signed tag for the release using the specified GPG key and version.

```bash
git add <spec-file>
git commit -S${GPG_KEY} -m "Release ${VERSION}"
git tag -u ${GPG_KEY} -m "Release ${VERSION}" ${VERSION}
```

--------------------------------

### Client Hello Message Structure (Responder Only)

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'client-hello' message sent by responders to the server, containing their permanent public key. Initiators skip this step, and the message is not encrypted.

```json
{
  "type": "client-hello",
  "key": "55e7dd57a01974ca31b6e588909b7b501cdc7694f21b930abb1600241b2ddb27"
}
```

--------------------------------

### Client Hello Message

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

Sent by the responder client after receiving 'server-hello'. It includes the client's permanent public key. The server validates the key size and uses this message to differentiate between initiator and responder roles.

```json
{
  "type": "client-hello",
  "key": b"55e7dd57a01974ca31b6e588909b7b501cdc7694f21b930abb1600241b2ddb27"
}
```

--------------------------------

### WebRTC Task - 'offer' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'offer' message format used by the initiator to send an SDP offer for establishing a WebRTC peer connection.

```APIDOC
### 'offer' Message

Initiator sends the SDP offer produced by `RTCPeerConnection.createOffer()`.

```json
{
  "type": "offer",
  "offer": {
    "type": "offer",
    "sdp": "v=0\r\no=- 461234 2 IN IP4 127.0.0.1\r\n..."
  }
}
```
```

--------------------------------

### Server Control Message: 'application'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Post-handshake: either client can send arbitrary user-defined control data without defining a custom task.

```json
{
  "type": "application",
  "data": { "hello": "world" }
}
```

--------------------------------

### Server Hello Message Validation Pseudocode

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Pseudocode for validating the 'server-hello' message, ensuring the key is 32 bytes and distinct from the server's permanent public key if provided.

```python
# Validation (pseudocode)
assert len(msg['key']) == 32         # must be exactly 32 bytes
if server_permanent_pubkey:
    assert msg['key'] != server_permanent_pubkey  # session ≠ permanent key
```

--------------------------------

### Python Pseudocode for Nonce Construction

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Illustrates how to construct a SaltyRTC nonce using Python, including generating a random cookie and packing sequence and overflow numbers.

```python
import os, struct

cookie       = os.urandom(16)            # fresh per peer
src_addr     = 0x01                      # initiator
dst_addr     = 0x00                      # server
overflow_num = 0                         # starts at 0
seq_num      = struct.unpack('>I', os.urandom(4))[0]  # random start

nonce = cookie + bytes([src_addr, dst_addr]) \
      + struct.pack('>H', overflow_num) \
      + struct.pack('>I', seq_num)

# Combined Sequence Number (CSN) alternative:
# upper 16 bits = overflow, lower 32 bits = sequence
# csn must never wrap to 0; close with 3001 if it does.
cen = (overflow_num << 32) | seq_num
```

--------------------------------

### Minimal SaltyRTC Send Loop

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

This pseudocode illustrates the basic process of packing, encrypting, and sending data messages in SaltyRTC. Ensure data_queue is populated and ws is an active WebSocket connection.

```pseudocode
for item in data_queue:
    msg = msgpack.packb({"type": "data", "p": item})
    encrypted = nacl_box.encrypt(msg, nonce)
    ws.send(nonce + encrypted)
```

--------------------------------

### Client Auth Message Field Explanations

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Explains the fields within the 'client-auth' message, specifically 'your_cookie', 'subprotocols', and 'your_key'.

```text
# your_cookie  = cookie the server used in its server-hello nonce
# subprotocols = same list given to the WebSocket constructor
```

--------------------------------

### Server Hello Message Structure

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'server-hello' message sent by the server upon connection, containing its session public key. This message is not encrypted.

```json
{
  "type": "server-hello",
  "key": "debc3a6c9a630f27eae6bc3fd962925bdeb63844c09103f609bf7082bc383610"
}
```

--------------------------------

### Send 'new-initiator' Message

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

The server sends this message to responders when a new initiator authenticates. No additional fields are needed. Ensure this message is sent before the initiator can communicate with responders.

```json
{
  "type": "new-initiator"
}
```

--------------------------------

### New Initiator Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'new-initiator' message is sent by the server to all responders, notifying that a new initiator has authenticated on the path.

```APIDOC
## 'new-initiator' Message

Server → all responders: notifies that a new initiator authenticated on the path.

```json
{ "type": "new-initiator" }
```
```

--------------------------------

### Set Release Version Variables

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Releasing.md

Export environment variables for versioning the SaltyRTC protocol, chunking spec, or tasks. Ensure the GPG key is set for signed commits and tags.

```bash
# For the SaltyRTC protocol or the chunking spec:
export VERSION=protocol|chunking-<version>
# For tasks:
export VERSION=task-<task-name>-<version>
export GPG_KEY=3FDB14868A2B36D638F3C495F98FBED10482ABA6
```

--------------------------------

### WebRTC Task - Task Data in 'auth'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Configuration for the WebRTC task, specifying data channels to exclude and whether to enable handover.

```APIDOC
## WebRTC Task (`v1.webrtc.tasks.saltyrtc.org`)

### Task Data in 'auth'

```json
{
  "v1.webrtc.tasks.saltyrtc.org": {
    "exclude": [0, 1],
    "handover": true
  }
}
```

* `exclude`: list of data channel IDs reserved by the application (not usable for handover).
* `handover`: `true` = both sides agree; `false` on either side disables handover.
```

--------------------------------

### Server Authentication Message ('server-auth')

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Sent by the server in reply to 'client-auth'. Assigns the client its address and optionally provides a signed key proof. Encrypted with server session key + client permanent key.

```json
{
  "type": "server-auth",
  "your_cookie": "18b96fd5a151eae23e8b5a1aed2fe30d",
  "signed_keys": "e42bfd8c5bc9870ae1a0d928...",
  "initiator_connected": true,
  "responders": [2, 3]
}
```

--------------------------------

### Server Control Message: 'disconnected'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Server → peer: the other client has disconnected.

```json
{ "type": "disconnected", "id": 2 }
```

--------------------------------

### WebRTC Task - 'candidates' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'candidates' message format for exchanging ICE candidates between peers. Multiple candidates can be bundled.

```APIDOC
### 'candidates' Message

Both peers exchange ICE candidates; bundle multiple candidates per message where possible.

```json
{
  "type": "candidates",
  "candidates": [
    {
      "candidate": "candidate:1 1 UDP 2122194687 192.168.1.5 54321 typ host",
      "sdpMid": "data",
      "sdpMLineIndex": 0,
      "usernameFragment": "abcdefgh"
    },
    null
  ]
}
```
```

--------------------------------

### Client Auth Message Structure

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'client-auth' message sent by both initiators and responders after receiving 'server-hello'. It is encrypted and includes the client's cookie, supported subprotocols, ping interval, and public key.

```json
{
  "type": "client-auth",
  "your_cookie": "af354da383bba00507fa8f289a20308a",
  "subprotocols": [
    "v1.saltyrtc.org"
  ],
  "ping_interval": 30,
  "your_key": "2659296ce03993e876d5f2abcaa6d19f92295ff119ee5cb327498d2620efc979"
}
```

--------------------------------

### WebRTC 'candidates' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Peers exchange ICE candidates, bundling multiple candidates per message for efficiency.

```json
{
  "type": "candidates",
  "candidates": [
    {
      "candidate": "candidate:1 1 UDP 2122194687 192.168.1.5 54321 typ host",
      "sdpMid": "data",
      "sdpMLineIndex": 0,
      "usernameFragment": "abcdefgh"
    },
    null
  ]
}
```

--------------------------------

### Secure Data Channel Nonce Format

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Illustrates the nonce format for secure data channels, which replaces Source/Destination with Data Channel ID.

```plaintext
+-------------------+-----------------+-----------------+------------------+
| Cookie (16 bytes) | DC ID (2 bytes) | Overflow (2)    | Sequence (4)     |
+-------------------+-----------------+-----------------+------------------+

# Each data channel instance has independent cookie, overflow, and sequence
# counters for both incoming AND outgoing directions.
# Fragmentation: chunk with SaltyRTC Chunking in unreliable/unordered mode.
# Chunk size ≤ RTCSctpTransport.maxMessageSize.
```

--------------------------------

### Send 'new-responder' Message

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

The server sends this message to an initiator when a new responder authenticates. The 'id' field must be set to the responder's identity. Ensure this message is sent before the responder can communicate with the initiator.

```json
{
  "type": "new-responder",
  "id": 0x04
}
```

--------------------------------

### Application Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'application' message allows either client to send arbitrary user-defined control data after the handshake, without defining a custom task.

```APIDOC
## 'application' Message

Post-handshake: either client can send arbitrary user-defined control data without defining a custom task.

```json
{
  "type": "application",
  "data": { "hello": "world" }
}
```
```

--------------------------------

### Send ICE Candidates Message

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-ORTC.md

Use this message to send ICE candidates to the peer. Ensure candidates are bundled and validated before sending.

```json
{
  "type": "ice-candidates",
  "candidates": [{
    "candidate": {
      "foundation": "f4d3...",
      "priority": 12345,
      "ip": "192.168.1.1",
      "protocol": "udp",
      "port": 48765,
      "type": "host"
    },
    "label": "echo-service" // optional
  }, {
    "candidate": {
      "foundation": "abcd...",
      "priority": 1234,
      "ip": "1.1.1.1",
      "protocol": "udp",
      "port": 42354,
      "type": "srflx",
      "relatedAddress": "192.168.1.1",
      "relatedPort": 48766
    },
    "label": "echo-service" // optional
  }, {
    "candidate": {
      "foundation": "1111...",
      "priority": 123,
      "ip": "192.168.1.1",
      "protocol": "tcp",
      "port": 48767,
      "type": "host",
      "tcpType": "active"
    },
    "label": "echo-service" // optional
  }, {
    "candidate": {
      "complete": true
    },
    "label": "echo-service" // optional
  }]
}
```

--------------------------------

### Client-to-Client Handshake: 'key' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Both peers exchange freshly generated session key pairs. Encrypted with both clients' permanent key pairs. After key exchange all further messages use session keys for encryption. Responder sends 'key' first; initiator must process it before replying.

```json
{
  "type": "key",
  "key": "bbbf470d283a9a4a0828e3fb86340fcbd19efe75f63a2e51ad0b16d20c3a0c02"
}
```

--------------------------------

### Server Auth Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'server-auth' message is sent by the server in reply to 'client-auth'. It assigns the client its address and optionally provides a signed key proof.

```APIDOC
## server-auth Message

Sent by the server in reply to `client-auth`. Assigns the client its address (initiator → `0x01`, responders → `0x02..0xff`) and optionally provides a signed key proof. Encrypted with server session key + client permanent key.

```json
{
  "type": "server-auth",
  "your_cookie": "18b96fd5a151eae23e8b5a1aed2fe30d",
  "signed_keys": "e42bfd8c5bc9870ae1a0d928...",
  "initiator_connected": true,
  "responders": [2, 3]
}
```

```
# signed_keys (if present): NaCl box of (server_session_pubkey || client_permanent_pubkey)
#   encrypted with server_permanent_privkey + client_permanent_pubkey using message nonce.
#   Verifies that the server really owns the permanent key the client expected.

# For initiators: 'responders' array lists already-authenticated responder addresses.
# For responders: 'initiator_connected' tells whether an initiator is waiting.
```
```

--------------------------------

### New Responder Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'new-responder' message is sent by the server to the initiator, notifying that a new responder has authenticated on the same path.

```APIDOC
## 'new-responder' Message

Server → initiator: notifies that a new responder authenticated on the same path.

```json
{ "type": "new-responder", "id": 4 }
```
```

--------------------------------

### WebRTC 'answer' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The responder sends an SDP answer to complete the WebRTC connection negotiation.

```json
{
  "type": "answer",
  "answer": {
    "type": "answer",
    "sdp": "v=0\r\no=- 123456 2 IN IP4 127.0.0.1\r\n..."
  }
}
```

--------------------------------

### WebRTC Task - 'answer' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'answer' message format used by the responder to send an SDP answer for establishing a WebRTC peer connection.

```APIDOC
### 'answer' Message

Responder replies with the SDP answer from `RTCPeerConnection.createAnswer()`.

```json
{
  "type": "answer",
  "answer": {
    "type": "answer",
    "sdp": "v=0\r\no=- 123456 2 IN IP4 127.0.0.1\r\n..."
  }
}
```
```

--------------------------------

### Offer Message Structure for WebRTC Signaling

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-WebRTC.md

This JSON structure represents an 'offer' message used in SaltyRTC for WebRTC signaling. It includes the message type and the WebRTC offer details, such as SDP type and data.

```json
{
  "type": "offer",
  "offer": {
    "type": "offer",
    "sdp": "..."
  }
}
```

--------------------------------

### ORTC Task - 'ice-parameters' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Message for exchanging ICE parameters in the ORTC task, including username fragment, password, and ICE lite status.

```APIDOC
## ORTC Task (`v0.ortc.tasks.saltyrtc.org`)

### 'ice-parameters' Message

```json
{
  "type": "ice-parameters",
  "parameters": {
    "usernameFragment": "abcd1234",
    "password": "efgh5678ijkl9012",
    "iceLite": false
  },
  "role": "controlling",
  "label": "main-transport"
}
```
```

--------------------------------

### WebSocket Connection URI Format

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Defines the URI format for connecting to a SaltyRTC server, including optional server public key and authentication token.

```text
wss://<host>:<port>/<initiator-pubkey-hex>?<server-permanent-pubkey-hex>#<auth-token-hex>
```

--------------------------------

### SaltyRTC 'ice-parameters' Message Format

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-ORTC.md

Use this JSON structure to send ICE parameters. The 'parameters' field must contain usernameFragment, password, and iceLite. The 'role' and 'label' fields are optional.

```json
{
  "type": "ice-parameters",
  "parameters": {
    "usernameFragment": "abcd...",
    "password": "efgh...",
    "iceLite": false
  },
  "role": "controlling", // optional
  "label": "echo-service" // optional
}
```

--------------------------------

### Key Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'key' message is exchanged between peers for fresh session key pairs. It is encrypted with both clients' permanent key pairs.

```APIDOC
## 'key' Message

Both peers exchange freshly generated session key pairs. Encrypted with both clients' permanent key pairs.

```json
{
  "type": "key",
  "key": "bbbf470d283a9a4a0828e3fb86340fcbd19efe75f63a2e51ad0b16d20c3a0c02"
}
```

```
# Rules:
# - Each client generates a NEW NaCl key pair per connection (session key).
# - The session key MUST NOT equal the permanent key.
# - After key exchange all further messages use session keys for encryption.
# - Responder sends 'key' first; initiator must process it before replying.
```
```

--------------------------------

### Client-to-Client Handshake: 'auth' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Finalises client-to-client authentication. Includes a cookie echo, task negotiation, and task-specific data. Encrypted with both clients' session key pairs. Initiator drops all other responders with drop-responder 3004 after auth.

```json
{
  "type": "auth",
  "your_cookie": "957c92f0feb9bae1b37cb7e0d9989073",
  "tasks": [
    "v1.webrtc.tasks.saltyrtc.org",
    "v1.ortc.tasks.saltyrtc.org"
  ],
  "task": "v1.webrtc.tasks.saltyrtc.org",
  "data": {
    "v1.webrtc.tasks.saltyrtc.org": {
      "exclude": [],
      "handover": true
    },
    "v1.ortc.tasks.saltyrtc.org": null
  }
}
```

--------------------------------

### JavaScript WebSocket Connection

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Establishes a WebSocket connection to a SaltyRTC server using the 'v1.saltyrtc.org' subprotocol. The server closes the connection with code 1002 if the subprotocol is not supported.

```javascript
const ws = new WebSocket(
  'wss://example.com:8765/debc3a6c9a630f27eae6bc3fd962925bdeb63844c09103f609bf7082bc383610',
  ['v1.saltyrtc.org']
);
// If the server did not choose 'v1.saltyrtc.org', it closes with code 1002.
```

--------------------------------

### Send 'drop-responder' Message

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

An initiator sends this message to request dropping a responder. Include the responder's 'id' and optionally a 'reason' for the drop. The initiator should clear cached information before sending.

```json
{
  "type": "drop-responder",
  "id": 0x02,
  "reason": 3005
}
```

--------------------------------

### SCTP Capabilities Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-ORTC.md

Send this message to share SCTP capabilities. The 'capabilities' field is a map that must include 'maxMessageSize'. An optional 'label' can be provided, but 'handover' is a reserved value.

```json
{
  "type": "sctp-capabilities",
  "capabilities": {
    "maxMessageSize": 16384
  },
  "label": "echo-service" // optional
}
```

--------------------------------

### WebRTC Task - Secure Data Channel Nonce Format

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Describes the nonce format used for secure data channels in WebRTC tasks, including cookie, data channel ID, overflow, and sequence.

```APIDOC
### Secure Data Channel Nonce

The nonce format changes when using data channels (Source/Destination replaced by Data Channel ID).

```
+-------------------+-----------------+-----------------+------------------+
| Cookie (16 bytes) | DC ID (2 bytes) | Overflow (2)    | Sequence (4)     |
+-------------------+-----------------+-----------------+------------------+
```

* Each data channel instance has independent cookie, overflow, and sequence
  counters for both incoming AND outgoing directions.
* Fragmentation: chunk with SaltyRTC Chunking in unreliable/unordered mode.
* Chunk size ≤ RTCSctpTransport.maxMessageSize.
```

--------------------------------

### SaltyRTC 'candidates' Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-WebRTC.md

Used to send ICE candidates between clients. Each candidate can be a Map with 'candidate', 'sdpMid', 'sdpMLineIndex', and 'usernameFragment' fields, or null.

```json
{
  "type": "candidates",
  "candidates": [
    {
      "candidate": "...",
      "sdpMid": "data",
      "sdpMLineIndex": 0,
      "usernameFragment": "abcdefgh"
    }, {
      "candidate": "...",
      "sdpMid": "data",
      "sdpMLineIndex": null, // Nil
      "usernameFragment": null // Nil
    },
    null // Nil
  ]
}
```

--------------------------------

### WebRTC Task - 'handover' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'handover' message sent over the WebSocket channel once the dedicated secure data channel is open, indicating a switch to data channel signaling.

```APIDOC
### 'handover' Message (WebRTC)

Sent over the WebSocket channel once the dedicated secure data channel is open. Subsequent signalling messages must go via the data channel.

```json
{ "type": "handover" }
```

*Handover sequence:*
* 1. Create RTCDataChannel: `{ ordered: true, protocol: "v1.saltyrtc.org", negotiated: true, id: <lowest free id> }`
* 2. Wrap it as a Secure Data Channel (NaCl encrypted, chunked).
* 3. Once 'open': send 'handover' over WS, switch outgoing to DC.
* 4. Accept WS messages until peer's 'handover' arrives; then DC-only.
* 5. Close WS with code 3003 after both sides have sent 'handover'.
```

--------------------------------

### Server-Auth Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

This JSON structure represents the 'server-auth' message sent by the server. It includes fields like 'your_cookie', 'signed_keys', and role-specific fields 'initiator_connected' or 'responders'.

```json
{
  "type": "server-auth",
  "your_cookie": b"18b96fd5a151eae23e8b5a1aed2fe30d",
  "signed_keys": b"e42bfd8c5bc9870ae1a0d928d52810983ac7ddf69df013a7621d072aa9633616cfd...",
  "initiator_connected": true,  // ONLY towards responders
  "responders": [  // ONLY towards initiators
    0x02,
    0x03
  ]
}
```

--------------------------------

### SaltyRTC 'token' Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

Represents the structure of the 'token' message exchanged during the SaltyRTC handshake. The 'key' field must contain a valid NaCl public key.

```python
{
  "type": "token",
  "key": b"55e7dd57a01974ca31b6e588909b7b501cdc7694f21b930abb1600241b2ddb27"
}
```

--------------------------------

### Server Control Message: 'drop-responder'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Initiator → server: request to forcibly disconnect a responder. Valid reason codes include Protocol Error (3001), Internal Error (3002), Dropped by Initiator (3004), and Initiator Could Not Decrypt (3005).

```json
{
  "type": "drop-responder",
  "id": 2,
  "reason": 3005
}
```

--------------------------------

### Client-to-Client Handshake: 'token' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Sent by a responder to an initiator when the responder is not yet trusted. Encrypted with a one-time NaCl secret key (the authentication token) that the initiator previously shared out-of-band. The token is valid for exactly ONE successfully decrypted message.

```json
{
  "type": "token",
  "key": "55e7dd57a01974ca31b6e588909b7b501cdc7694f21b930abb1600241b2ddb27"
}
```

--------------------------------

### Data Channel Parameters Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-ORTC.md

Use this message to exchange data channel parameters. The 'parameters' field is a map containing details like 'id', 'label', 'ordered', 'maxPacketLifetime', and 'protocol'. An optional 'label' can distinguish different data channels.

```json
{
  "type": "dc-parameters",
  "parameters": {
    "id": 42,
    "label": "echo-service", // optional
    "ordered": true, // optional
    "protocol": "echo-service-protocol" // optional
  },
  "label": "echo-service-data" // optional
}
```

--------------------------------

### SaltyRTC 'handover' Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-WebRTC.md

Sent to indicate the secure data channel for signaling is open. No additional fields are included.

```json
{
  "type": "handover"
}
```

--------------------------------

### WebRTC 'handover' Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Sent over WebSocket when the secure data channel is open, signaling a switch to data channel for subsequent messages.

```json
{ "type": "handover" }
```

--------------------------------

### Auth Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'auth' message finalizes client-to-client authentication. It includes a cookie echo, task negotiation, and task-specific data, encrypted with session key pairs.

```APIDOC
## 'auth' Message

Finalises client-to-client authentication. Includes a cookie echo, task negotiation, and task-specific data. Encrypted with both clients' session key pairs.

```json
{
  "type": "auth",
  "your_cookie": "957c92f0feb9bae1b37cb7e0d9989073",
  "tasks": [
    "v1.webrtc.tasks.saltyrtc.org",
    "v1.ortc.tasks.saltyrtc.org"
  ],
  "task": "v1.webrtc.tasks.saltyrtc.org",
  "data": {
    "v1.webrtc.tasks.saltyrtc.org": {
      "exclude": [],
      "handover": true
    },
    "v1.ortc.tasks.saltyrtc.org": null
  }
}
```

```
# Responder sets 'tasks' (list of supported task names, in preference order).
# Initiator reads responder's 'tasks', picks the first match from its own list,
# and sets 'task' (singular) in its own auth message.
# If no common task: send 'close' with reason 3006, then terminate.
# After auth, initiator drops all other responders with drop-responder 3004.
```
```

--------------------------------

### Token Message

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

The 'token' message is sent by a responder to an initiator when the responder is not yet trusted. It is encrypted with a one-time NaCl secret key.

```APIDOC
## 'token' Message

Sent by a responder to an initiator when the responder is not yet trusted. Encrypted with a one-time NaCl secret key (the authentication token) that the initiator previously shared out-of-band.

```json
{
  "type": "token",
  "key": "55e7dd57a01974ca31b6e588909b7b501cdc7694f21b930abb1600241b2ddb27"
}
```

```
# The token is a 32-byte NaCl secret key generated by the initiator.
# It is valid for exactly ONE successfully decrypted message.
# If decryption fails, initiator sends drop-responder with reason 3005.
# Once authenticated, both sides may store each other's pubkeys as "trusted"
# and skip the token message on future connections.
```
```

--------------------------------

### Send DTLS Parameters Message

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-ORTC.md

Send this message to exchange DTLS parameters with the peer. The message must include a role and at least one DTLS fingerprint.

```json
{
  "type": "dtls-parameters",
  "parameters": {
    "role": "auto",
    "fingerprints": [{
      "algorithm": "sha-256",
      "value": "00aabb..."
    }, ...]
  },
  "label": "echo-service" // optional
}
```

--------------------------------

### RTP Capabilities Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-ORTC.md

Use this message to exchange RTP capabilities between clients. The 'capabilities' field must be an array of maps, each describing RTCRtpCapabilities. An optional 'label' can distinguish different instances.

```json
{
  "type": "rtp-capabilities",
  "capabilities": [{
    "capabilities": {
      "codecs": [...],
      "headerExtensions": [...],
      "fecMechanisms": [...] 
    },
    "label": "echo-service-audio" // optional
  }, {
    "capabilities": {
      "codecs": [...],
      "headerExtensions": [...],
      "fecMechanisms": [...] 
    },
    "label": "echo-service-video" // optional
  }, ...]
}
```

--------------------------------

### WebRTC Task Auth Data

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Specifies WebRTC task configuration, including reserved data channel IDs and handover preference.

```json
{
  "v1.webrtc.tasks.saltyrtc.org": {
    "exclude": [0, 1],
    "handover": true
  }
}
```

--------------------------------

### Server Control Message: 'close'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Either client requests graceful termination of the signalling connection. Close codes include Normal Closure (1000), Going Away (1001), and WS Protocol Error (1002).

```json
{ "type": "close", "reason": 1001 }
```

--------------------------------

### SaltyRTC 'answer' Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Task-WebRTC.md

Represents the answer SDP from a WebRTC peer. The 'answer' field must be a Map containing 'type' (RTCSdpType) and 'sdp' (string).

```json
{
  "type": "answer",
  "answer": {
    "type": "answer",
    "sdp": "..."
  }
}
```

--------------------------------

### SaltyRTC 'application' Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

The 'application' message is used for sending arbitrary data between user applications after the client-to-client handshake. The 'data' field can contain any type of data. Both clients must support this message type.

```json
{
  "type": "application",
  "data": ...
}
```

--------------------------------

### Server Control Message: 'send-error'

Source: https://context7.com/saltyrtc/saltyrtc-meta/llms.txt

Server → sender: a relayed message could not be delivered. The 'id' field is a binary concatenation of src(1) || dst(1) || overflow(2) || seq(4) from the undeliverable message's nonce. Client must raise an error event and delete cached state for that peer.

```json
{
  "type": "send-error",
  "id": "010200000000000f"
}
```

--------------------------------

### SaltyRTC 'auth' Message Structure

Source: https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md

The 'auth' message is exchanged by both initiator and responder after key exchange. It includes cookies, offered/chosen tasks, and task-specific data. The responder offers tasks, while the initiator selects one. Both parties validate received fields.

```json
{
  "type": "auth",
  "your_cookie": b"957c92f0feb9bae1b37cb7e0d9989073",
  "tasks": [
    "v1.ortc.tasks.saltyrtc.org",
    "v1.webrtc.tasks.saltyrtc.org"
  ],
  "task": "v1.ortc.tasks.saltyrtc.org",
  "data": {
     "v1.ortc.tasks.saltyrtc.org": {
        ...
      },
      "v1.webrtc.tasks.saltyrtc.org": {
        ...
      }
  }
}
```