Architecture technique
Composants, frontières de processus, état local, fournisseur, transport et Worker.
#Processus PC
L’interface et les services de fond partagent des modules Python pour configuration, agent, conversations, mémoire, voix et connecteurs. Le serveur mobile expose le protocole applicatif aux transports, et un coordinateur attribue un bail à un seul chemin autoritaire.
#Application mobile
Flutter sépare interface, stockage sécurisé, WebSocket/relais, LAN, WebRTC, audio, notifications et coordination de transport. Le coordinateur transfère une connexion validée au chat, qui utilise identifiants de tour et de conversation pour l’idempotence.
#Infrastructure
Le Worker de rendez-vous associe une clé opaque à une origine temporaire. Le Worker de relais utilise un Durable Object par session pour connecter les rôles, appliquer la politique E2E et gérer pression, fragments et durée de session. Aucun de ces services n’est le fournisseur de modèle.
#État et flux
| État | Autorité | Persistance |
|---|---|---|
| Conversations | PC | Fichiers JSON atomiques. |
| Réglages et clés | PC | Fichiers de données utilisateur séparés. |
| Mémoire | PC | Schéma JSON versionné. |
| Association et identités LAN mobile | Téléphone | Stockage sécurisé de l’application. |
| Session de relais | Durable Object | État opérationnel de connexion, pas archive de conversation. |
Provenance de cette page
Faits produit vérifiés sur PC 7b6b3b000b89, mobile d492cc89cf77 et Worker f07e239bd455.
Sources consultées
- PC: osia/server/server.py
- PC: docs/webrtc-direct.md
- Mobile: lib/services/transport/
- Worker: src/relay.js et src/relay_policy.js