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.