docs: Add audio call feasibility plan#2
Merged
Conversation
Agent-Logs-Url: https://github.com/etnt/cryptic/sessions/09564913-c570-4deb-a003-e3d06de667c1 Co-authored-by: etnt <5860+etnt@users.noreply.github.com>
Owner
|
What about cryptic-mobile? |
There was a problem hiding this comment.
Pull request overview
Adds a new feasibility/planning document describing how Cryptic could implement E2E-encrypted 1:1 audio calls, leveraging existing WebSocket/mTLS signaling and Double Ratchet for DTLS fingerprint authentication.
Changes:
- Introduces a detailed architecture plan covering transport (ICE + DTLS-SRTP + relay fallback), encryption binding, signaling message types, and phased delivery.
- Proposes server-side routing via existing
user_connectionsETS lookups and outlines optional relay/registry modules. - Scopes initial audio support to the Rust TUI, with console client limited to signaling commands in v1.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+230
to
+233
| the existing Double Ratchet session derives a 32-byte "call binding key" | ||
| `K_call` using a dedicated context string (e.g., | ||
| `KDF(chain_key, "audio_call_v1")`). This is communicated as part of the | ||
| encrypted SDP offer message, not transmitted in plaintext. |
| authenticated identity. | ||
|
|
||
| 3. **SRTP via DTLS-SRTP** (RFC 5764): DTLS establishes the master key for SRTP. | ||
| Audio frames are encrypted with SRTP (AES-128-GCM or ChaCha20 profiles). |
Owner
There was a problem hiding this comment.
We are only considering communication between Cryptic clients, hence ChaCha20 should be fine, or?
Comment on lines
+332
to
+342
| #### `call_reject` | ||
| Bob declines. | ||
| ```json | ||
| { | ||
| "type": "call_reject", | ||
| "call_id": "uuid-1234", | ||
| "from_user": "bob", | ||
| "to_user": "alice", | ||
| "reason": "busy" | ||
| } | ||
| ``` |
Comment on lines
+355
to
+367
| ### Server Relay Message Types (when P2P fails) | ||
|
|
||
| #### `call_relay_frame` | ||
| An encrypted Opus audio frame relayed through the server. | ||
| ```json | ||
| { | ||
| "type": "call_relay_frame", | ||
| "call_id": "uuid-1234", | ||
| "from_user": "alice", | ||
| "to_user": "bob", | ||
| "seq": 42, | ||
| "encrypted_frame": "base64..." | ||
| } |
| CallType =:= <<"call_hangup">> -> | ||
| ToUser = maps:get(<<"to_user">>, Msg), | ||
| relay_to_user(ToUser, Msg), | ||
| {ok, State}; |
- Fix K_call derivation inconsistency: clarify that both sides derive
K_call locally from chain_key + call_nonce via HKDF (not communicated)
- Clarify SRTP profiles: AEAD_AES_128_GCM (RFC 7714) as mandatory;
ChaCha20-Poly1305 noted as non-standard Cryptic-specific extension
- Fix Cowboy callback return type: {[], State} instead of {ok, State}
- Add context for call_reject (additional signaling message) and
call_relay_frame (relay-mode only, Phase 2+)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Feasibility study for adding E2E encrypted audio calls between Cryptic users, covering transport architecture, encryption model, signaling protocol, and phased implementation path.
Key decisions
call_invite,call_answer,call_ice_candidate,call_hangup) over the existing WebSocket mTLS channel; server routes by looking up peer PID inuser_connectionsETScpal+opus+webrtc-rs); Erlang console limited to signaling commands in v1Phased delivery
Out of scope
Group calls (requires SFU), video, call recording.