Architecture du serveur

Structure des dossiers

server/
  room/           Domaine des salons P2P
  friends/        Domaine des amis et des MP
  calls/          Domaine des appels audio/vidéo
  profile/        Domaine du profil utilisateur local
  identity/       Domaine de l'identité cryptographique
  messages/       Domaine des messages de discussion

Chaque dossier de domaine suit le même modèle :

Fichier	Rôle
store.ts	Lit et écrit les données sur le disque
utils.ts	Fonctions utilitaires pures
handler.ts	Gestionnaires de messages WebSocket
events.ts	Gestionnaires d’événements P2P
watcher.ts	Abonnements P2P en direct (salons uniquement)
tracker.ts	État d’exécution en mémoire (appels uniquement)

Responsabilités des domaines

room/

Tout ce qui concerne les salons P2P : conserver les salons rejoints, surveiller les mises à jour en direct, interroger l’historique du salon pour connaître l’état de propriété et de modération, et traiter tous les messages WebSocket liés aux salons (créer, rejoindre, quitter, opérations d’administration).

friends/

Le système d’amis : conserver la liste d’amis, utilitaires de recherche purs, traiter les messages WebSocket de demande/acceptation/suppression d’ami, et traiter les événements P2P d’amis entrants (rejoindre les salons de MP lors de l’acceptation).

calls/

Appels audio/vidéo : suivre quels appels sont actuellement actifs en mémoire et relayer les messages WebSocket de signalisation d’appel (démarrer, rejoindre, relais de signal, terminer) à travers le journal du salon. PeerJS s’exécute dans le navigateur ; le serveur ne fait que transmettre les charges utiles opaques call-signal, il n’a donc besoin d’aucun broker PeerServer.

profile/

Les données visibles de l’utilisateur local : conserver le nom, l’avatar et le statut de présence sur le disque, fonctions utilitaires pour normaliser la présence et générer des noms d’utilisateur anonymes, et traiter les messages WebSocket de mise à jour de profil.

identity/

Opérations d’identité cryptographique : traiter les messages WebSocket pour la sauvegarde de la phrase de récupération, l’import de la phrase de récupération et la réinitialisation de la base de données locale. La logique d’identité centrale réside dans lib/identity.ts.

messages/

Opérations sur les messages de discussion : traiter tous les messages WebSocket liés aux messages (envoyer, modifier, réagir, épingler, téléverser/télécharger des fichiers, gestion des canaux, émojis personnalisés).

Fichiers au niveau du serveur

Fichier	Rôle
server.ts	Point d’entrée
ws-dispatch.ts	Achemine les messages WebSocket entrants vers le bon gestionnaire
context.ts	Types partagés : SessionContext et PipelineContext
broadcast.ts	Envoie les messages à tous les clients WebSocket connectés
http-handler.ts	Sert les fichiers statiques du client et gère l’endpoint de réinitialisation
quibble-init.ts	Initialise le nœud P2P avec une logique de réessai pour le verrou de stockage
rtc.ts	Résout la liste des serveurs ICE envoyée aux clients (délègue à lib/rtc-config.ts)
net.ts	Trouve un port TCP libre au démarrage

Serveurs ICE

À la connexion, le serveur envoie à chaque client un message rtc-config contenant la liste des serveurs ICE. Les valeurs par défaut proviennent de lib/rtc-config.ts (STUN de Cloudflare + TURN partagé de Metered). On peut les remplacer avec des variables d’environnement :

• QUIBBLE_ICE_SERVERS_JSON : un tableau JSON complet de { urls, username?, credential? }, utilisé tel quel.

• TURN_URL, TURN_USERNAME, TURN_CREDENTIAL : dirige tous les clients vers votre propre serveur TURN.

Les utilisateurs peuvent aussi configurer leur propre serveur STUN/TURN dans les Paramètres, ce qui remplace localement les valeurs par défaut du serveur. Voir stun-turn.md.