System overview
Trinity is one end-to-end encrypted Matrix client delivered through four host environments. The Angular application and its libraries are shared; the Web/PWA runs the bundle directly, while Capacitor and Electron package the same root www/ output.
Runtime shape
Section titled “Runtime shape”The main parts have distinct responsibilities:
| Part | Responsibility |
|---|---|
apps/trinity | Select routes, environment values, lazy features, and application providers |
| Application libraries | Coordinate startup, workspace navigation, appearance, search, and badge state across capabilities |
| Data-access libraries | Own product capability state and isolate Matrix SDK access |
| Feature libraries | Present workflows and connect UI to capability APIs |
| Component libraries | Provide reusable, domain-neutral Trinity controls and layouts |
| Runtime libraries | Supply policy-free projection, preference, and host primitives |
| Host adapters | Translate browser, Capacitor, and Electron behavior into shared host contracts |
provideTrinityApplication() is the host-neutral composition boundary. It installs zoneless Angular change detection, the router, capability providers, shared UI providers, host capabilities, and the Application Runtime adapter. The application entrypoint supplies routes, environment configuration, build information, and lazy dialog loaders.
Startup and steady state
Section titled “Startup and steady state”Application Runtime owns ordered startup: negotiate the host, hydrate preferences, restore accounts, prepare session capabilities, restore Workspace, then open readiness and ongoing session streams. A feature does not start a parallel application lifetime.
After startup, capability services project authoritative Matrix or host events into read-only signals. Feature components render those signals and invoke finite commands. The result of a command normally returns through the same event projection rather than a second hand-maintained application store.
How requests move
Section titled “How requests move”A typical room action moves through these boundaries:
- A feature component invokes a public data-access command.
- The data-access adapter calls
matrix-js-sdkfor the exact active account and room. - SDK events invalidate or reconcile the owned projection.
- Read-only signals update the
OnPushUI. - Workspace remains responsible for the canonical destination and browser history.
Use capability ownership to select the owner, dependency boundaries before adding an import, and host capabilities before branching on an environment.