readme.md
keks-meet
a simple secure web conferencing application
Features
- Ability to share different kinds of media:
- Camera
- Microphone
- Screen capture
- Files
- End-to-end-encryption (including p2p negotiation, chat and p2p traffic)
- Peer-to-peer data transmission
- Multiple streams of any type
- Noise suppression (using RNNoise)
- Rooms (created on demand, do not persist)
- Chat (supports text and images)
- Minimal user-interface
- Should work with screen readers
Licence
Licensed under the terms of the GNU Affero General Public License version 3 only
with exception of the icons found withing client-web/assets/icons
, which are
Apache-2.0 licensed. See COPYING.
Usage
For trying it out, a hosted version is available on meet.metamuffin.org. For self-hosting, this should help:
pacman -S --needed esbuild rustup make coreutils curl tar; rustup install nightly
git clone https://codeberg.org/metamuffin/keks-meet.git
cd keks-meet
make install-server # binaries will be installed to ~/.cargo/bin
keks-meet-server config/default.toml
When changing code, use make watch
to re-build things automatically as needed.
(requires cargo install systemfd cargo-watch
)
The server takes a path to the configuration file as its first argument unless
the embed_config
feature is used. In that case, the configuration is read from
config/config.toml
and embedded into the server binary.
The server's bind address can be controlled using the BIND
environment
variable. When compilin without debug assertions (release) all assets are
embedded into the binary; This is a speedup and allows the server to run from
just the binary.
If you use this project or have any suggestions, please contact me
Rift
Rift is similar to the magic wormhole, except that it's peer-to-peer. It reuses the keks-meet signaling protocol to establish a WebRTC data channel.
pacman -S --needed rustup; rustup install nightly
cargo +nightly install --path client-native-rift
rift --help
rift --secret hunter2 send /path/to/file &
rift --secret hunter2 receive /path/to/output
Security
keks-meet tries to be secure. However I am not a security expert. The current system works as follows:
- The room name is set in the section of the URL which is not sent to the server.
- The server receives a salted SHA-256 hash of the room name to group clients of a room.
- The client uses PBKDF2 (constant salt; 250000 iterations) to derive a 256-bit AES-GCM key from the room name.
- All relayed message contents are encrypted with this key.
- Message recipient is visible to the server
- The server assigns user ids
Keybinds
Keybind | Action |
---|---|
C-RET |
Toggle chat |
M |
Add microphone track |
R |
Add microphone track (but with your left hand) |
C |
Add camera track |
S |
Add screencast track |
C-c |
End all tracks |
C-v * |
Paste image in chat (does not require chat to be shown) |
Debugging
- If a connection cant be established, look at it with
webrtc_debug
enabled. - In case downloading files doesn't work, check if the service worker was
installed correctly by visiting
/swtest
- If it still doesn't work, file a bug report.
Parameters
Some configuration parameters can be added like query params but after the
section. (e.g /room#mymeeting?username=alice
) The page will not automatically
reload if the section changes. Booleans can be either 1
, true
, yes
or
their opposites. A convenience function for changing params is also exported:
window.change_pref(key, value)
Option name | Type | Default | Description |
---|---|---|---|
username |
string | "guest-…" |
Username |
warn_redirect |
boolean | false |
Internal option that is set by a server redirect. |
image_view_popup |
boolean | true |
Open image in popup instead of new tab |
webrtc_debug |
boolean | false |
Show additional information for WebRTC related stuff |
microphone_enabled |
boolean | false |
Add one microphone track on startup |
screencast_enabled |
boolean | false |
Add one screencast track on startup |
camera_enabled |
boolean | false |
Add one camera track on startup |
rnnoise |
boolean | true |
Use RNNoise for noise suppression |
native_noise_suppression |
boolean | false |
Suggest the browser to do noise suppression |
microphone_gain |
number | 1 |
Amplify microphone volume |
video_fps |
number | - | Preferred framerate (in 1/s) for screencast and camera |
video_resolution |
number | - | Preferred width for screencast and camera |
camera_facing_mode |
string | - | Prefer user-facing or env-facing camera ("environment" / "user" ) |
auto_gain_control |
boolean | - | Automatically adjust mic gain |
echo_cancellation |
boolean | - | Cancel echo |
audio_activity_threshold |
number | 0.003 |
Audio activity threshold |
optional_audio_default_enable |
boolean | true |
Enable audio tracks by default |
optional_video_default_enable |
boolean | false |
Enable video tracks by default |
notify_chat |
boolean | true |
Send notifications for incoming chat messages |
notify_join |
boolean | true |
Send notifications when users join |
notify_leave |
boolean | true |
Send notifications when users leave |
enable_onbeforeunload |
boolean | true |
Prompt for confirmation when leaving the site while local resources are active |
room_watches |
string | "public" |
Known rooms (as semicolon seperated list of name=secret pairs) |
Protocol
The protocol packets are defined in packets.d.ts. Here are some simplified examples of how the protocol is used.
S->C { init: { your_id: 5, version: "..." } }
---- # Your join packet will be the first one.
S->C { client_join: { id: 5 } }
S->C { client_join: { id: 3 } }
---- # The server doesnt know people's names so they identify themselves.
S->C { message: { sender: 3, message: <Encrypted { identify: { username: "Alice" } }> } }
---- # You should do that too.
C->S { relay: { message: <Encrypted { identify: { username: "Bob" } }> } }
---- # Publish your ICE candidates.
C->S { relay: { message: <Encrypted { ice_candiate: <RTCIceCandidateInit> }> } }
---- # If you create a resource, tell others about it:
C->S { relay: { message: <Encrypted { provide: { id: "asd123", label: "Camera", kind: "track", track_kind: "video" } }> } }
---- # If somebody is interested in this resource, they will request you to transmit.
S->C { message: { sender: 3, message: <Encrypted { request: { id: "asd123" } }> } }
---- # Whenever you change your tracks/data channels:
---- # Send an offer to everybody
C->S { relay: <Encrypted { recipient: 3, offer: <RTCSessionDescriptionInit> }> }
---- # Await answer:
S->C { message: { sender: 3, message: <Encrypted { offer: <RTCSessionDescriptionInit> }> } }
---- # In case the server uses a reverse-proxy that disconnects inactive connections: Ping every 30s
C->S { ping: null }
If you decide to implement this protocol, please make sure it is compatible, especially ensure that channels/tracks are only added on request and to not reuse existing identifiers for new protocol packets.