Bedrud est un monorepo contenant un serveur Go, trois applications client, des agents bot Python et des packages partagés. Cette page décrit comment les composants sont liés entre eux.

Diagramme de haut niveau

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

Composants

Serveur (server/)

Le backend Go est le cœur de Bedrud. Il gère :

• REST API - authentification, gestion des salles, opérations d’administration
• Static file serving - le frontend web compilé est intégré via //go:embed
• Intégration LiveKit - génère des tokens et gère les salles via le LiveKit Protocol SDK
• Embedded LiveKit server - le binaire du serveur média s’exécute en tant que processus enfant

Le serveur utilise le framework web Fiber (similaire à Express.js dans Node.js) et GORM comme couche ORM. Il prend en charge SQLite pour le développement et PostgreSQL pour la production.

Voir Architecture du serveur pour plus de détails.

Web Frontend (apps/web/)

Une application React construite avec TanStack Start, TailwindCSS v4 et shadcn/ui. En production, elle est pré-rendue sur le serveur et les assets client sont intégrés dans le binaire Go.

Capacités clés :

• Video meeting UI avec LiveKit Client SDK
• JWT-based authentication avec rafraîchissement automatique des tokens
• Admin dashboard pour la gestion des utilisateurs et des salles
• Design system avec une bibliothèque de composants cohérente

Voir Frontend web pour plus de détails.

Android App (apps/android/)

Une application Android native construite avec Jetpack Compose et Kotlin. Utilise Koin pour l’injection de dépendances et Retrofit pour HTTP.

Capacités clés :

• Expérience complète de réunion vidéo avec LiveKit Android SDK
• Picture-in-picture mode
• Deep link handling (bedrud.com/m/* et bedrud.com/c/*)
• Call management avec Android’s ConnectionService
• Multi-instance support (connexion à plusieurs serveurs)

Voir Application Android pour plus de détails.

iOS App (apps/ios/)

Une application iOS native construite avec SwiftUI. Utilise KeychainAccess pour le stockage sécurisé des identifiants et LiveKit Swift SDK pour les médias.

Capacités clés :

• Expérience complète de réunion vidéo
• Multi-instance support
• Deep link handling
• Keychain-based secure storage

Voir Application iOS pour plus de détails.

Desktop App (apps/desktop/)

Une application de bureau native Windows et Linux construite avec Rust et le Slint UI toolkit. Compile en un seul binaire sans dépendances d’exécution.

Capacités clés :

• Expérience complète de réunion vidéo via LiveKit Rust SDK
• Native Windows (Direct3D 11) et Linux (OpenGL/Vulkan) rendering
• Multi-instance support (connexion à plusieurs serveurs Bedrud)
• OS keyring integration pour le stockage sécurisé des identifiants

Voir Application de bureau pour plus de détails.

Bot Agents (agents/)

Scripts Python qui rejoignent les salles de réunion en tant que bots et diffusent du contenu média :

• Music Agent - lit des fichiers audio
• Radio Agent - diffuse des stations de radio Internet
• Video Stream Agent - partage du contenu vidéo (HLS, MP4)

Voir Agents bots pour plus de détails.

Authentication Flow

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

Toutes les requêtes authentifiées utilisent des tokens JWT dans l’en-tête Authorization. Le web frontend’s authFetch wrapper gère l’attachement des tokens et le rafraîchissement automatique.

Méthodes d’authentification prises en charge :

Meeting Connection Flow

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. Le client demande à rejoindre une salle via l’API REST
2. Le serveur valide les permissions et génère un token LiveKit signé
3. Le client se connecte directement à LiveKit via WebSocket en utilisant le token
4. ICE rassemble les candidats (host, STUN, TURN) et sélectionne le meilleur chemin
5. Audio/video tracks flow through LiveKit’s SFU

Voir Connectivité WebRTC pour la pile de connectivité complète.

Data Model

User

Room

Passkey

RefreshToken

Deployment Architecture

En production, Bedrud s’exécute comme deux systemd services :

Les deux sont gérés par un seul binaire. Traefik ou un autre reverse proxy gère la TLS termination et routes le trafic.

Voir Guide de déploiement pour les instructions de configuration.

Key Terms

Ces termes apparaissent dans toute la documentation de l’architecture :

Voir aussi

• Connectivité WebRTC - pile de connectivité complète STUN/ICE/TURN/SFU
• Guide du serveur TURN - architecture et configuration du relai TURN
• Intégration LiveKit - comment Bedrud intègre LiveKit