Usage Guide

Usage Guide

This guide covers the day-to-day administration and usage of a running Burble instance.

Topology Modes

Burble can operate in four distinct topologies, controlled via the BURBLE_TOPOLOGY environment variable.

1. monarchic (Default): A single standalone server. Perfect for small communities, homelabs, or embedded deployments.
2. federated: Multiple servers communicating to share room state, acting as a unified cluster.
3. mesh: A serverless, fully distributed topology. Requires mandatory End-to-End Encryption (E2EE).
4. relay: Acts strictly as a relay for bridging (e.g., to Murmur/Mumble).

Room Management

Currently, rooms are ephemeral. They are created dynamically when the first user joins and destroyed when the last user leaves. Configuration for room limits, codecs, and access control is managed via the server/priv/schemas and config.yaml.

E2EE (End-to-End Encryption)

E2EE is supported and can be mandated at the server or room level. When E2EE is active, the Burble server only sees opaque encrypted RTP packets. It routes them based on unencrypted headers but cannot decode the payload, preserving user privacy.

Monitoring

Burble exposes telemetry data that can be consumed by Prometheus/Grafana. Key metrics include:

• Concurrent connections
• Room allocations
• UDP packet drop rates
• Zig NIF execution times