Bedrud ist ein Monorepo mit einem Go-Server, drei Client-Anwendungen, Python-Bot-Agenten und gemeinsam genutzten Paketen. Diese Seite beschreibt, wie die Komponenten zusammenhängen.

Allgemeines Diagramm

flowchart TB
    subgraph Clients ["Clients"]
        Web["Web<br/>React"]
        Android["Android<br/>Compose"]
        iOS["iOS<br/>SwiftUI"]
        Desktop["Desktop<br/>Rust + Slint"]
    end
 
    subgraph Server ["Bedrud Server"]
        Router["Fiber HTTP Router<br/>/api/auth/* /api/room/* /api/admin/*"]
        DB["GORM / SQLite<br/>(or PostgreSQL)"]
        LKSDK["LiveKit Protocol SDK<br/>(token generation, room management)"]
        LiveKit["Embedded LiveKit<br/>Media Server (WebRTC)"]
    end
 
    Clients -->|"REST API + WebSocket"| Router
    Router --> DB
    Router --> LKSDK
    LKSDK --> LiveKit

Komponenten

Server (server/)

Das Go-Backend ist der Kern von Bedrud. Es ist verantwortlich für:

• REST API - Authentifizierung, Raumverwaltung, Administratoroperationen
• Statische Dateiauslieferung - Das kompilierte Web-Frontend wird über //go:embed eingebettet
• LiveKit-Integration - Erstellt Token und verwaltet Räume über das LiveKit Protocol SDK
• Eingebetteter LiveKit-Server - Der Media-Server-Binary läuft als Kindprozess

Der Server verwendet das Fiber-Webframework (ähnlich wie Express.js in Node.js) und GORM als ORM-Schicht. Er unterstützt SQLite für die Entwicklung und PostgreSQL für den Produktivbetrieb.

Siehe Server-Architektur für Details.

Web-Frontend (apps/web/)

Eine React-Anwendung, die mit TanStack Start, TailwindCSS v4 und shadcn/ui erstellt wurde. Im Produktivbetrieb wird sie auf dem Server vorgerendert und die Client-Assets werden in das Go-Binary eingebettet.

Wichtige Funktionen:

• Video-Meeting-Benutzeroberfläche mit LiveKit Client SDK
• JWT-basierte Authentifizierung mit automatischem Token-Refresh
• Admin-Dashboard für Benutzer- und Raumverwaltung
• Designsystem mit einheitlicher Komponentenbibliothek

Siehe Web-Frontend für Details.

Android-App (apps/android/)

Eine native Android-App, die mit Jetpack Compose und Kotlin erstellt wurde. Verwendet Koin für Dependency Injection und Retrofit für HTTP.

Wichtige Funktionen:

• Vollständiges Video-Meeting-Erlebnis mit LiveKit Android SDK
• Picture-in-Picture-Modus
• Deep Link-Verarbeitung (bedrud.com/m/* und bedrud.com/c/*)
• Anrufverwaltung mit Androids ConnectionService
• Multi-Instance-Unterstützung (Verbindung zu mehreren Servern)

Siehe Android-App für Details.

iOS-App (apps/ios/)

Eine native iOS-App, die mit SwiftUI erstellt wurde. Verwendet KeychainAccess für die sichere Speicherung von Anmeldeinformationen und LiveKit Swift SDK für Medien.

Wichtige Funktionen:

• Vollständiges Video-Meeting-Erlebnis
• Multi-Instance-Unterstützung
• Deep Link-Verarbeitung
• Keychain-basierte sichere Speicherung

Siehe iOS-App für Details.

Desktop-App (apps/desktop/)

Eine native Windows- und Linux-Desktopanwendung, die mit Rust und dem Slint-UI-Toolkit erstellt wurde. Kompiliert zu einem einzelnen Binary ohne Laufzeitabhängigkeiten.

Wichtige Funktionen:

• Vollständiges Video-Meeting-Erlebnis über das LiveKit Rust SDK
• Natives Windows (Direct3D 11) und Linux (OpenGL/Vulkan) Rendering
• Multi-Instance-Unterstützung (Verbindung zu mehreren Bedrud-Servern)
• OS-Keyring-Integration für sichere Speicherung von Anmeldeinformationen

Siehe Desktop-App für Details.

Bot-Agenten (agents/)

Python-Skripte, die als Bots an Meeting-Räumen teilnehmen und Medieninhalte streamen:

• Music Agent - Spielt Audiodateien ab
• Radio Agent - Streamt Internet-Radiosender
• Video Stream Agent - Teilt Videoinhalte (HLS, MP4)

Siehe Bot-Agenten für Details.

Authentifizierungsablauf

sequenceDiagram
    participant Client
    participant Server
    participant Database
 
    Client->>Server: POST /api/auth/login
    Server->>Database: verify credentials
    Database-->>Server: credentials valid
    Server-->>Client: access + refresh JWT
 
    Client->>Server: GET /api/room/list
    Note right of Server: "Authorization: Bearer <access_token>"
    Server-->>Client: room list

Alle authentifizierten Anfragen verwenden JWT-Token im Authorization-Header. Der authFetch-Wrapper des Web-Frontends übernimmt das Anhängen des Tokens und das automatische Refresh.

Unterstützte Authentifizierungsmethoden:

Meeting-Verbindungsablauf

sequenceDiagram
    participant C as Client
    participant S as Bedrud Server
    participant LK as LiveKit SFU
 
    C->>S: POST /api/room/join
    S->>S: Validate permissions
    S->>C: LiveKit JWT token
    C->>LK: WebSocket connect (with token)
    LK->>C: SDP offer + join response
 
    Note over C,LK: ICE connectivity check
    C->>LK: Host + STUN + TURN candidates
 
    alt Direct path (UDP)
        C-->>LK: Media via UDP 50000-60000
    else TURN relay
        C-->>LK: Media via TURN relay
    end
 
    Note over C,LK: Audio/video tracks flow through SFU

1. Der Client fordert über die REST API den Beitritt zu einem Raum an
2. Der Server validiert die Berechtigungen und generiert ein signiertes LiveKit-Token
3. Der Client verbindet sich direkt über WebSocket mit LiveKit unter Verwendung des Tokens
4. ICE sammelt Kandidaten (Host, STUN, TURN) und wählt den besten Pfad aus
5. Audio-/Video-Tracks werden über die SFU von LiveKit geleitet

Siehe WebRTC-Konnektivität für den vollständigen Verbindungs-Stack.

Datenmodell

Benutzer

Raum

Passkey

RefreshToken

Bereitstellungsarchitektur

Im Produktivbetrieb läuft Bedrud als zwei systemd-Dienste:

Beide werden von einem einzelnen Binary verwaltet. Traefik oder ein anderer Reverse Proxy übernimmt die TLS-Terminierung und leitet den Datenverkehr weiter.

Siehe Bereitstellungsleitfaden für Einrichtungsanweisungen.

Schlüsselbegriffe

Diese Begriffe tauchen in der gesamten Architekturdokumentation auf:

Siehe auch

• WebRTC-Konnektivität - vollständiger STUN/ICE/TURN/SFU-Verbindungs-Stack
• TURN-Server-Leitfaden - TURN-Relay-Architektur und Konfiguration
• LiveKit-Integration - wie Bedrud LiveKit einbettet