Compare commits

9 Commits

Author SHA1 Message Date
47beed01ca docs: add cross-context feature docs for auth, presence, access-control, messaging, attachments
Fills the five highest-value gaps under agents-docs/features/ so the index covers
the system's main cross-context contracts. Each doc follows the feature-template
structure and the AGENTS_FEATURES.md contract, with honest TODOs where coverage
or behavior couldn't be confirmed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 22:33:41 +02:00
d5ef0b84d8 add skills 2026-05-25 15:38:26 +02:00
b19c39208c docs: populate initial cross-context feature docs
Add area-level documentation for the five most significant cross-context
feature areas under agents-docs/features/:

- websocket-envelopes: full envelope catalogue, lifecycle, dispatcher
- ipc-bridge: window.electronAPI surface, IPC channels, CQRS dispatch
- plugin-system: manifest contract, runtime, capabilities, plugin-support API
- server-directory: REST endpoints, CQRS, entities, business rules
- voice-signaling: mesh signaling, RNNoise pipeline, domain split

Update agents-docs/FEATURES.md index alphabetically and remove the
"no cross-context feature docs" placeholder.

Each doc records honest TODOs for verified gaps (stale signaling-contracts.ts,
window.api vs window.electronAPI mismatch, IPC error envelope drift from
CONTEXT.md, missing OpenAPI coverage for server-directory routes, no
envelope round-trip test).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 15:36:36 +02:00
c48b6e9c94 docs: scaffold agent instruction tree
Add AGENTS.md, CLAUDE.md, and the agents-docs/ tree (workflow, lessons,
engineering standards, context map, ADR seed, feature template) plus a
domain-bearing CONTEXT.md for each of the six subdomains: toju-app,
electron, server, e2e, website, docs-site.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 00:02:02 +02:00
Myx
232a9ea8ea test: Ensure tests work after latest changes
All checks were successful
Queue Release Build / prepare (push) Successful in 17s
Deploy Web Apps / deploy (push) Successful in 7m20s
Queue Release Build / build-windows (push) Successful in 25m4s
Queue Release Build / build-linux (push) Successful in 33m59s
Queue Release Build / finalize (push) Successful in 41s
2026-05-19 00:52:28 +02:00
Myx
54e8b9a5e4 feat: Update how messages load and sync, allow plugins to import messages
All checks were successful
Queue Release Build / prepare (push) Successful in 23s
Deploy Web Apps / deploy (push) Successful in 7m36s
Queue Release Build / build-windows (push) Successful in 28m3s
Queue Release Build / build-linux (push) Successful in 44m14s
Queue Release Build / finalize (push) Successful in 39s
2026-05-18 23:21:09 +02:00
Myx
94428ed170 fix: Mobile style fixes and other small ui fixes 2026-05-18 23:20:32 +02:00
Myx
afb64520ed perf: server navigation 2026-05-18 19:38:08 +02:00
Myx
0152ed9dd2 fix: memory leak hunting and reconnecting on data error 2026-05-18 19:37:30 +02:00
99 changed files with 5359 additions and 485 deletions

View File

@@ -0,0 +1,150 @@
---
name: document-features
description: Populate `<docs-dir>/features/<slug>.md` for one, several, or every undocumented feature area by dispatching up to 10 parallel subagents — one per feature. The agent docs directory is discovered from `AGENTS.md` — typically `agents-docs/` (the `setup-agentic-repository` default) but may be elsewhere if `--docs-dir` was used. Use whenever the user wants to document features, fill out feature docs, write up specific features (e.g. "document auth and billing"), document all undocumented features, or follow up on `find-features` discovery. This is the natural sequel to `find-features` — that skill identifies what is missing, this skill writes the docs in parallel.
metadata:
author: Olof Brogeby
url: https://github.com/brogeby
---
# document-features
Write feature documentation for the repository — one populated `<docs-dir>/features/<slug>.md` per requested feature — by dispatching subagents in parallel so an "all" run does not serialize. The agent docs directory (`<docs-dir>`) is discovered in Phase 1; it's typically `agents-docs/` but `setup-agentic-repository` may have written it somewhere else.
This skill is the documentation counterpart to `find-features`. `find-features` discovers what is missing; `document-features` is the focused worker that actually fills the template, in parallel, for the features the user names.
If the user asks "find and document everything", you can start with `find-features` to build the candidate list, then hand that list to this skill. If the user already knows which features they want (e.g. "document auth and billing"), come straight here.
---
## Phase 1 — Verify prerequisites and locate the docs directory
Confirm the repo has been initialized with the Mimas template, and discover where its agent docs actually live. `setup-agentic-repository` writes the agent doc tree to **`agents-docs/`** by default (a sibling of any human-maintained `docs/`), but `--docs-dir <dir>` can override that (e.g. `docs/agents`). Don't assume the path; discover it.
1. Read `AGENTS.md` at the repo root. Every Mimas-generated `AGENTS.md` lists its docs paths in the first block (`<docs-dir>/AGENT_WORKFLOW.md`, `<docs-dir>/AGENTS_FEATURES.md`, etc.) — the directory in those paths is the docs dir for this repo.
2. If `AGENTS.md` doesn't exist or doesn't reference the contract files, fall back to searching for `AGENTS_FEATURES.md` directly (`find . -maxdepth 3 -name AGENTS_FEATURES.md`). The directory containing it is the docs dir.
3. Confirm the files this skill needs are there:
- `<docs-dir>/AGENTS_FEATURES.md` — feature documentation contract
- `<docs-dir>/features/feature-template.md` — canonical template
- `<docs-dir>/FEATURES.md` — feature index
If any are missing, tell the user this skill is designed to run after `setup-agentic-repository` and stop. Do not scaffold them yourself.
For the rest of this skill, treat the discovered directory as `<docs-dir>` and use it wherever paths appear. **Critical:** the subagent prompt in Phase 3 is a template — substitute the actual discovered value into it before dispatching each subagent. The subagents do not run this Phase 1 themselves and will not discover the dir on their own.
Read `<docs-dir>/AGENTS_FEATURES.md` and the root `AGENTS.md` (plus any subdomain `CONTEXT.md` files) so you know the contract — what counts as an area-level doc vs. a per-service doc, and which subdomains exist. These files are authoritative; if anything in this skill drifts from them, the files win.
---
## Phase 2 — Decide what to document
The user's request usually contains the answer. Parse what they said:
- **Named features** ("document auth and billing", "write up the search feature") → take that list of slugs
- **A number** ("document 3 features", "write up the top 5") → take a numeric count of the most significant undocumented features
- **"all" / "every" / "everything"** → every undocumented feature with meaningful implementation
- **Ambiguous or empty** → use `AskUserQuestion` with the same options find-features uses (Top 5 / All / Number / Specific names) plus an "Other" free-text fallback
If the user is continuing from a recent `find-features` session, prefer the candidate list that already exists in the conversation over re-asking.
Then quickly inventory `<docs-dir>/features/`:
- Top-level `.md` files (one per documented area, ignoring `feature-template.md`)
- Subdirectories (areas with per-service docs)
- Entries in `<docs-dir>/FEATURES.md`
Filter the requested list against the inventory:
- Drop slugs that already have `<docs-dir>/features/<slug>.md`. Tell the user which ones you skipped and why
- For named features that you cannot locate in the codebase, surface them and ask whether to skip or scaffold a TODO doc. Do not invent feature areas
If the user asked for a number or "all" and you need to identify candidates yourself, scan the subdomains declared in `AGENTS.md` looking for named concepts with dedicated logic — dedicated service layer, non-trivial handler, dedicated tables/migrations, multiple endpoints, real business rules. A single empty route stub is not enough. Rank by significance and trim to the requested count.
---
## Phase 3 — Dispatch one subagent per feature, in parallel
This is the whole point of the skill. Documentation per feature is independent work — one subagent can read the code for `auth` while another reads the code for `billing`. Serializing them throws away the parallelism the harness gives you.
**Cap concurrency at 10 subagents.** If the final list has more than 10 features, dispatch the first batch of 10 in one message, wait for it to complete, then dispatch the next batch. Do not exceed 10 concurrent agents — it overwhelms tooling and the user's review can't keep up.
For each feature in the current batch, spawn one `Agent` call in the **same message** (this is what makes them run in parallel). Use the `general-purpose` subagent unless something more specific fits.
Each subagent gets a self-contained prompt — it has not seen this conversation, so include everything it needs. **Before dispatching, substitute `<docs-dir>` with the value you discovered in Phase 1** (typically `agents-docs`). The subagents do not discover the dir on their own.
```
You are documenting a single feature area for this repository. The output is one populated markdown file at `<docs-dir>/features/<slug>.md` that follows the project's feature documentation contract.
Feature slug: <slug>
One-line concept (from discovery, may be rough): <concept>
Authoritative reading order (read these first, in order):
1. `<docs-dir>/AGENTS_FEATURES.md` — the contract that governs how feature docs are written
2. `<docs-dir>/features/feature-template.md` — the canonical template. Mirror its section order and headings; do not invent your own structure
3. `AGENTS.md` and any subdomain `CONTEXT.md` files — for vocabulary and where the code lives
Your task:
- Locate this feature in the codebase. Confirm it has meaningful implementation (service layer, handler, endpoints, tables, real business rules). If it is only a stub, stop and report that back — do not write a doc for a stub
- Create `<docs-dir>/features/<slug>.md` from the template
- Fill in what you can verify from the code: overview, responsibilities, key concepts, endpoint(s), service/handler/repository paths, key types, tests location, related features
- Set `Area:` to the slug, `Status:` to `Active` for production code or `In Progress` for half-built features, and `Last updated:` to today's date in `YYYY-MM-DD`
- For sections you cannot confidently fill (performance, security review, undocumented edge cases), keep the template's prompt and add a clear `TODO:` marker. Honest gaps beat invented content
- If the feature has multiple distinct services or endpoints worth separating, also create `<docs-dir>/features/<slug>/<service>.md` files from the same template and link them from the area doc — but only when complexity actually warrants it. Do not duplicate large sections between area and per-service docs
- Do not edit `<docs-dir>/FEATURES.md` — the dispatcher will update the index once all features are written, to avoid concurrent edits to the same file
- Do not commit anything
Report back when done with:
- Path(s) of the file(s) you created
- One-line description of the feature (this will be used for the FEATURES.md entry)
- Which template sections you left as TODO
- Anything you noticed that needs human judgment
```
Substitute `<slug>`, `<concept>`, and `<docs-dir>` per feature. Keep the rest verbatim — the subagent depends on having the contract in its own context.
If features turn out to be unrelated to one another (different subdomains, different layers), there's no need to coordinate beyond avoiding the shared `<docs-dir>/FEATURES.md` file. The dispatcher updates the index after the batch returns.
---
## Phase 4 — Update the index and report back
Once a batch completes, collect each subagent's reported one-liner and add entries to `<docs-dir>/FEATURES.md` in alphabetical order, in the form:
```
- [<slug>](./features/<slug>.md) — one-line description
```
If `<docs-dir>/FEATURES.md` still contains the placeholder `_No feature areas documented yet. Add entries as you build out the system._`, remove that line as you add the first real entry.
Then, if more features remain (because the original list was >10), dispatch the next batch of up to 10 and repeat.
When everything is written, tell the user:
- Which feature docs were created (full paths), grouped by batch if there were multiple
- Which requested features were skipped, and why ("already documented at `<docs-dir>/features/<slug>.md`", "could not locate in codebase", "implementation too thin to earn an entry yet")
- Which sections in the new docs are TODOs that still need human judgment
- That `<docs-dir>/FEATURES.md` was updated and how many entries were added
- Any discrepancies you noticed between `<docs-dir>/FEATURES.md` and the filesystem
Do not commit the changes. The user reviews before committing.
---
## Why this is structured around subagents
Documenting one feature is read-heavy and largely independent of documenting another — different files, different services, different endpoints. The slow part is the reading, and parallelizing the reading is the entire reason this skill exists separately from `find-features`. Spawning ten subagents in one message and letting them work concurrently turns a 10-minute sequential run into something closer to a 12 minute parallel one, with each subagent producing a focused, faithful doc because its whole context is one feature.
The 10-agent cap is pragmatic, not theoretical: more than that and you risk rate limits, output you can't usefully review at once, and the dispatcher running out of room to track which agent owns which slug. Two batches of ten is fine; ten batches of one is the failure mode this skill is designed to avoid.
---
## What makes a good output
**Faithful to the code.** Endpoint paths, file locations, method names, table names must match what is actually in the repo. If a subagent can't find something, the right move is a `TODO:` marker, not a guess.
**Concept-first for area docs.** The area-level doc explains what the feature is *for* — responsibilities, boundaries, vocabulary. Deep implementation detail belongs in per-service docs once they exist.
**Honest about gaps.** A clear `TODO: describe rate limiting` is more useful than a fabricated rate limit policy. Future sessions can fill these in from real information.
**Proportionate.** A small CRUD endpoint with one handler does not need every section of the template. Trim or skip sections that genuinely do not apply. The template is a checklist of what *might* be relevant, not a contract that every section must be populated.
**Honors the contract.** The structure, headings, and rules in `<docs-dir>/AGENTS_FEATURES.md` and `<docs-dir>/features/feature-template.md` win every time. If this skill's instructions ever drift from those files, the files are authoritative — they live with the project and are what other agents read.

View File

@@ -0,0 +1,35 @@
{
"skill_name": "document-features",
"evals": [
{
"id": 1,
"prompt": "find-features just listed auth, billing, and search as undocumented. Please go document all three.",
"expected_output": "Skill verifies prerequisites by discovering the agent docs directory (typically agents-docs/, but may be elsewhere — read from AGENTS.md), takes the three named features, inventories <docs-dir>/features/ to confirm none are already documented, dispatches one subagent per feature in a single message (so they run in parallel), substitutes the discovered <docs-dir> value into each subagent prompt before dispatching, then writes <docs-dir>/features/auth.md, <docs-dir>/features/billing.md, <docs-dir>/features/search.md from the template, and appends three entries to <docs-dir>/FEATURES.md (alphabetical). Leaves TODO markers where content cannot be derived from the code. Does not commit.",
"files": []
},
{
"id": 2,
"prompt": "document every undocumented feature in this repo",
"expected_output": "Skill discovers the docs dir, parses 'every' as 'all', identifies undocumented feature areas with meaningful implementation, dispatches subagents in parallel batches capped at 10 per batch (with the discovered <docs-dir> substituted into each subagent prompt), writes one doc per feature, and updates <docs-dir>/FEATURES.md. If there are more than 10 features, runs a second batch after the first finishes. Reports back which features were skipped and why.",
"files": []
},
{
"id": 3,
"prompt": "write the docs for billing",
"expected_output": "Skill discovers the docs dir, treats 'billing' as a single named feature, checks <docs-dir>/features/billing.md does not already exist, locates billing in the codebase, dispatches one subagent to document it (with <docs-dir> substituted into the prompt), writes <docs-dir>/features/billing.md from the template, and adds an entry to <docs-dir>/FEATURES.md. If billing already has a doc or cannot be located, the skill surfaces that instead of silently creating something.",
"files": []
},
{
"id": 4,
"prompt": "document the top 5 undocumented features",
"expected_output": "Skill discovers the docs dir, parses '5' as a numeric limit, identifies undocumented feature areas, ranks by significance, takes the top 5, dispatches 5 subagents in parallel in a single message (each with <docs-dir> substituted), writes 5 docs from the template, and updates <docs-dir>/FEATURES.md with 5 alphabetical entries. Other candidates are listed in the final report as 'not selected this round'.",
"files": []
},
{
"id": 5,
"prompt": "this repo uses --docs-dir docs/agents for its agent docs. document the auth feature.",
"expected_output": "Skill discovers the docs dir is docs/agents/ (from AGENTS.md path references), dispatches a single subagent with docs/agents substituted into the subagent prompt template, writes docs/agents/features/auth.md, and updates docs/agents/FEATURES.md. Does not hardcode agents-docs/ or docs/features/ — uses the discovered path everywhere.",
"files": []
}
]
}

View File

@@ -0,0 +1,149 @@
---
name: find-features
description: Discover feature areas in the current repository that are not yet documented under the agent docs `features/` tree (scaffolded by `setup-agentic-repository``agents-docs/features/` by default, or wherever `--docs-dir` put it), then create populated feature docs from the canonical template. Use whenever the user wants to find undocumented features, fill out `features/`, catch up on missing feature documentation, document feature X/Y/Z, or mentions "find features". This is the natural follow-up to `setup-agentic-repository`, which scaffolds the empty `features/` tree this skill populates.
metadata:
author: Olof Brogeby
url: https://github.com/brogeby
---
# find-features
Discover feature areas in this repository that are missing from `<docs-dir>/features/`, then create a populated markdown file for each one — following the contract in `<docs-dir>/AGENTS_FEATURES.md` and the template at `<docs-dir>/features/feature-template.md`. The agent docs directory (`<docs-dir>`) is discovered in Phase 1 — it's typically `agents-docs/` but `setup-agentic-repository` may have written it somewhere else.
The Mimas template (`setup-agentic-repository`) scaffolds an empty `<docs-dir>/features/` tree. This skill is the next step — it fills it in.
---
## Phase 1 — Verify prerequisites and locate the docs directory
Confirm the repo has been initialized with the Mimas template, and discover where its agent docs actually live. `setup-agentic-repository` writes the agent doc tree to **`agents-docs/`** by default (a sibling of any human-maintained `docs/`), but `--docs-dir <dir>` can override that (e.g. `docs/agents`). Don't assume the path; discover it.
1. Read `AGENTS.md` at the repo root. Every Mimas-generated `AGENTS.md` lists its docs paths in the first block (`<docs-dir>/AGENT_WORKFLOW.md`, `<docs-dir>/AGENTS_FEATURES.md`, etc.) — the directory in those paths is the docs dir for this repo.
2. If `AGENTS.md` doesn't exist or doesn't reference the contract files, fall back to searching for `AGENTS_FEATURES.md` directly (`find . -maxdepth 3 -name AGENTS_FEATURES.md`). The directory containing it is the docs dir.
3. Confirm the files this skill needs are there:
- `<docs-dir>/AGENTS_FEATURES.md` — feature documentation contract
- `<docs-dir>/features/feature-template.md` — the canonical template
- `<docs-dir>/FEATURES.md` — the feature index
If any of those are missing, tell the user this skill is designed to run after `setup-agentic-repository` and stop. Don't try to scaffold them yourself — that is the other skill's job.
For the rest of this skill, treat the discovered directory as `<docs-dir>` and use it wherever paths appear. Don't hardcode `docs/` or `agents-docs/` in your reasoning, prompts, or report.
Read `<docs-dir>/AGENTS_FEATURES.md` and the root `AGENTS.md` (plus any subdomain `CONTEXT.md` files) so you know:
- what counts as a feature area — a named concept with dedicated logic in the codebase, identified by naming and behavior, not folder structure alone
- the split between area-level docs (`<docs-dir>/features/<area>.md`) and per-service docs (`<docs-dir>/features/<area>/<service>.md`)
- which subdomains exist and where their code lives
These files define the contract you must satisfy. The whole point of the skill is to produce docs that look like a senior engineer on this project wrote them, following the rules already agreed in `AGENTS_FEATURES.md`.
---
## Phase 2 — Inventory what is already documented
List `<docs-dir>/features/` and capture, before asking the user anything:
- Top-level `.md` files (one per documented area) — ignore `feature-template.md`, it is the template
- Subdirectories under `<docs-dir>/features/` (areas with per-service docs)
- The entries listed in `<docs-dir>/FEATURES.md`
You will use this list to filter out features that already have an area doc. Discrepancies between the filesystem and `<docs-dir>/FEATURES.md` are worth flagging in your final report, but don't block on them.
---
## Phase 3 — Ask the user what to discover
Use `AskUserQuestion` to ask how many features (or which ones) to discover. Phrase the question so it accepts a number, "all", or a free-text list of names. The tool always offers an "Other" free-text fallback, so give a few sensible presets and let the user type a specific answer when none fit.
```
questions:
- question: "How many features would you like to discover, or which ones specifically?"
header: "Scope"
multiSelect: false
options:
- label: "Top 5 (Recommended)"
description: "Discover up to 5 of the most significant undocumented feature areas."
- label: "All"
description: "Find every undocumented feature area in the codebase."
- label: "A specific number (110)"
description: "I'll tell you a number from 1 to 10."
- label: "Specific names"
description: "I'll list the feature names I want documented (e.g. 'auth, billing, search')."
```
Parse whatever they answer with — accept a bare number, the word "all" (any case), or a comma- or space-separated list. Phrases like "find feature x, y, z" or "auth and billing" should yield `["x", "y", "z"]` and `["auth", "billing"]` respectively. Don't be strict about format; pull out the names.
If the user names features you can't locate in the codebase, surface that and ask whether to skip them or create scaffolded TODO docs for them. Do not silently invent them.
---
## Phase 4 — Discover undocumented feature areas
Scan the codebase for feature areas using the definition from `<docs-dir>/AGENTS_FEATURES.md`. Start from the subdomains declared in the root `AGENTS.md` — if there are several large subdomains, **launch one subagent per subdomain in parallel** so discovery doesn't serialize.
For each candidate feature, capture:
- **Slug** — kebab-case, ideally matching how the area is referenced in code or routes (e.g. `auth`, `billing`, `recruitment-content`)
- **One-sentence concept** — what the feature does, in user-facing terms
- **Where the code lives** — routes, services, handlers, components, modules
- **Significance signal** — at least one of: dedicated service layer, non-trivial handler, dedicated DB tables/migrations, multiple endpoints, real business rules. A single empty route stub is not enough
- **Whether it is already documented** — does `<docs-dir>/features/<slug>.md` exist already?
Then filter:
- Drop anything that already has an area-level doc
- Drop stubs and scaffolding — `<docs-dir>/AGENTS_FEATURES.md` says an entry must have meaningful implementation. Err on the side of leaving thin features out and noting them as "not yet earning an entry"
Rank what is left by significance (surface area, number of endpoints, depth of business logic), then trim to what the user asked for:
- **Number** → take the top N from the ranked list
- **"all"** → take everything that survived the filter
- **Named features** → take only those, matched by slug or close fuzzy match, warning about any that didn't match
---
## Phase 5 — Create the feature docs
For each chosen feature:
1. Read `<docs-dir>/features/feature-template.md` once and use it as the structural template — section order, headings, prompts. Do not invent your own structure.
2. Create `<docs-dir>/features/<slug>.md` populated from the template:
- Fill in what you can verify from the code: overview, responsibilities, key concepts, API endpoint(s), service/handler/repository paths, key types, tests location, related features
- Set **`Area:`** to the slug, **`Status:`** to `Active` for production code or `In Progress` for half-built features, and **`Last updated:`** to today's date in `YYYY-MM-DD`
- For sections you cannot confidently fill (performance characteristics, security review, edge cases nobody has documented), keep the template's prompt and add a clear TODO marker. Leaving an honest gap is better than inventing content
3. If the feature has multiple distinct services or endpoints worth separating, also create `<docs-dir>/features/<slug>/` and seed per-service docs (`<docs-dir>/features/<slug>/<service>.md`) from the same template, then link them from the area doc. Only do this when complexity actually warrants it — the contract says don't duplicate large sections between area and per-service docs
After writing each file, add an entry to `<docs-dir>/FEATURES.md` in alphabetical order, in the form:
```
- [<slug>](./features/<slug>.md) — one-line description
```
If `<docs-dir>/FEATURES.md` still contains the placeholder `_No feature areas documented yet. Add entries as you build out the system._`, remove that line as you add the first real entry.
---
## Phase 6 — Report back
Tell the user:
- Which feature docs were created (full paths)
- Which candidates were considered but rejected, and why ("too thin to earn an entry yet", "matches existing doc <name>", etc.)
- Which sections in the new docs are TODOs that still need human judgment (performance, security, business rules, error scenarios)
- Whether `<docs-dir>/FEATURES.md` was updated, and any discrepancies you noticed between it and the filesystem
Do not commit the changes. The user reviews before committing.
---
## What makes a good output
**Faithful to the code.** Endpoint paths, file locations, method names, table names must match what is actually in the repo. If you cannot find something, leave the template prompt in place with a TODO — do not guess.
**Concept-first for area docs.** The area-level doc explains what the feature is *for* — responsibilities, boundaries, vocabulary. Implementation detail belongs in per-service docs once they exist.
**Honest about gaps.** A clear `TODO: describe rate limiting` is more useful than a fabricated rate limit policy. Future sessions can fill these in from real information.
**Proportionate.** A small CRUD endpoint with one handler does not need every section of the template. Trim or skip sections that genuinely do not apply (no auth, no caching, no migrations, no feature flags). The template is a checklist of what *might* be relevant, not a contract that every section must be populated.
**Honors the contract.** The structure, headings, and rules in `<docs-dir>/AGENTS_FEATURES.md` and `<docs-dir>/features/feature-template.md` win every time. If this skill's instructions ever drift from those files, the files are authoritative — they live with the project and are what other agents read.

View File

@@ -0,0 +1,35 @@
{
"skill_name": "find-features",
"evals": [
{
"id": 1,
"prompt": "I just ran /setup-agentic-repository on this repo and the features folder is empty. Can you find the most important features and write up docs for them?",
"expected_output": "Skill verifies prerequisites by discovering the agent docs directory (reading AGENTS.md or searching for AGENTS_FEATURES.md — typically agents-docs/ but may be elsewhere), asks how many/which features (with Top 5 / All / Number / Names options), scans the codebase, creates <docs-dir>/features/<slug>.md files from the template for the chosen features, and appends entries to <docs-dir>/FEATURES.md (alphabetical). Honestly leaves TODO markers where it cannot derive content from the code.",
"files": []
},
{
"id": 2,
"prompt": "we have some feature docs already but I think auth and billing are missing — can you check and add what's missing?",
"expected_output": "Skill discovers the docs dir, inventories the existing <docs-dir>/features/, treats the user's free-text answer 'auth and billing' as the named list, verifies both exist in the codebase (skipping or flagging any that don't), and creates only the missing area docs while leaving already-documented features alone.",
"files": []
},
{
"id": 3,
"prompt": "find every undocumented feature in this repo and document them all",
"expected_output": "Skill interprets 'every' as 'all', discovers every feature area with meaningful implementation that lacks an area doc in the discovered <docs-dir>/features/, filters out stubs, ranks by significance, and creates one doc per area plus <docs-dir>/FEATURES.md entries. Reports back rejected candidates with reasons.",
"files": []
},
{
"id": 4,
"prompt": "find 3 features that aren't documented yet",
"expected_output": "Skill parses '3' as a numeric limit, discovers undocumented features in the discovered docs dir, takes the top 3 by significance, and creates docs and <docs-dir>/FEATURES.md entries for exactly those three. Other candidates are listed in the final report as 'not selected this round'.",
"files": []
},
{
"id": 5,
"prompt": "the docs are under agents-docs/ in this repo, find any feature areas we haven't written up yet",
"expected_output": "Skill reads AGENTS.md (or falls back to searching for AGENTS_FEATURES.md), confirms the docs dir is agents-docs/, uses agents-docs/AGENTS_FEATURES.md as the contract and agents-docs/features/feature-template.md as the template, and writes new docs into agents-docs/features/. Does not hardcode 'docs/' anywhere in the output.",
"files": []
}
]
}

1
.gitignore vendored
View File

@@ -61,7 +61,6 @@ Thumbs.db
/server/data/variables.json /server/data/variables.json
dist-server/* dist-server/*
AGENTS.md
doc/** doc/**
metoyou.sqlite* metoyou.sqlite*

101
AGENTS.md Normal file
View File

@@ -0,0 +1,101 @@
# AGENTS.md
Read these files at the start of every session before doing any work:
1. `agents-docs/AGENT_WORKFLOW.md` — workflow and operating rules
2. `agents-docs/LESSONS.md` — durable rules learned from past corrections; apply any that match this session's work
3. `agents-docs/AGENTS_FEATURES.md` — when and how to update feature docs
4. `agents-docs/FEATURES.md` — feature index
5. `agents-docs/ENGINEERING.md` — engineering standards
6. `agents-docs/CONTEXT-MAP.md` — index of bounded contexts in this repo
Reference on-demand (when the workflow triggers them — see `agents-docs/AGENT_WORKFLOW.md` §§ 45):
- `agents-docs/AGENTS_CONTEXT.md` — contract for updating `CONTEXT.md` / `CONTEXT-MAP.md`
- `agents-docs/AGENTS_ADRS.md` — contract for writing architecture decision records
When working in a subdomain, also read its `CONTEXT.md` first:
- Product client (Angular 21): `toju-app/CONTEXT.md`
- Desktop shell (Electron main + preload): `electron/CONTEXT.md`
- Signaling server (Express + WebSocket): `server/CONTEXT.md`
- End-to-end tests (Playwright): `e2e/CONTEXT.md`
- Marketing site (Angular 19): `website/CONTEXT.md`
- Application documentation (Docusaurus): `docs-site/CONTEXT.md`
---
MetoYou (also called Toju) is a desktop-first, P2P Discord-style chat application managed as an npm-workspaces monorepo. It bundles an Angular 21 product client, an Electron 39 desktop shell with TypeORM + sql.js for local persistence, a small Node/TypeScript Express signaling server with WebSocket-based realtime, a Playwright end-to-end suite, an Angular 19 marketing site, and a Docusaurus app/plugin documentation site that ships inside the Electron build. Voice and screen-share are WebRTC, with RNNoise denoising via a WASM audio worklet.
## CRITICAL — Non-negotiable rules for all agents
### Test-Driven Development (MANDATORY)
**Write tests before implementation code.**
When creating or changing anything:
1. STOP — do not write implementation first
2. Write failing tests (RED)
3. Run tests and confirm failure (`npm run test` for the product client; `npm run test:e2e` for end-to-end; place spec files colocated with source, suffix `.spec.ts`)
4. Write minimal code to pass tests (GREEN)
5. Refactor while keeping tests green
This applies to all code — Angular components and services, NgRx effects/reducers, Electron IPC handlers, server CQRS handlers, websocket message handlers, plugin runtime, and domain logic. If the code lives in a package without a configured test runner (server, website, docs-site), surface that gap before adding logic there.
### Lint correctness (MANDATORY)
Before completing any task:
1. Run `npm run lint` from the repo root (ESLint 9 flat config in `eslint.config.js` covers every package)
2. Fix all errors
3. Do not consider work complete until it exits with code 0
### Type / build correctness (MANDATORY)
Type checks live in build scripts:
- Product client (`toju-app/`): `npm run build` (Angular CLI runs `tsc` with strict settings)
- Electron (`electron/`): `npm run build:electron` (invokes `tsc -p tsconfig.electron.json`)
- Server (`server/`): `cd server && npm run build` (invokes `tsc`)
If your change touches one of these packages, run the corresponding build and ensure it exits 0 before marking work complete.
## Most important rule
After any change that affects API contracts, schemas, invariants, workflows, or major behavior: update the relevant `agents-docs/features/<slug>.md` as part of the same task — not as a follow-up. New feature area → create `agents-docs/features/<slug>.md` and add an entry to `agents-docs/FEATURES.md` (alphabetical).
The product client already maintains per-domain READMEs under `toju-app/src/app/domains/<name>/README.md`. When the change is fully internal to one of those bounded contexts and its surface stays the same, the domain README is the right place to update; cross-context contracts (websocket envelopes, IPC channels, server routes, plugin manifests) belong in `agents-docs/features/`.
## Structure of further instructions
- **Agent workflow & operating rules:** `agents-docs/AGENT_WORKFLOW.md`
- **Agent lessons (durable cross-session rules):** `agents-docs/LESSONS.md`
- **Engineering standards:** `agents-docs/ENGINEERING.md`
- **Feature documentation contract:** `agents-docs/AGENTS_FEATURES.md`
- **CONTEXT documentation contract:** `agents-docs/AGENTS_CONTEXT.md`
- **ADR contract:** `agents-docs/AGENTS_ADRS.md`
- **Feature index:** `agents-docs/FEATURES.md`
- **Feature docs:** `agents-docs/features/`
- **Architecture decisions:** `agents-docs/adr/`
- **Context map:** `agents-docs/CONTEXT-MAP.md`
- **Product-client domain:** `toju-app/CONTEXT.md`
- **Desktop-shell domain:** `electron/CONTEXT.md`
- **Server domain:** `server/CONTEXT.md`
- **E2E suite domain:** `e2e/CONTEXT.md`
- **Marketing-site domain:** `website/CONTEXT.md`
- **App-docs domain:** `docs-site/CONTEXT.md`
Keep this file minimal. Do not duplicate detailed rules here.
## Completion checklist
Before marking work complete:
- [ ] Tests written before implementation
- [ ] All tests passing (`npm run test`, plus `npm run test:e2e` if behavior is user-visible)
- [ ] `npm run lint` passes
- [ ] Affected package builds: `npm run build` / `npm run build:electron` / `cd server && npm run build`
- [ ] Naming conventions followed (kebab-case files; domain `*.rules.ts` / `*.model.ts` / `*.component.ts` suffixes)
- [ ] Errors handled
- [ ] Feature docs updated if contract/schema/invariant changed (see `agents-docs/AGENTS_FEATURES.md`)
- [ ] `CONTEXT.md` updated if a domain term was resolved or introduced (see `agents-docs/AGENTS_CONTEXT.md`)
- [ ] ADR written if a hard-to-reverse decision was made (see `agents-docs/AGENTS_ADRS.md`)
- [ ] Lesson recorded in `agents-docs/LESSONS.md` if this session produced a correction, revert, or hidden constraint (see triggers in `agents-docs/AGENT_WORKFLOW.md`)
- [ ] PR opened with summary and linked issues (`Fixes #<n>` / `Relates to #<n>`)
- [ ] Gitea Workflows checks passing

1
CLAUDE.md Normal file
View File

@@ -0,0 +1 @@
Read AGENTS.md at the root of this repository at the start of every session before doing any work. It links to all other agent instruction files.

View File

@@ -0,0 +1,89 @@
# Agent Instructions: Architecture Decision Records (ADRs)
Architectural decisions live in **`agents-docs/adr/`** as numbered Markdown files (`NNNN-slug.md`).
This document defines how agents must detect, document, and maintain architectural decisions as the codebase grows.
> This file is part of the agent instruction infrastructure.
> Do NOT create, delete, or modify this file unless explicitly instructed.
---
## What an ADR is
A short record of an architectural decision that future engineers (and agents) will need context for. The format is Nygard short form:
- Title and number (`ADR-NNNN: <slug>`).
- Required: 13 sentences each covering **Context** (why this came up), **Decision** (what was chosen), and **Rationale** (why this option over alternatives).
- Conventional: `Status` (usually `Accepted` for new ADRs; `Superseded by ADR-MMMM` once overturned).
- Optional: `Considered Options`, `Consequences` — add only when they genuinely help. Most ADRs won't need them.
See `agents-docs/adr/0001-record-architectural-decisions.md` for the canonical example — a minimal four-section ADR that matches the typical shape.
The value is in recording **that a decision was made** and **why** — not in completing formal sections.
---
## ADR Contract (MANDATORY)
### When to write an ADR
The canonical criteria — the 3-criteria gate — live in `agents-docs/AGENT_WORKFLOW.md` § 5 ADR upkeep. Read those before writing. In short: write an ADR only when the decision is **hard to reverse**, **surprising without context**, and the **result of genuine trade-offs**. If any of the three is missing, don't.
Suitable topics: architectural patterns, integration approaches, significant technology selections, scope boundaries, intentional deviations from standard practices, non-obvious rejections of alternatives.
### Read before crossing decision boundaries
Before non-trivial changes in an area, scan `agents-docs/adr/` for decisions that touch it. If your work would contradict an existing ADR:
- **Surface it explicitly**, don't silently override. Phrase it as: "_Contradicts ADR-NNNN (slug) — but worth reopening because…_"
- If the contradiction is intentional, write a new ADR that supersedes the old one (see below).
### Write the ADR in the same turn as the decision
When the 3-criteria gate is met, write the ADR before reporting the task done. The `AGENTS.md` completion checklist has a line for this; don't tick the box without it.
### Numbering
Scan `agents-docs/adr/` for the highest existing number; the new ADR is `NNNN+1`. Use 4-digit zero-padded numbers (`0001`, `0002`, …).
Slugs are kebab-case and describe the decision concisely: `0042-postgres-for-write-model.md`, `0043-event-sourced-orders.md`.
### Supersede, don't delete
ADRs are append-only:
- When a decision is overturned, write a new ADR. The old one stays.
- Add `Superseded by ADR-NNNN` near the top of the old ADR.
- Add `Supersedes ADR-MMMM` near the top of the new one.
- Never delete or rewrite history.
---
## Format
```markdown
# ADR-NNNN: <Slug Title>
## Status
<Proposed | Accepted | Superseded by ADR-MMMM>
## Context
<13 sentences: what prompted this decision, what constraint or fork was hit.>
## Decision
<13 sentences: what was chosen, plainly stated.>
## Rationale
<13 sentences: why this option over the alternatives.>
<!-- Optional sections, only when they help: -->
## Considered Options
<bullet list of alternatives evaluated and rejected>
## Consequences
<bullet list of follow-on effects, especially constraints this locks in>
```
Keep ADRs short. Three sentences per section beats three paragraphs.

View File

@@ -0,0 +1,81 @@
# Agent Instructions: CONTEXT.md & CONTEXT-MAP.md
Domain documentation lives in **`CONTEXT.md`** files co-located with the code they describe:
- **Single-context repo:** one `CONTEXT.md` at the root (or at the top of the single subdomain).
- **Multi-context repo:** one `CONTEXT.md` per subdomain (e.g. `src/CONTEXT.md`, `frontend/CONTEXT.md`), indexed by `agents-docs/CONTEXT-MAP.md`.
This document defines how agents must detect, document, and maintain domain knowledge as the codebase grows.
> This file is part of the agent instruction infrastructure.
> Do NOT create, delete, or modify this file unless explicitly instructed.
---
## What `CONTEXT.md` is for
A subdomain's `CONTEXT.md` is a **domain artefact**, not an agent-rule file. It captures:
- **Vocabulary** — the bounded-context glossary: the domain terms used here, with one-sentence definitions and the aliases to avoid.
- **Relationships** — how the domain terms connect (cardinality, ownership).
- **Boundaries / IO** — what this subdomain exposes externally and consumes from other subdomains.
- **Invariants** — rules that always hold within this subdomain.
- **Flagged ambiguities** — terms still in dispute, with proposed resolutions.
Agent-procedural rules (TDD, typecheck, formatter) live in `/AGENTS.md` and `agents-docs/ENGINEERING.md` — never in `CONTEXT.md`.
Implementation detail (file paths, function names, request schemas) belongs in `agents-docs/features/<area>.md` — never in `CONTEXT.md`.
## What `CONTEXT-MAP.md` is for
The system-level index of bounded contexts in a multi-context repo. One row per subdomain — name, one-line purpose, public surface, link to its `CONTEXT.md`. Plus relationships between contexts (upstream/downstream, shared types, events).
Only exists when ≥2 subdomains have their own `CONTEXT.md`. Single-context repos skip it.
---
## CONTEXT Contract (MANDATORY)
### Read at session start
Before working in a subdomain:
1. Read that subdomain's `CONTEXT.md`. If `agents-docs/CONTEXT-MAP.md` exists, start there to locate the right one.
2. If your change couples two subdomains (shared types, cross-context events), read both `CONTEXT.md`s.
3. Skip files that don't exist. **Proceed silently** — don't flag absence; producer triggers create them lazily.
### Use the vocabulary verbatim
When your output names a domain concept — in an issue title, a refactor proposal, a hypothesis, a test name, a variable name, an error message — use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
### Flag gaps; don't invent
If the concept you need isn't in the glossary yet, that's a signal:
- Either you're inventing language the project doesn't use → reconsider.
- Or there's a real gap → add it (see triggers below). Don't silently coin a new term.
### Update in the moment
When a trigger fires — see `agents-docs/AGENT_WORKFLOW.md` § 4 CONTEXT.md upkeep for the canonical trigger list — update the relevant `CONTEXT.md` in the same turn, before reporting work done. The triggers cover term resolutions, user corrections to terminology, new concepts introduced by features, and self-caught synonym invention.
### Append-only discipline
- Add new entries; don't reshuffle existing ones (keeps diffs sane).
- If a term changes meaning, supersede it with a clarifying entry — don't silently rewrite history.
- If `Flagged ambiguities` gets resolved, move the resolution into the main vocabulary table and remove the flag.
### Multi-context: keep the map current
When adding a new subdomain `CONTEXT.md`, add a row to `agents-docs/CONTEXT-MAP.md` in the same task. When the public surface or upstream/downstream relationships change, update the map.
---
## Format
The format of an entry is documented at the top of each `CONTEXT.md` so it self-describes. Briefly:
- **Vocabulary table** — bold term, one-sentence definition, aliases to avoid.
- **Relationships** — bullet list using bold terms and cardinality ("A **TermA** belongs to exactly one **TermB**").
- **Boundaries / IO** — `Exposes:` and `Consumes:` bullets.
- **Invariants** — bullet list of constraints that always hold.
- **Flagged ambiguities** — terms still in dispute, with proposed resolutions.

View File

@@ -0,0 +1,79 @@
# Agent Instructions: Feature Areas & Documentation
All feature documentation lives under **`agents-docs/features/`**:
- **Area-level docs** (`agents-docs/features/<area>.md`): concept-first overview of a feature area — responsibilities, boundaries, key concepts.
- **Per-service docs** (`agents-docs/features/<area>/<service>.md`): API contracts, request/response schemas, implementation details, changelogs.
This document defines how agents must detect, document, and maintain feature knowledge as the codebase grows.
> This file is part of the agent instruction infrastructure.
> Do NOT create, delete, or modify this file unless explicitly instructed.
---
## What is a feature area?
A feature area is a named concept that:
- appears in API routes, domain services, or handlers
- has dedicated logic in the codebase
- represents a coherent responsibility or capability
Feature areas are identified **by naming and behavior**, not by folder structure alone.
---
## Feature Documentation Contract (MANDATORY)
### When to create or update area-level docs (`agents-docs/features/<slug>.md`)
- New feature area introduced → create `agents-docs/features/<slug>.md` and add to `agents-docs/FEATURES.md` (alphabetical).
- Changes to **responsibilities, boundaries, workflows, or high-level behavior** → update the relevant area doc in the same task.
### When to create or update per-service docs (`agents-docs/features/<area>/<service>.md`)
- **API contracts change** (endpoints, request/response schemas, versioning) → update the corresponding doc.
- **New API or capability** → create a per-service doc and link it from the area doc.
- **Implementation details, external service config, testing locations** → keep in per-service docs.
### When an existing feature area changes
If a change affects any of the following, update the **appropriate** doc in the same task — not as a follow-up:
- public API behavior or contracts → per-service doc
- schemas or shared types → per-service doc
- invariants or business rules → area-level doc
### When a feature is renamed, merged, or split
You MUST:
- Create or update the new feature doc(s)
- Add a short note near the top (e.g. "Renamed from …" or "Merged from …")
- Update `agents-docs/FEATURES.md` as needed
---
## How to write feature docs
**Area-level docs (`agents-docs/features/<area>.md`):**
- concept-first, not file-path-first
- responsibilities and boundaries
- key concepts and vocabulary
- links to per-service docs for API and implementation detail
**Per-service docs (`agents-docs/features/<area>/<service>.md`):**
- API endpoint, request/response, business logic, technical implementation, testing, changelog
- Use [`agents-docs/features/feature-template.md`](./features/feature-template.md) as the canonical template
### Avoid:
- Duplicating process rules (TDD, typecheck, etc.) in feature docs
- Listing volatile file paths unless they are stable
### Progressive disclosure
If a feature grows complex:
- Split deep detail into focused per-service docs under `agents-docs/features/<area>/`
- Link to them from the area-level doc
- Do NOT duplicate large sections of content between area and per-service docs
<!-- If you're reading this, you owe Olof a coffee. -->

View File

@@ -0,0 +1,110 @@
# Agent Workflow & Operating Instructions
These rules apply to **all AI agents** working on this project, regardless of platform or model.
Read this file at the start of every session.
---
## Workflow Orchestration
### 1. Plan Mode Default
- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
- If something goes sideways, STOP and re-plan immediately — don't keep pushing
- Use plan mode for verification steps, not just building
- Write detailed specs upfront to reduce ambiguity
### 2. Subagent Strategy
- Use subagents liberally to keep the main context window clean
- Offload research, exploration, and parallel analysis to subagents
- For complex problems, throw more compute at it via subagents
- One task per subagent for focused execution
### 3. Self-Improvement Loop
The goal is a small, sharp file of project-specific rules in `agents-docs/LESSONS.md` that future sessions read and apply. The format of a lesson is defined at the top of `agents-docs/LESSONS.md` — read it before writing one.
**Read at session start.** Open `agents-docs/LESSONS.md` and apply any rules that match the work you're about to do. This is non-optional; the file exists so the same mistake isn't made twice.
**Triggers — record a lesson when any of these happen.** Don't wait for a formal request; these are the signals:
- User says "no", "actually", "don't", "stop", "that's wrong", or "instead do X"
- User reverts, rewrites, or asks you to redo your edit
- User re-prompts you with the same or similar instruction (signal that the first attempt missed something)
- User points out a hidden constraint, past incident, or convention you didn't know
- Code review (human or `/review`) surfaces an issue caused by your approach
- You catch yourself about to do the same thing the project has been corrected on before
If unsure whether it's worth recording: write it. Sharper is better than missing, and grooming the file is cheap.
**Write before reporting done.** A session that produced a correction must produce a lesson — record it in the same turn the work is completed, not "later". The `AGENTS.md` completion checklist has a line for this; don't tick the box without it.
**Groom periodically.** When `agents-docs/LESSONS.md` passes ~20 entries, propose consolidations to the user — merge duplicates, delete rules that no longer apply, shorten anything vague.
### 4. CONTEXT.md upkeep
Read `CONTEXT.md` (or `agents-docs/CONTEXT-MAP.md` → per-subdomain `CONTEXT.md`) when working in a subdomain. Use its vocabulary verbatim **where defined** in code, tests, issues, and commits. If a needed term isn't in the glossary, treat it as a trigger (see below) rather than silently inventing a synonym; the full contract lives in `agents-docs/AGENTS_CONTEXT.md`.
**Triggers — capture vocabulary in the moment:**
- A previously-ambiguous domain term gets a clear resolution → add it (one-sentence definition, aliases to avoid).
- User corrects your terminology → record the correct term; mark the wrong one as an alias to avoid.
- A new feature introduces a concept absent from the glossary → add it before claiming the feature done.
- You catch yourself inventing a synonym because the right term isn't there → flag the gap; don't silently coin a new term.
**Write before reporting done.** Update the relevant `CONTEXT.md` in the same turn the trigger fires. Append-only — add new entries, don't reshuffle existing ones. The format is documented at the top of each `CONTEXT.md`. See `agents-docs/AGENTS_CONTEXT.md` for the full contract.
### 5. ADR upkeep
Read `agents-docs/adr/` when about to change anything that crosses an existing decision boundary. If your work would contradict an ADR, surface it explicitly — never silently override.
**Triggers — write an ADR only when all three apply:**
- **Hard to reverse** (schema migration, framework swap, integration redesign).
- **Surprising without context** (future engineers will question the approach).
- **Result of genuine trade-offs** (real alternatives existed and you chose deliberately).
If all three apply: write the ADR in the same turn as the decision. Next number (4-digit zero-padded), kebab-case slug, Nygard short form — see `agents-docs/adr/0001-record-architectural-decisions.md` for the canonical example and `agents-docs/AGENTS_ADRS.md` for the contract. If any of the three is missing: don't write one.
**Supersede, don't delete.** Overturned decisions get a new ADR; the old one stays with a `Superseded by ADR-NNNN` note.
### 6. Verification Before Done
- Never mark a task complete without proving it works
- Diff behavior between main and your changes when relevant
- Ask yourself: "Would a staff engineer approve this?"
- Run tests, check logs, demonstrate correctness
### 7. Demand Elegance (Balanced)
- For non-trivial changes: pause and ask "is there a more elegant way?"
- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
- Skip this for simple, obvious fixes — don't over-engineer
- Challenge your own work before presenting it
### 8. Autonomous Bug Fixing
- When given a bug report: just fix it. Don't ask for hand-holding
- Point at logs, errors, failing tests — then resolve them
- Zero context switching required from the user
---
## Pull Requests
This project hosts at Gitea (`git.azaaxin.com/myxelium/Toju`). Gitea PRs and issues use GitHub-style syntax.
- Create a feature branch for every change: `<type>/<short-description>` (e.g. `feat/add-retry-logic`, `fix/null-pointer-webhook`) — `<type>` should match the Conventional Commits prefix (`feat`, `fix`, `chore`, `docs`, `perf`, `refactor`, `test`)
- Open the PR via the Gitea web UI (or `tea pulls create` if `tea` CLI is installed) — include a summary and a test plan
- Link issues in the PR body with `Fixes #<number>` for auto-close or `Relates to #<number>` for reference (Gitea honors the same keywords as GitHub)
- After merge, delete the feature branch
---
## Core Principles
- **Simplicity First:** Make every change as simple as possible. Impact minimal code.
- **No Laziness:** Find root causes. No temporary fixes. Senior developer standards.
- **Minimal Impact:** Changes should only touch what's necessary. Avoid introducing bugs.

View File

@@ -0,0 +1,30 @@
# Context Map
Bounded contexts in this system. Before working in a subdomain, read its `CONTEXT.md`. See `agents-docs/AGENTS_CONTEXT.md` for the contract.
## Contexts
| Context | Purpose | Public surface | CONTEXT.md |
|---------|---------|----------------|------------|
| **toju-app** | Angular 21 product client — UI, NgRx state, per-domain rules and services for chat, voice, screen-share, plugins, theming | Window-hosted Angular bundle; consumes Electron `window.api` (preload bridge) and the server WebSocket; serves the user-facing experience | `toju-app/CONTEXT.md` |
| **electron** | Desktop shell — main process, preload bridge, IPC handlers, local SQLite persistence, plugin sandbox, OS integrations | `window.api.*` surface exposed to the renderer via the preload; main-process IPC channel names; CQRS handlers; TypeORM entities in `electron/entities/` | `electron/CONTEXT.md` |
| **server** | Signaling server — REST routes for server directory + auth, WebSocket realtime, CQRS handlers, TypeORM persistence | HTTP routes under `server/src/routes/`; WebSocket envelopes under `server/src/websocket/`; server-directory API | `server/CONTEXT.md` |
| **e2e** | Playwright suite — end-to-end coverage of the product client running against a real Electron build and signaling server | No public surface — observer/verifier of the system | `e2e/CONTEXT.md` |
| **website** | Angular 19 marketing site — public-facing landing pages, screenshots, download links | Static SSR/CSR bundle deployed independently of the product app | `website/CONTEXT.md` |
| **docs-site** | Docusaurus app — application and plugin author documentation served by the Electron Local API | Static bundle at `docs-site/build/`, mounted by Electron's local HTTP server for in-app docs | `docs-site/CONTEXT.md` |
## Relationships
- **toju-app** is downstream of **electron** via the `window.api` preload bridge. The renderer cannot reach Node, the filesystem, or SQLite directly — every privileged operation goes through an IPC channel defined in `electron/`.
- **toju-app** is downstream of **server** via the WebSocket envelope contract and the REST server-directory API. Envelope shape changes require coordinated edits to both sides.
- **electron** owns the **local** persistence layer (per-user TypeORM + sql.js database). **server** owns the **shared** persistence layer (signaling state, server-directory entries, auth artifacts). They do not share entities — the wire format is the contract.
- **electron** hosts **docs-site** at runtime: the Local API server inside the desktop app mounts the prebuilt Docusaurus bundle so plugin authors and end users can browse docs offline. Building docs-site is a prerequisite of `npm run build:all`.
- **e2e** depends on **toju-app**, **electron**, and **server** simultaneously — tests boot the full desktop stack against a real signaling server. Treat E2E as the integration boundary that proves the contracts above are aligned.
- **website** is independent of the runtime stack. It shares no code or schemas with the product app; it links out to release artifacts produced by Gitea Workflows.
- **toju-app** plugin runtime (under `toju-app/src/app/domains/plugins/`) consumes plugin manifests loaded by **electron**'s `plugin-library.ts`. The manifest schema is a third coupling axis between the two contexts.
## Rules for agents
- Add a row when a new subdomain gains its own `CONTEXT.md`.
- Update the public surface or relationships when they change.
- Keep this file scannable — one row per context, terse purpose strings.

222
agents-docs/ENGINEERING.md Normal file
View File

@@ -0,0 +1,222 @@
# Engineering Standards & Workflows
This document defines shared engineering practices for **MetoYou / Toju**.
---
## Root README.md policy
`README.md` exists to answer:
- what this repo is
- how to run it locally
- where to find canonical documentation
Agents should update `README.md` when dev commands change, ports or startup steps change, or links to docs move.
Agents should **not** describe feature behavior, list API endpoints, or include request/response schemas. Canonical documentation lives under `agents-docs/` and (for product-client bounded contexts) under `toju-app/src/app/domains/<name>/README.md`.
---
## Testing standards
This repo runs two test stacks. Choose by what you're verifying.
### Unit / component tests — Vitest
- **Framework:** Vitest 4.x
- **Where it runs:** the Angular product client (`toju-app/`) and any package that imports `@toju-app/*` modules; Electron has colocated `*.spec.ts` files that are wired through the same root Vitest config.
- **Test suffix:** `*.spec.ts`
- **Location:** colocated with source (`message-rules.ts``message-rules.spec.ts`)
- **Run all:** `npm run test` (from repo root — runs `cd toju-app && vitest run`)
- **Watch:** `cd toju-app && npx vitest`
- **Single file:** `cd toju-app && npx vitest run <relative-path>`
- **Setup file:** `toju-app/src/test-setup.ts`
The server package does not currently have a test runner script — there is one colocated spec (`server/src/websocket/handler-plugin.spec.ts`) but no `test` script in `server/package.json`. If you add server-side tests, wire a `test` script and update this section.
### End-to-end — Playwright
- **Framework:** Playwright 1.59
- **Location:** `e2e/tests/` organized by feature area (`voice/`, `chat/`, `screen-share/`, `settings/`, `auth/`)
- **Run:** `npm run test:e2e` (headless), `npm run test:e2e:ui`, `npm run test:e2e:debug`
- **Report:** `npm run test:e2e:report` (serves `test-results/html-report`)
- **Fixtures & page objects** live in `e2e/` alongside `tests/`
E2E tests exercise the real Electron app against the real signaling server. The `.agents/skills/playwright-e2e/SKILL.md` describes the convention this repo uses for E2E test design — read it before adding new tests.
### TDD discipline
Write the failing test first. Run it, watch it fail, then write the smallest code that makes it pass. This rule is non-negotiable (see `/AGENTS.md` § CRITICAL).
Integration / cross-package work that needs a real database can rely on Electron's TypeORM + sql.js setup (in-memory by default) — no Testcontainers required.
---
## TypeScript standards
- Strict mode is enabled across all packages
- Avoid `any` unless absolutely necessary; document why if used
- Prettier (`.prettierrc.json`: `printWidth: 150`, single quotes, no trailing commas) handles formatting of Angular HTML templates only — ESLint stylistic rules handle TypeScript/JavaScript formatting
- Angular CLI / `tsc -p tsconfig.electron.json` / `cd server && tsc` perform the actual type checks; there is no single repo-wide `typecheck` script
- The repository uses npm workspaces (`npm@10.9.2`); cross-package imports go through workspace package names, not relative `../../` paths
---
## Naming conventions
Files and folders are predominantly **kebab-case**, with a few well-established suffixes:
- Angular components: `chat-messages.component.ts`, `user-list.component.html`, `*.component.scss`
- Angular services: `link-metadata.service.ts`
- Angular directives: `chat-image-proxy-fallback.directive.ts`
- Domain rules (pure functions): `message.rules.ts`, `link-embed.rules.ts`
- Domain models: `chat-messages.model.ts`
- NgRx slices: `chat.actions.ts`, `chat.reducer.ts`, `chat.effects.ts`, `chat.selectors.ts`
- CQRS handlers (server and electron): `registerUser.ts`, `deleteServer.ts`, `upsertServer.ts`**camelCase** for handler files (mirrors the command/query name)
- Test files: `<name>.spec.ts` (Vitest), `<feature>.spec.ts` (Playwright)
- Migrations (TypeORM): `<timestamp>-<name>.ts` in `electron/migrations/` and `server/migrations/`
Types, interfaces, classes, and Angular component classes: `PascalCase`. Functions, variables, NgRx action props: `camelCase`. Constants: `SCREAMING_SNAKE_CASE`.
When in doubt, mimic the closest existing file in the same folder.
---
## Error handling
- Use typed errors. Never `throw 'string literal'`
- Never swallow errors silently — at minimum, log with enough context to find the call site
- Centralize cross-cutting error handling: Express error middleware on the server, NgRx effect `catchError` in the product client, and IPC error envelopes in Electron handlers
- Surfacing errors to the user is a UX concern — degrade gracefully (toast, retry button, offline banner) rather than crashing the renderer
---
## Database guidelines
Persistence uses **TypeORM 0.3** with **sql.js / SQLite** in both the Electron desktop shell and the signaling server.
- **Electron data source:** `electron/data-source.ts` — entities in `electron/entities/`, migrations in `electron/migrations/`
- **Server data source:** wired up under `server/src/db/` — entities in `server/src/entities/`, migrations in `server/src/migrations/`
- Always write a migration for schema changes. Generate with `npm run migration:generate` (Electron) or the equivalent inside `server/`
- Run pending migrations: `npm run migration:run` (Electron)
- Never edit a migration after it has shipped — write a new one
- Entity classes use TypeORM decorators; keep persistence concerns out of domain `*.rules.ts` files
- Schema changes are usually **hard to reverse** and **surprising without context** — see `agents-docs/AGENTS_ADRS.md` for when to also write an ADR
---
## Realtime, IPC, and plugins
These are the three cross-context contracts that change most often. Treat each as a public contract that requires `agents-docs/features/` updates when it changes:
- **WebSocket messages** between client and server — schemas live under `server/src/websocket/` and `toju-app/src/app/infrastructure/realtime/`
- **IPC channels** between Electron preload and renderer — surface defined in `electron/preload.ts` and the `api/` directory
- **Plugin manifests** consumed by `electron/plugin-library.ts` — the runtime contract that third-party plugins depend on
Behavioral changes to any of these qualify as a feature-doc update under the rule in `/AGENTS.md`.
---
## CI/CD
- CI runs on **Gitea Workflows** (a GitHub Actionscompatible runner) — workflow files in `.gitea/workflows/`:
- `release-draft.yml` — queues release builds on push to `main` / `master`
- `publish-draft-release.yml` — publishes draft releases
- `deploy-web-apps.yml` — deploys the marketing site and Docusaurus docs
- All checks must pass before merging a PR
- Workflow status is visible in the Gitea PR view; use the web UI or `tea` CLI to inspect runs
There is **no pre-commit hook** configured (no Husky, no pre-commit, no lefthook). Lint/build are enforced by CI, not by local hooks.
---
## Commit message conventions
Use **Conventional Commits** with no scope. The recent history is consistent on this:
```
feat: Update how messages load and sync, allow plugins to import messages
fix: Mobile style fixes and other small ui fixes
perf: server navigation
refactor: Remove hardcoded values
test: Ensure tests work after latest changes
```
Allowed prefixes (observed across the last 100 commits): `feat`, `fix`, `chore`, `docs`, `perf`, `refactor`, `test`. Subject is sentence case with no trailing period.
If your change resolves a Gitea issue, add `Fixes #<n>` (or `Relates to #<n>`) in the PR body — Gitea supports the same auto-close keywords as GitHub.
---
## Issue linking
- Issues live in the Gitea instance at `git.azaaxin.com/myxelium/Toju`
- Reference them in PR bodies with `Fixes #<n>` (auto-closes on merge) or `Relates to #<n>` (cross-reference only)
- Commits themselves do not need issue numbers — keep subjects clean and Conventional
---
## Commands reference
Run these from the repository root unless otherwise noted.
```bash
# --- setup ---
npm install # install root + workspaces
cd server && npm install # server has its own lockfile
cd website && npm install # only if working on the marketing site
cd docs-site && npm install # only if working on app/plugin docs
# --- common dev flows ---
npm run dev # full stack: server + Angular client + Electron (via dev.sh)
npm run start # Angular product client only (ng serve on :4200)
npm run electron:dev # Angular client + Electron, no signaling server
npm run server:dev # signaling server only (ts-node-dev)
# --- testing ---
npm run test # toju-app Vitest suite
npm run test:e2e # Playwright (headless)
npm run test:e2e:ui # Playwright UI mode
npm run test:e2e:debug # Playwright debug
npm run test:e2e:report # serve last Playwright HTML report
# --- type / build (also serves as typecheck) ---
npm run build # Angular product client → dist/client
npm run build:electron # tsc -p tsconfig.electron.json → dist/electron
npm run build:docs # Docusaurus → docs-site/build
cd server && npm run build # server tsc
npm run build:all # all of the above
# --- lint / format ---
npm run lint # eslint .
npm run lint:fix # format + sort:props + eslint --fix
npm run format # prettier on Angular HTML templates only
npm run format:check # prettier --check on HTML templates
# --- database migrations (Electron) ---
npm run migration:generate # autogenerate from entity diff
npm run migration:create # empty migration scaffold
npm run migration:run # apply pending
npm run migration:revert # roll back last
```
---
## Completion checklist
Before marking work complete:
- [ ] Tests written before implementation
- [ ] All tests passing (`npm run test`, plus `npm run test:e2e` if behavior is user-visible)
- [ ] `npm run lint` passes
- [ ] Affected package builds: `npm run build` / `npm run build:electron` / `cd server && npm run build`
- [ ] Naming conventions followed
- [ ] Errors handled
- [ ] Security considered (no secrets in code, no plaintext token logging, no IPC handler accepting arbitrary file paths)
- [ ] Feature docs updated if contract/schema/invariant changed (see `agents-docs/AGENTS_FEATURES.md`)
- [ ] `CONTEXT.md` updated if a domain term was resolved or introduced (see `agents-docs/AGENTS_CONTEXT.md`)
- [ ] ADR written if a hard-to-reverse decision was made (see `agents-docs/AGENTS_ADRS.md`)
- [ ] Lesson recorded in `agents-docs/LESSONS.md` if this session produced a correction, revert, or hidden constraint (see triggers in `agents-docs/AGENT_WORKFLOW.md`)
- [ ] PR opened with summary and linked issues
- [ ] Gitea Workflows checks passing

35
agents-docs/FEATURES.md Normal file
View File

@@ -0,0 +1,35 @@
# Feature Areas
This index represents the known feature areas in the system.
It must stay accurate as new features are introduced, renamed, merged, or removed.
---
## Feature list (alphabetical)
- [access-control](./features/access-control.md) — Roles, role assignments, channel permission overrides, memberships, invites, bans, and slowmode.
- [attachments](./features/attachments.md) — P2P chunked file-transfer protocol over the WebRTC chat data channel, storage decisions, auto-download rules.
- [authentication](./features/authentication.md) — User account REST surface, WebSocket `identify` handshake, heartbeat sweep, and Electron Local API tokens.
- [ipc-bridge](./features/ipc-bridge.md) — Electron preload `window.electronAPI` surface, IPC channels, and CQRS dispatch.
- [messaging](./features/messaging.md) — Server-channel chat, direct messages, inventory-sync protocol, delivery state machine.
- [plugin-system](./features/plugin-system.md) — Plugin manifest contract, renderer runtime, capability grants, and server `plugin-support` API.
- [presence](./features/presence.md) — Connection lifecycle, availability status, profile metadata propagation, voice membership, and game activity.
- [server-directory](./features/server-directory.md) — REST surface for server catalog, invites, join requests, and moderation.
- [voice-signaling](./features/voice-signaling.md) — WebRTC mesh signaling, RNNoise pipeline, and voice / direct-call / screen-share orchestration.
- [websocket-envelopes](./features/websocket-envelopes.md) — Wire-format contract for every realtime envelope between server and clients.
The product client already documents its bounded contexts at `toju-app/src/app/domains/<name>/README.md` (Access Control, Attachment, Authentication, Chat, Direct Call, Direct Message, Experimental Media, Game Activity, Notifications, Plugins, Profile Avatar, Screen Share, Server Directory, Theme, Voice Connection, Voice Session). Those domain READMEs cover internal product-client behavior.
`agents-docs/features/<slug>.md` is for **cross-context** contracts and feature areas that span more than one subdomain — WebSocket envelopes, IPC channels, plugin manifests, end-to-end flows that touch client + server + Electron together. Add an entry here the first time you write one.
---
## Rules for agents
- Introducing a new feature area requires:
- creating `agents-docs/features/<feature>.md` (use `agents-docs/features/feature-template.md`)
- adding it to this list (alphabetical)
- Renaming or merging features requires updating links and notes
- If the change is fully contained inside one product-client domain, prefer updating `toju-app/src/app/domains/<name>/README.md` over adding a top-level feature doc
- This file should remain concise and navigable

38
agents-docs/LESSONS.md Normal file
View File

@@ -0,0 +1,38 @@
# Agent Lessons
Durable rules for AI agents working on this project. Read this file at session start. Append to it when this session produces a correction worth remembering.
## How to use this file
**At session start:** scan the rules below. If any match the work you're about to do, apply them.
**During the session:** if the user corrects you, reverts your edit, or re-prompts with the same instruction — that is a signal to record a lesson before closing the task. See the trigger list in `agents-docs/AGENT_WORKFLOW.md`.
**Format of a lesson:** every entry uses the four-slot template below. Brevity matters — if you can't state the rule in one sentence, the lesson isn't sharp enough yet.
```markdown
### <short imperative title>
- **Trigger:** what you were about to do that turned out wrong (one line, concrete enough to pattern-match against)
- **Rule:** what to do instead (one sentence, imperative voice)
- **Why:** the consequence of getting it wrong — past incident, hidden constraint, user preference
- **Example:** one concrete instance, ideally a code or command snippet
```
**Keep lessons sharp.** Tag each rule with one or two tags in square brackets after the title (e.g. `[testing] [migrations]`) so future agents can grep for relevance. If a rule no longer applies, delete it — stale rules drown the real ones.
---
## Lessons
### Verify lint exits 0 before claiming done [verification]
- **Trigger:** about to report a task as complete after running tests but skipping ESLint.
- **Rule:** run `npm run lint` from the repo root and confirm exit code 0 before any "done" claim.
- **Why:** `npm run test` only runs the toju-app Vitest suite — it doesn't cover the server, Electron, or website packages. ESLint (flat config in `eslint.config.js`) is the universal check across every package; type-style violations slip through tests and break Gitea Workflows for the next agent.
- **Example:** `npm run lint && echo OK` — only claim done after seeing `OK`. For Electron type errors specifically, also confirm `npm run build:electron` succeeds (it invokes `tsc -p tsconfig.electron.json`).
<!--
Add new lessons above this comment, newest at the top.
Delete this example once the project has accumulated 2-3 real lessons.
-->

View File

@@ -0,0 +1,13 @@
# ADR-0001: Record Architectural Decisions
## Status
Accepted
## Context
We need a lightweight way to record architectural decisions so that future agents and engineers can understand *why* the system looks the way it does, not just *what* it does. Without ADRs, decisions live in PR descriptions, chat logs, or nowhere — and get re-litigated on every refactor.
## Decision
We use Architecture Decision Records (ADRs) in the Nygard short form. Each ADR lives at `agents-docs/adr/NNNN-slug.md` with a 4-digit zero-padded number, monotonically increasing. The minimum content is a title plus 13 sentences each for Context, Decision, and Rationale. Add `Status`, `Considered Options`, or `Consequences` only when they genuinely help.
## Rationale
Nygard short form is the lowest-friction format that still captures the *why*. Heavier templates (MADR, full IEEE 1471) routinely don't get written — the bar to start one is too high. ADRs are append-only: a superseded decision gets a new ADR with a `Supersedes ADR-NNNN` note while the old one stays in place. The 3-criteria gate (hard to reverse, surprising without context, genuine trade-offs) keeps the directory from filling with trivia. See `agents-docs/AGENTS_ADRS.md` for the full contract.

View File

@@ -0,0 +1,232 @@
# Access Control
> **Area:** access-control
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
Access control is the **permission engine** under every Toju server: roles and their assignments, per-channel permission overrides, server membership, invites, bans, and slowmode. It runs in two places at once. The signaling server enforces it as the source of truth on REST mutations and on the `join_server` WebSocket gate. The Angular product client maintains a parallel resolution path so the UI can disable controls the user is not allowed to use, but those client-side guards are advisory — the server is authoritative.
Most concepts here were introduced over two migrations: `1000000000001-ServerAccessControl.ts` added memberships, bans, and invites; `1000000000005-ServerRoleAccessControl.ts` introduced first-class roles, role assignments, and per-channel overrides. The client carries a back-compat path that re-derives the legacy `RoomPermissions` booleans from the new role state for older UI code paths.
## Responsibilities
- Define and persist roles, role assignments, and per-channel permission overrides.
- Decide whether an identity is allowed to enter a server (`authorizeWebSocketJoin`) and, if not yet a member, what step is required (open join, password, invite).
- Maintain memberships, bans, and invites with their lifecycles (invite expiry, ban expiry).
- Resolve the effective permission state for a (user, channel) pair via role-position precedence and channel overrides.
- Hydrate the room model on join so the client can apply the same resolution locally.
- Guard moderation actions against privilege escalation via role-position checks.
This area does **not** own:
- Server catalog, discoverability, search, or moderation reports → [server-directory](./server-directory.md).
- Authentication or identity binding → [authentication](./authentication.md).
- The wire format of `join_server`, `access_denied`, role/ban update envelopes → [websocket-envelopes](./websocket-envelopes.md).
- Online status, voice presence, game activity → [presence](./presence.md).
## Key concepts
- **Role** — named row in `server_role` with a `position` (higher number = higher precedence) and a `PermissionStatePayload` of per-key overrides (`allow | deny | inherit`).
- **System role** — bootstrap roles seeded by `1000000000005-ServerRoleAccessControl.ts`: `system-everyone`, `system-moderator`, `system-admin`. `system-everyone` applies to all members; the others are assignable.
- **RoleAssignment** — (server, user, role) row in `server_user_role`.
- **ChannelPermissionOverride** — (server, channel, role) row in `server_channel_permission` carrying allow / deny / inherit per permission key on top of the role's base state.
- **Membership** — (server, user) row in `server_membership` with `createdAt` and optional metadata.
- **Invite** — single-use or multi-use server invite in `server_invite`; default expiry **10 days** from creation.
- **Ban** — (server, user) entry in `server_ban` with optional `expiresAt` and `reason`. Persists across reconnects.
- **Slowmode** — per-channel send interval (`slowModeInterval` on the channel) — currently a client-rendered hint, not enforced server-side (see TODOs).
---
## Permission keys
Defined as a `PermissionStatePayload` in `server/src/cqrs/types.ts`. ~11 keys gate distinct capabilities:
- `manageServer` — edit server metadata (name, icon, settings).
- `manageChannels` — create / edit / delete channels.
- `manageRoles` — create / edit / delete roles (subject to role-position guard, see below).
- `moderateMember` — kick / ban / mute / change-nick on lower-positioned members.
- `inviteMember` — create invites.
- `viewChannel` — see a channel exists.
- `readMessages` — read message history in a channel.
- `writeMessages` — send messages.
- `manageMessages` — delete / pin others' messages.
- `connectVoice` — join a voice room.
- `speakVoice` — un-mute in a voice room.
Each key may be `allow`, `deny`, or `inherit` on a given role. The default state on `system-everyone` is permissive for "read / view / write" and restrictive for "manage / moderate"; see the migration for the seed values.
### Resolution algorithm
For a (user, channel) lookup:
1. Collect the user's role assignments for the server, plus the implicit `system-everyone`.
2. Order roles by `position` ascending — **lowest position resolved first**, highest position resolved last (last-writer-wins).
3. For each role, apply its base `PermissionStatePayload` to a running accumulator: `allow` and `deny` overwrite; `inherit` leaves the prior value intact.
4. Apply the channel's per-role overrides (`server_channel_permission`) on top, in the same position order.
5. The accumulator's final value per key is the effective permission.
Because there is no inherent `deny > allow` priority, a higher-positioned role's `allow` will *override* a lower-positioned role's `deny` on the same key. This is the intentional Discord-style "promote to override" model. Document any deviation from this when introducing a new key.
---
## Membership state machine
Entry into a server runs through `joinServerWithAccess` in `server/src/services/server-access.service.ts`:
1. Look up the server. If missing → reject.
2. Look up the user's membership. If active → fast-path success.
3. Look up an active ban for `(server, user)`. If present and not expired → reject with `banned`.
4. If the server is **public** (`isPublic = true`, no password, no invite required) → create membership, return success.
5. If the server is **password-protected** (`hasPassword = true`) → require the supplied password to hash-match. If mismatch → reject with `password_required` / `bad_password`.
6. If the server is **invite-only** → require a valid (`server_invite.code`) and non-expired invite. Consume the invite if single-use.
7. On success → insert a `server_membership` row, return ok.
`authorizeWebSocketJoin` is the lighter gate used on the `join_server` WebSocket envelope: it short-circuits to "allowed" if a membership already exists, otherwise reports the access mode needed. Unlike `joinServerWithAccess`, it does **not** consume invites or process passwords — those flow through dedicated REST routes on the server before the client retries the WebSocket join.
`handleJoinServer` (`server/src/websocket/handler.ts:155`) is the call site: on rejection the server sends `access_denied` with a reason (`banned`, `password_required`, `invite_required`, ...); on success it broadcasts presence (`user_joined`) per the rules documented in [presence](./presence.md).
---
## Moderation actions
Moderation is gated by two helpers in `server/src/services/server-permissions.service.ts`:
- `canManageServerUpdate(actorRoles, requested)` — maps the requested change (rename, icon change, permission edit, role create, invite, etc.) to the permission key it needs, then resolves the actor's effective state.
- `canModerateServerMember(actorHighestRole, targetHighestRole)` — privilege-escalation guard: the actor's highest-position role must be **strictly greater** than the target's highest-position role. Two moderators at the same position cannot ban each other.
Bans are written via `banServerUser`. The ban entity supports an optional `expiresAt` for time-limited bans and a `reason` string for moderator-facing UI.
Kick is implemented as "delete membership"; the connection is dropped via a subsequent WebSocket close on the next envelope.
---
## Client-side hydration
When the client joins a server, the server sends the room model with normalized access-control fields:
```
roles: ServerRolePayload[]
roleAssignments: RoleAssignmentPayload[]
channelPermissions: ChannelPermissionPayload[]
permissions: legacy RoomPermissions bools (back-compat)
slowModeInterval: number | undefined (per-channel)
```
`normalizeRoomAccessControl` in `toju-app/src/app/shared-kernel/room.models.ts` is the single normalization helper. It:
- Backfills the legacy `permissions` booleans from the role state so older NgRx selectors keep working.
- Sorts roles by `position` ascending.
- De-duplicates assignments by `(userId, roleId)`.
Client-side resolution mirrors the server algorithm and lives under `toju-app/src/app/domains/access-control/domain/rules/`. Selectors expose `canSendMessage(channelId)`, `canManageRole(roleId)`, etc., which UI components consume to disable controls.
`canManageRole` enforces the same privilege-escalation guard as the server: a user cannot edit a role at or above their own highest position.
---
## Invites
`server_invite` rows have:
- `code` — opaque token used in invite URLs.
- `serverId`, `createdById`.
- `expiresAt` — default 10 days from creation.
- `maxUses` / `uses` — single-use or multi-use semantics.
The REST surface for invite creation, lookup, and consumption is part of [server-directory](./server-directory.md). Invite consumption is **transactional**: a single-use invite is decremented before the membership row is created so a race cannot create two memberships off one invite.
---
## Bans
`server_ban` rows carry `userId`, `serverId`, optional `expiresAt`, optional `reason`, and `createdById`. Active bans are matched on `(serverId, userId)` with the expiry filter applied at read time. A ban broadcast envelope notifies connected peers so the client can drop the banned user from the local room model — TODO: confirm whether such an envelope exists today or whether clients only learn of bans on the next `server_users` snapshot.
---
## Slowmode
`slowModeInterval` is a per-channel hint expressed in seconds. The client renders the cooldown UI and is expected to gate the send button locally. The server does **not** enforce slowmode today — a non-cooperating client can ignore the interval. This is a known gap; see TODOs.
---
## Business rules and invariants
- **Server is authoritative.** Client-side `canX` selectors are advisory and exist to prevent UI confusion, not to gate security.
- **Last-writer-wins by position** — there is no inherent allow/deny priority; a higher-positioned role can override a lower-positioned role's deny.
- **Privilege escalation is blocked** by requiring strict position-greater on the moderator. Same-position moderation is rejected on both sides.
- **Invite consumption is atomic** for single-use invites.
- **Bans persist independently of memberships** — a banned user without a membership row is still banned.
- **`system-everyone` always applies** at position 0 (or whatever the migration seeds); it cannot be removed.
- **Channel overrides resolve last** after role base state.
---
## Technical implementation
### Server
- Services — `server/src/services/server-access.service.ts` (`authorizeWebSocketJoin`, `joinServerWithAccess`, `ensureServerMembership`, `banServerUser`, `leaveServerUser`); `server/src/services/server-permissions.service.ts` (`getServerRoles`, `getServerAssignments`, `resolveRolePermissionState`, `resolveHighestRole`, `canManageServerUpdate`, `canModerateServerMember`).
- Entities — `server/src/entities/ServerMembershipEntity.ts`, `ServerBanEntity.ts`, `ServerInviteEntity.ts`, `ServerRoleEntity.ts`, `ServerUserRoleEntity.ts`, `ServerChannelPermissionEntity.ts`.
- Migrations — `1000000000001-ServerAccessControl.ts`, `1000000000005-ServerRoleAccessControl.ts`.
- CQRS — payload types in `server/src/cqrs/types.ts` (`AccessRolePayload`, `PermissionStatePayload`, `RoleAssignmentPayload`, `ChannelPermissionPayload`); normalization in `server/src/cqrs/relations.ts` (`normalizeServerRoles`, `normalizeServerRoleAssignments`).
- REST — server / role / invite / ban routes are mounted under `server/src/routes/servers.ts` (catalog endpoints are documented in [server-directory](./server-directory.md)).
- WS — `server/src/websocket/handler.ts::handleJoinServer` (line 155), `access_denied` emission.
### Product client
- Domain — `toju-app/src/app/domains/access-control/`.
- Shared kernel — `toju-app/src/app/shared-kernel/access-control.models.ts`, `moderation.models.ts`, `room.models.ts` (`normalizeRoomAccessControl`).
- NgRx — access-control reducers / selectors under `toju-app/src/app/store/access-control/`.
---
## Testing
- TODO: no spec was located for `server-access.service.ts` or `server-permissions.service.ts`.
- TODO: no spec was located for the `authorizeWebSocketJoin` rejection paths.
- Client-side rule specs likely exist under `toju-app/src/app/domains/access-control/domain/rules/*.spec.ts` — confirm and list when filling in.
- TODO: E2E coverage for invite consumption, ban enforcement, and role-position escalation.
---
## Security considerations
- **Slowmode is not server-enforced.** A modified client can spam. Treat slowmode as an anti-accident measure, not abuse mitigation.
- **No server-side channel-permission enforcement on message send** — only role-state is checked at the join gate. TODO: verify whether per-channel overrides are applied on the message-send path.
- **No audit log** of moderation actions. TODO.
- **Password-protected servers** rely on the same SHA-256 hashing used for AuthUser passwords — see Security in [authentication](./authentication.md); the same caveats apply.
- **Position-based escalation guard** works only if positions are well-ordered. Position assignment is on `manageRoles`-bearing users; misconfiguration can produce moderators who can demote each other arbitrarily.
- **Bans are not always broadcast in real time** — clients may discover an ongoing ban only on the next `server_users` snapshot. TODO: confirm the live ban envelope.
---
## Performance considerations
- Role and assignment lookups are point queries on `server_role` / `server_user_role` indexed by `serverId`.
- Per-channel override resolution is O(roles × channels) at hydration time; happens once on `join_server` and is cached client-side.
- `authorizeWebSocketJoin` is O(1) for existing members (single membership lookup), O(1)O(invites) for invite consumption.
---
## Known issues and limitations
- **No server-side slowmode enforcement.**
- **No dedicated ban-broadcast envelope** (or unconfirmed).
- **No audit log** for moderation actions.
- **Channel-permission overrides may not be applied on the message-send path** server-side — TODO.
- **Unsalted SHA-256** for password-protected server passwords — same gap as user passwords.
---
## Related features
- **[server-directory](./server-directory.md)** — owns server catalog, discoverability, and the REST surface for invites/bans/roles.
- **[authentication](./authentication.md)** — provides the `oderId` identity that access-control authorizes.
- **[presence](./presence.md)** — `user_joined` / `user_left` are emitted only after `authorizeWebSocketJoin` succeeds.
- **[websocket-envelopes](./websocket-envelopes.md)** — owns the wire shape of `join_server`, `access_denied`, role/ban update envelopes.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,196 @@
# Attachments
> **Area:** attachments
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
Attachments are pure peer-to-peer in Toju. The signaling server never sees a file byte. A sender announces an attachment on the WebRTC chat data channel; a receiver requests it; the sender streams base64-encoded 64 KiB chunks back; the receiver reassembles and (on Electron) writes the result to disk under a per-conversation folder. If the original sender goes offline mid-transfer, the receiver can re-request from another peer that previously announced the same attachment. There is no inventory protocol, no integrity signature, and no server-side fallback — attachments live entirely on the participants' machines.
This area is the closest sibling of [voice-signaling](./voice-signaling.md): both are P2P protocols that ride the same RTCPeerConnection. The chat events that drive attachments are members of the `ChatEvent` union; they share the data channel with chat messages but are conceptually distinct.
## Responsibilities
- Define the file-transfer envelope set (announce / request / chunk / cancel / not-found) and its sequencing rules.
- Maintain per-transfer state on both sides — chunk index, in-flight chunk, retry/failover bookkeeping.
- Decide whether to auto-download (size + media-type heuristic).
- Decide where to persist (Electron disk vs browser memory).
- Estimate transfer speed via EWMA so the UI can render a progress bar that doesn't jitter.
- Pick a failover peer when the current sender disappears.
This area does **not** own:
- The chat message that references the attachment → [messaging](./messaging.md).
- The peer connection or data channel itself → [voice-signaling](./voice-signaling.md).
- The IPC channels used to read / write the file on Electron → [ipc-bridge](./ipc-bridge.md).
- Permission to upload — there is no formal upload gate today; access-control's `writeMessages` is the proxy. See [access-control](./access-control.md).
## Key concepts
- **Attachment** — a file announced and referenced by a chat message. Persisted independently of the message body.
- **Transfer** — the per-receiver state for a single in-flight attachment.
- **Bucket** — storage subfolder: `image | video | audio | files`. Determined by MIME type.
- **Tried-peer set** — the set of peers a receiver has already attempted for a given `${messageId}:${fileId}`; used to drive failover without re-trying the same peer in a loop.
- **`uploaderPeerId`** — the original announcer; the receiver prefers it over the tried-peer set when (re-)issuing a `file-request`.
---
## Protocol
The five events live in the `ChatEvent` union (`toju-app/src/app/shared-kernel/chat-events.ts`) and ride the WebRTC `chat` data channel. They do **not** flow through the WebSocket signaling server.
- `file-announce` — sender announces an attachment alongside a chat message. Carries `messageId`, `fileId`, `name`, `size`, `mimeType`, optional preview metadata.
- `file-request` — receiver requests the attachment from a specific peer.
- `file-chunk` — sender streams `index`, base64-encoded chunk payload, and `total` chunk count.
- `file-cancel` — either side aborts the in-flight transfer.
- `file-not-found` — sender responds when asked for an unknown `fileId`.
### Constants
Defined in the attachment domain (`toju-app/src/app/domains/attachment/`):
- `P2P_BASE64_CHUNK_SIZE_BYTES = 64 * 1024` — re-exported as `FILE_CHUNK_SIZE_BYTES`. Shared with the avatar P2P sync path.
- `MAX_AUTO_SAVE_SIZE_BYTES = 10 * 1024 * 1024` — files at or under 10 MiB are auto-downloaded on receipt.
- `MAX_BROWSER_INLINE_MEDIA_SIZE_BYTES = 50 * 1024 * 1024` — browser-mode cap on inlined media.
- **EWMA weights** — previous-weight `0.7`, current-weight `0.3` for transfer-rate smoothing.
- **Data-channel water marks** — `highWaterMark = 4 MiB`, `lowWaterMark = 1 MiB` for backpressure pacing.
### Flow
1. Sender computes attachment metadata and emits `file-announce` referencing the chat message.
2. Receiver opens a transfer state. Auto-download triggers if `size ≤ MAX_AUTO_SAVE_SIZE_BYTES` and the MIME type is in the allow-list for the bucket. Larger files require an explicit user click.
3. Receiver sends `file-request` to `uploaderPeerId`.
4. Sender streams `file-chunk` events sequentially. **Exactly one chunk is in flight per receiver at a time** — the sender awaits the per-chunk write/ack before queueing the next one. On Electron the receiver writes each chunk to disk; the protocol requires `index === receivedCount` for the next chunk or the transfer aborts.
5. Receiver reassembles. On Electron, the file lands at:
- `{appData}/server/{room}/{bucket}/{id}{.ext}` for server-channel attachments.
- `{appData}/direct-messages/{conv}/{bucket}/{id}{.ext}` for DM attachments.
- Browser mode keeps the file as a Blob in memory — lost on reload.
6. Either side may `file-cancel`; the sender returns `file-not-found` if the requested `fileId` is unknown.
### Failover
- Receiver-driven. No inventory protocol.
- Sequential — tries one peer at a time.
- The tried-peer set is keyed by `${messageId}:${fileId}`.
- `uploaderPeerId` is always preferred when reachable; the tried-peer set ensures it isn't re-attempted in a busy loop after a failure.
- If every available peer is in the tried set, the transfer ends in a not-found state and surfaces a UI prompt.
---
## Storage
### Electron
- `AttachmentEntity` — TypeORM row in the per-user local database. Carries `id`, `messageId`, `roomId` / `conversationId`, `name`, `size`, `mimeType`, `bucket`, `relativePath`, `createdAt`.
- CQRS commands — `save-attachment`, `delete-attachments-for-message`.
- CQRS queries — `get-all-attachments`, `get-attachments-for-message`.
- Filesystem IPC — `read-file-chunk`, `get-file-size`, `write-file`, `append-file`, `get-file-url`, `file-exists`, `delete-file`, `ensure-dir`, `get-app-data-path`.
The renderer never touches Node.js filesystem APIs directly; every read/write is brokered through [ipc-bridge](./ipc-bridge.md).
### Browser
When the desktop shell is not present, attachments stay in-memory as Blob URLs. Reloading the renderer loses them; this is documented behavior, not a bug.
---
## Auto-download heuristic
- Any file with `size ≤ 10 MiB` and a media MIME type (`image/*`, `video/*`, `audio/*`) is auto-downloaded on receipt so the chat UI can render it inline.
- Files above the cap or in the `files` bucket require an explicit click. The chat UI shows a "Download" affordance with the file size.
---
## Speed estimation (EWMA)
Transfer rate is exposed to the UI via an exponentially-weighted moving average:
```
rate_t = 0.7 · rate_{t-1} + 0.3 · instantaneous_t
```
Smooth enough for a stable progress display; responsive enough to surface a stalled transfer within a few seconds.
---
## Business rules and invariants
- Attachments are **pure P2P** — the signaling server never sees an attachment byte.
- **One chunk in flight per sender → receiver** (`await` per chunk). No parallelism within a single transfer.
- **Sequential chunk indices on Electron disk receive** — `index === receivedCount` is enforced; mismatches abort.
- **`PeerDeliveryService` is not on the attachment path.** Attachments use `RealtimeSessionFacade.broadcastMessage` / `sendToPeer` / `sendToPeerBuffered` directly.
- **Browser mode loses everything on reload** — no IndexedDB persistence today for attachments.
- **No integrity / signature check** on chunks; no encryption at rest beyond OS file permissions.
- **Failover is receiver-driven** and tried-peer-set deduplicated.
---
## Technical implementation
### Product client
- Domain — `toju-app/src/app/domains/attachment/`: manager, transfer state, persistence selection.
- Contracts — `toju-app/src/app/shared-kernel/attachment-contracts.ts`, `chat-events.ts` (the five envelope types).
- Realtime send paths — `RealtimeSessionFacade.broadcastMessage` / `sendToPeer` / `sendToPeerBuffered` in the realtime infrastructure tree.
### Electron
- Entity — `AttachmentEntity` in `electron/entities/`.
- CQRS handlers — under `electron/src/cqrs/` (or equivalent) for `save-attachment`, `delete-attachments-for-message`, `get-all-attachments`, `get-attachments-for-message`.
- Filesystem IPC handlers — `electron/ipc/`: `read-file-chunk`, `get-file-size`, `write-file`, `append-file`, `get-file-url`, `file-exists`, `delete-file`, `ensure-dir`, `get-app-data-path`.
### Key types
- `AttachmentEntity` — local persistence row.
- `FileChunkEvent`, `FileAnnounceEvent`, `FileRequestEvent`, `FileCancelEvent`, `FileNotFoundEvent` — member shapes of the `ChatEvent` union.
---
## Testing
- TODO: no dedicated `*.spec.ts` files under `toju-app/src/app/domains/attachment/` at time of writing.
- E2E: `e2e/tests/chat/chat-message-features.spec.ts` includes `test('syncs image and file attachments between users', ...)` which covers happy-path attachment sync.
- TODO: no E2E coverage for multi-peer failover.
- TODO: no E2E coverage for `file-cancel`.
---
## Security considerations
- **No integrity signature.** A malicious sender can corrupt a chunk; the receiver assembles whatever arrives.
- **No encryption at rest** beyond OS-level file permissions on the per-user app-data folder.
- **No MIME-type sanitation.** The receiver trusts the announced `mimeType` for bucket routing; a misleading MIME does not change the on-disk contents but does affect inline rendering. Browser-side renderers must defend against this.
- **No size cap server-side.** Caps are receiver-side and advisory: `MAX_AUTO_SAVE_SIZE_BYTES` for auto-download, `MAX_BROWSER_INLINE_MEDIA_SIZE_BYTES` for in-memory media. A sender can announce arbitrarily large files; the receiver simply refuses them.
- **Receivers expose disk write paths** indirectly: a misbehaving peer cannot escape `{appData}/server/...` or `{appData}/direct-messages/...` because the relative path is computed by the receiver, not transmitted by the sender — but this property must be preserved in any future protocol change.
---
## Performance considerations
- **Base64 overhead.** ~33 % inflation on the wire; a 64 KiB binary chunk is ~86 KiB on the wire.
- **Single chunk in flight** per (sender, receiver) — caps single-receiver throughput at one round-trip per chunk.
- **Data-channel water marks** (4 MiB high, 1 MiB low) provide back-pressure pacing without tuning per-NIC.
- **No FEC, no parallel chunks, no resumption across browser reloads.**
---
## Known issues and limitations
- **No dedicated unit specs** for the attachment domain.
- **No resume across browser reloads** (Electron writes to disk and survives; browser does not).
- **No checksum / signed integrity** on chunks.
- **No encryption at rest** beyond OS file permissions.
- **No server-side fallback** if every peer is offline — attachments are unreachable until at least one peer with the file returns.
---
## Related features
- **[messaging](./messaging.md)** — chat messages reference attachments; attachments are persisted separately from message bodies.
- **[voice-signaling](./voice-signaling.md)** — establishes the data channel that attachments ride on.
- **[ipc-bridge](./ipc-bridge.md)** — exposes the filesystem and CQRS APIs the Electron persistence path uses.
- **[websocket-envelopes](./websocket-envelopes.md)** — for context only; attachments do not flow through the signaling server.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,194 @@
# Authentication
> **Area:** authentication
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
User identity in Toju is split into two surfaces. A small **HTTP credential surface** on the signaling server (`/api/users/register`, `/api/users/login`) registers and verifies user accounts persisted in TypeORM. A separate **WebSocket `identify` handshake** binds a *self-asserted* identity (`oderId` + display name + optional description) to a live WebSocket connection so the server can route envelopes. There is no server-issued session token: the client re-asserts identity on every reconnect, and other peers trust the claim as far as the signaling fabric does — i.e. only to the extent that subsequent authorization checks (see [access-control](./access-control.md)) accept it.
The Electron desktop shell adds a third surface — the **Local API token store** in `electron/api/auth-store.ts` — which issues short-lived bearer tokens for the in-process HTTP server that hosts the docs site and OpenAPI bundle. That surface is internal to the desktop process and is documented here only because it shares the "authentication" name.
## Responsibilities
- Register and authenticate user accounts against the signaling server's `users` table.
- Bind a connection-scoped identity to a WebSocket connection via the `identify` envelope, including profile metadata propagation.
- Detect dead WebSocket connections via ping/pong sweeps and reap stale `ConnectedUser` rows.
- Mint and validate short-lived bearer tokens for the Electron Local API server.
This area does **not** own:
- Permissions, roles, bans, or membership state → [access-control](./access-control.md).
- Online / away / busy status, voice presence, game activity → [presence](./presence.md).
- The shape of WebSocket envelopes carrying identity claims → [websocket-envelopes](./websocket-envelopes.md).
- Profile avatar bytes or per-user assets → product-client `profile-avatar` domain.
## Key concepts
- **AuthUser** — server-persisted account: `id` (uuid), `username` (unique), `passwordHash`, `displayName`, `createdAt`. Defined in `server/src/entities/AuthUserEntity.ts`.
- **oderId** — client-asserted user identifier sent on `identify`. Used as the broadcast routing key. The server **trusts** it; there is no cryptographic binding between an AuthUser row and the `oderId` claimed over WebSocket.
- **Identify handshake** — first message a client sends on a WebSocket. Carries `oderId`, `displayName`, optional `description`, optional `profileUpdatedAt`, optional `connectionScope`.
- **Connection scope** — opaque string (typically the signal URL the client connected through). Used together with `oderId` to disambiguate multiple sockets per identity so stale-connection eviction does not loop across signal URLs.
- **Local API token** — bearer token issued by the Electron desktop process, 24 h TTL, kept in-memory and pruned on access.
---
## HTTP credential surface
Mounted at `/api/users` (see `server/src/routes/index.ts:20`). All payloads are JSON.
### `POST /api/users/register`
**Request:**
```json
{
"username": "string (required, unique)",
"password": "string (required)",
"displayName": "string (optional, defaults to username)"
}
```
**Response (201):**
```json
{ "id": "uuid", "username": "string", "displayName": "string" }
```
**Errors:**
- **400** `Missing username/password` — either field absent.
- **409** `Username taken` — username already exists.
### `POST /api/users/login`
**Request:** `{ "username": "string", "password": "string" }`
**Response (200):** `{ "id": "uuid", "username": "string", "displayName": "string" }`
**Errors:**
- **401** `Invalid credentials` — no row matches, or stored hash differs.
No session cookie, JWT, or bearer token is issued — the response is purely informational. The client is expected to remember the username and re-present it via the WebSocket `identify` handshake on every reconnect.
---
## WebSocket `identify` handshake
`handleIdentify` (`server/src/websocket/handler.ts:112`) processes the first envelope a client sends. It:
1. Reads `oderId` (falls back to `connectionId` when absent).
2. Reads `connectionScope` (opaque routing key).
3. Reads / normalizes `displayName`, `description`, `profileUpdatedAt`.
4. Mutates the `ConnectedUser` row in `connectedUsers`.
5. If any of `displayName` / `description` / `profileUpdatedAt` changed, rebroadcasts `user_joined` to every server the user is currently in.
`identify` itself is unauthenticated — the server does not consult `AuthUserEntity` here. Authorization happens later, at `join_server` time, via `authorizeWebSocketJoin` (documented in [access-control](./access-control.md)).
`identify` is the canonical channel for **profile updates**. Renaming yourself or updating your description means resending `identify`; the rebroadcast pushes the new profile to peers without disconnect/reconnect.
---
## Heartbeat and dead-connection sweep
Defined in `server/src/websocket/index.ts:19``75`:
- `PING_INTERVAL_MS = 30_000` — server pings every connection every 30 s.
- `PONG_TIMEOUT_MS = 45_000` — a connection whose `lastPong` is older than 45 s is closed and removed from `connectedUsers`.
`lastPong` is bumped on any inbound frame (not just pong), so an active client cannot be reaped while sending traffic. Eviction triggers `handleLeaveServer` for every server the connection had joined, which in turn emits `user_left` if no other connection of the same `oderId` still holds the server.
---
## Electron Local API token store
`electron/api/auth-store.ts` mints opaque bearer tokens used by the Local API server (`electron/api/router.ts`) to gate calls to `/api/auth/login` and other authenticated routes. Tokens have a 24 h TTL and are kept in-memory only — they do not persist across desktop restarts. Pruning happens lazily on lookup.
This surface is **not** the same identity as the signaling server's AuthUser. It is a desktop-local affordance for the in-process HTTP server that serves docs and plugin APIs; the renderer never sees these tokens.
---
## Business rules and invariants
- Usernames are **unique** at the database level (`@Column('text', { unique: true })` on `AuthUserEntity.username`) AND pre-checked in the route handler. Comparison is **case-sensitive**.
- Passwords are hashed with **unsalted SHA-256** (`crypto.createHash('sha256')`, `routes/users.ts:8`). There is no salting, no peppering, no iteration count, no Argon2/bcrypt. This is a known weakness — see Security below.
- The signaling server never issues a session token. Identity is re-asserted on every reconnect via `identify`.
- The `identify` claim is **not verified** against `AuthUserEntity`. Two clients can claim the same `oderId`; only `(oderId, connectionScope)` is used to deduplicate eviction.
- `user_joined` is only re-broadcast on `identify` when at least one of `displayName` / `description` / `profileUpdatedAt` actually changed — duplicate identifies are silent.
- Dead-connection sweep runs continuously. A client that goes silent for ≥ 45 s is treated as disconnected.
---
## Technical implementation
### Server (signaling)
- HTTP routes: `server/src/routes/users.ts`, mounted at `/api/users` in `server/src/routes/index.ts`.
- CQRS handlers: `server/src/cqrs/commands/handlers/registerUser.ts`, `server/src/cqrs/queries/handlers/getUserByUsername.ts`, `server/src/cqrs/queries/handlers/getUserById.ts`.
- Entity: `server/src/entities/AuthUserEntity.ts` (`users` table).
- Migration: `server/src/migrations/1000000000000-InitialSchema.ts`.
- WebSocket handshake: `server/src/websocket/handler.ts::handleIdentify` (line 112).
- `ConnectedUser` shape: `server/src/websocket/types.ts`.
- Heartbeat sweep: `server/src/websocket/index.ts`.
### Product client
- Domain: `toju-app/src/app/domains/authentication/`.
- Service: `authentication.service.ts` (login / register HTTP calls).
- Components: `login.component.ts`, `register.component.ts`.
- Model: `authentication.model.ts`.
### Electron
- Local API token store: `electron/api/auth-store.ts`.
- Local API router: `electron/api/router.ts` (`/api/auth/login` endpoint).
### Key types
- `AuthUserEntity` — server account row.
- `ConnectedUser` — live WebSocket connection state, including `oderId`, `connectionScope`, `lastPong`.
---
## Testing
- E2E: `e2e/tests/auth/user-session-data-isolation.spec.ts` — verifies session-level data isolation between users.
- TODO: no unit specs were located for `server/src/routes/users.ts`, `handleRegisterUser`, `getUserByUsername`/`getUserById`, `handleIdentify`, the Electron `/api/auth/login` proxy, or the `toju-app` authentication services.
- TODO: no happy-path login/register E2E exists today.
---
## Security considerations
- **Password hashing is unsalted SHA-256.** Vulnerable to rainbow-table and parallel GPU attacks. Replacing with Argon2id or bcrypt is the obvious upgrade path and is currently a TODO.
- **No rate limiting on `/login`.** A `users` table with weak hashes is exposed to credential stuffing and online brute-force.
- **`identify` is unauthenticated.** Any WebSocket can claim any `oderId`. The real authorization gate is `authorizeWebSocketJoin` on `join_server`, which checks membership / invite / password against the access-control tables — until that gate is crossed, an unverified `oderId` cannot do anything meaningful beyond joining the public lobby.
- **No reuse-prevention on `displayName`.** Two distinct accounts may carry the same display name. UI must therefore disambiguate by `oderId` where identity actually matters.
- **Local API tokens** never leave the desktop process and have a 24 h TTL — they are not a credential primitive for the signaling server.
---
## Performance considerations
- `/register` and `/login` are O(1) lookups against a `UNIQUE` index on `username`. No caching layer.
- `identify` is O(serversJoinedByThisConnection) on profile change because of the rebroadcast loop; profile updates are rare so this is negligible.
- Dead-connection sweep is O(connections) per `PING_INTERVAL_MS`; trivially scalable for a single-process signaling server.
---
## Known issues and limitations
- **Unsalted SHA-256 password hashing.** Highest-priority hardening target.
- **No password reset, email confirmation, MFA, or account recovery.**
- **No audit log** of register/login events.
- **No binding between `AuthUserEntity.id` and the claimed `oderId`.** A future hardening pass should require the client to prove possession of an `AuthUser` credential before the server accepts an `identify` payload that names that user — likely via a signed challenge.
- **No spec coverage** for the HTTP credential surface or the identify handshake.
---
## Related features
- **[access-control](./access-control.md)** — consumes the `oderId` claimed via `identify` to authorize server joins, role lookups, and moderation actions.
- **[presence](./presence.md)** — `identify` is the canonical channel for profile-metadata updates that presence broadcasts forward.
- **[websocket-envelopes](./websocket-envelopes.md)** — owns the wire shape of `identify`, `user_joined`, and `access_denied`.
- **[ipc-bridge](./ipc-bridge.md)** — the Electron Local API token store lives behind the same IPC boundary as other privileged operations.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,183 @@
# [Feature Name]
> **Area:** [area-name]
> **Status:** Active | In Progress | Deprecated
> **Last updated:** YYYY-MM-DD
## Overview
One paragraph describing what this feature does and why it exists.
## Responsibilities
- What this feature is responsible for
- Its boundaries — what it does NOT own
## Key concepts
- **ConceptA**: short definition
- **ConceptB**: short definition
---
## API Endpoint
### Endpoint Details
- **Method**: [GET | POST | PUT | PATCH | DELETE]
- **Path**: `/api/v1/[feature-path]`
- **Authentication**: [Required | Optional | None]
- **Rate Limiting**: [Yes — describe | No]
### Request Schema
```json
{
"field": "type — description"
}
```
**Required fields:**
- `field` (type, constraints): description
**Optional fields:**
- `field` (type): description. Defaults to "X" if not provided.
### Response Schema
```json
{
"field": "type — description"
}
```
### Error Responses
- **400 Bad Request**: [specific causes]
- **401 Unauthorized**: missing or invalid authentication
- **404 Not Found**: [when this applies]
- **500 Internal Server Error**: [specific causes]
---
## Business Logic
### Core Functionality
1. **Step 1**: description
2. **Step 2**: description
3. **Step 3**: description
### Business Rules
- Rule 1
- Rule 2
### Data Flow
```
Input → Validation → [Processing Steps] → Response
```
### Dependencies
- **Service/Library**: what it's used for
- **External API**: what it's used for
- **Database**: what tables/collections are involved
---
## Technical Implementation
### Service Layer
- **Location**: `path/to/service`
- **Key methods**: `methodName()` — description
### Controller / Handler
- **Location**: `path/to/handler`
- **Responsibilities**: request validation, service invocation, response formatting
### Repository / Data Access
- **Location**: `path/to/repository`
- **Tables/Collections**: list the relevant database objects
- **Migrations**: reference the migration that created/modified the schema
### Key Types
- `TypeName`: description of what it represents
---
## Configuration
### Environment Variables
- `VAR_NAME`: description (required | optional, default: X)
### Feature Flags
- [List any feature flags, or "None"]
---
## Testing
### Unit Tests
- **Location**: `path/to/tests`
- **Key scenarios**: list the most important test cases
### Integration Tests
- **Location**: `path/to/integration/tests`
- **Setup**: describe any required infrastructure (database, external services, etc.)
- **Mocking**: what external services are mocked and how
---
## Error Handling & Edge Cases
### Common Errors
- **Error scenario**: how it's handled
### Edge Cases
- **Edge case**: expected behavior
---
## Security Considerations
- Authentication requirements
- Authorization / access control
- Input validation and sanitization
- Data privacy considerations
---
## Performance Considerations
- Expected response times
- Known bottlenecks
- Caching strategy (if any)
---
## Known Issues and Limitations
1. **Limitation**: description
---
## Related Features
- **[Related Feature]**: brief description of relationship
## Changelog
| Date | Change |
|------|--------|
| YYYY-MM-DD | Initial documentation |

View File

@@ -0,0 +1,178 @@
# Electron IPC Bridge
> **Area:** ipc-bridge
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
The Electron IPC bridge is the only path through which the Angular renderer can reach the desktop runtime — the filesystem, the local SQLite database, OS APIs, the update flow, plugin loading, and the in-process Local API server. The renderer cannot import `electron`, `node:fs`, TypeORM, or any other privileged module directly; every privileged operation crosses the preload `contextBridge` boundary as a typed IPC call. This area documents the surface itself: how it is registered, how it is consumed, and what guarantees do (or do not) hold.
## Responsibilities
- Expose a frozen, allow-listed set of methods on the renderer's global window object via the preload bridge.
- Register one `ipcMain` handler per exposed method, grouped by concern (`system`, `window-controls`, `cqrs`).
- Provide a CQRS abstraction over the local database (commands + queries dispatched through two generic channels).
- Translate main-process operations into renderer-safe values (file paths → URLs, native errors → structured responses where appropriate).
This area does **not** own:
- The schema or business logic behind any specific command/query (those live in `electron/cqrs/handlers/` and the affected product-client domains).
- The plugin manifest contract (see [plugin-system](./plugin-system.md)) — only the IPC methods that surface it.
- WebSocket signaling (see [websocket-envelopes](./websocket-envelopes.md)) — that bypasses Electron entirely.
## Key concepts
- **Preload bridge** — `electron/preload.ts`. The sole place `contextBridge.exposeInMainWorld` runs. Adding a method here requires a matching `ipcMain.handle` / `ipcMain.on` on the main side.
- **Window surface** — exposed as `window.electronAPI` on the renderer. (Note: `electron/CONTEXT.md` refers to this as `window.api.*` — the documented intent. The literal global today is `electronAPI`. TODO: pick one and align.)
- **CQRS channel** — two reserved channels `cqrs:command` and `cqrs:query` route every typed `Command`/`Query` through a single dispatch step, instead of one channel per operation.
- **Handler setup function** — registered once at app boot from `electron/ipc/index.ts`: `setupCqrsHandlers`, `setupSystemHandlers`, `setupWindowControlHandlers`.
- **Renderer bridge service** — `ElectronBridgeService` in `toju-app/src/app/core/platform/electron/electron-bridge.service.ts` is the Angular-side wrapper; domain services inject it rather than reaching for `window.electronAPI` directly.
---
## Surface catalogue
Defined in `electron/preload.ts`. Approximately 50 methods, grouped below by concern. For exact signatures see the file.
### Window controls (fire-and-forget)
- `minimizeWindow`, `maximizeWindow`, `closeWindow` — channels `window-minimize`, `window-maximize`, `window-close`. Implementation: `electron/ipc/window-controls.ts`. Uses `ipcMain.on` (no return value).
### Screen share & media
- `getSources` — DesktopCapturer source enumeration.
- Linux audio routing for screen-share monitor capture: `prepareLinuxScreenShareAudioRouting`, `activateLinuxScreenShareAudioRouting`, `deactivateLinuxScreenShareAudioRouting`, `startLinuxScreenShareMonitorCapture`, `stopLinuxScreenShareMonitorCapture`.
- Event listeners: `onLinuxScreenShareMonitorAudioChunk`, `onLinuxScreenShareMonitorAudioEnded`.
### Process & game detection
- `getRunningProcessNames` (via `electron/process-list.ts`).
- `getActiveGameCandidate` (via `electron/game-detection/`).
- `getIgnoredGameProcesses`, `setIgnoredGameProcesses`.
### File system
- `readFile`, `readFileChunk`, `getFileSize`, `writeFile`, `appendFile`, `deleteFile`, `fileExists`, `getFileUrl`, `ensureDir`, `saveFileAs`, `saveExistingFileAs`, `openFilePath`, `readClipboardFiles`.
- `getFileUrl` is the canonical way for the renderer to display a local file via `file://` — direct path access is forbidden.
### Theme & plugins (filesystem-backed)
- `getSavedThemesPath`, `listSavedThemes`, `readSavedTheme`, `writeSavedTheme`, `deleteSavedTheme`.
- `getLocalPluginsPath`, `listLocalPluginManifests`. See [plugin-system](./plugin-system.md) for the manifest contract.
### Settings & notifications
- `getDesktopSettings`, `setDesktopSettings`.
- `showDesktopNotification`, `requestWindowAttention`, `clearWindowAttention`, `onWindowStateChanged`.
### Auto-update
- `getAutoUpdateState`, `getAutoUpdateServerHealth`, `configureAutoUpdateContext`, `checkForAppUpdates`, `restartToApplyUpdate`, `onAutoUpdateStateChanged`.
### Local API & docs
- `getLocalApiStatus`, `openLocalApiDocs`, `openDocusaurusDocs`. The Local API server hosts the prebuilt Docusaurus bundle inside the desktop app — see `electron/api/local-api-server.ts`.
### App & deep links
- `relaunchApp`, `consumePendingDeepLink`, `onDeepLinkReceived`, `getAppDataPath`, `openCurrentDataFolder`.
### Data management
- `exportUserData`, `importUserData`, `eraseUserData`. Backed by `electron/data-archive.ts`.
### Clipboard & context menu
- `copyImageToClipboard`, `onContextMenu`, `contextMenuCommand`.
### Idle state
- `getIdleState`, `onIdleStateChanged`. Backed by `electron/idle/`.
### CQRS (typed database access)
- `command<T>(command: Command) => Promise<T>` → channel `cqrs:command`.
- `query<T>(query: Query) => Promise<T>` → channel `cqrs:query`.
- Command and query union types live in `electron/cqrs/types.ts`. Handlers are built dynamically per `DataSource` via `buildCommandHandlers(dataSource)` and `buildQueryHandlers(dataSource)` in `electron/ipc/cqrs.ts`.
- Current commands: `SaveMessage`, `DeleteMessage`, `UpdateMessage`, `ClearRoomMessages`, `SaveReaction`, `RemoveReaction`, `SaveUser`, `SetCurrentUserId`, `UpdateUser`, `SaveRoom`, `DeleteRoom`, `UpdateRoom`, `SaveBan`, `RemoveBan`, `SaveAttachment`, `DeleteAttachmentsForMessage`, `SavePluginData`, `DeletePluginData`, `SaveMeta`, `ClearAllData`.
- Current queries: `GetMessages`, `GetMessagesSince`, `GetMessageById`, `GetReactionsForMessage`, `GetUser`, `GetCurrentUser`, `GetCurrentUserId`, `GetUsersByRoom`, `GetRoom`, `GetAllRooms`, `GetBansForRoom`, `IsUserBanned`, `GetAttachmentsForMessage`, `GetAllAttachments`, `GetPluginData`, `GetMeta`.
- Unknown `type` raises `Error("No command/query handler for type: ${type}")`.
---
## Renderer consumption
- **`ElectronBridgeService`** (`toju-app/src/app/core/platform/electron/electron-bridge.service.ts`) — provides `getApi(): ElectronApi | null` and `requireApi(): ElectronApi`. Domain services inject the bridge service, never `window` directly. This also makes the bridge mockable for spec runs and the website preview (where `window.electronAPI` is absent).
- **CQRS wrapper**: `toju-app/src/app/infrastructure/persistence/electron-database.service.ts` wraps `api.command()` / `api.query()` with typed helpers; product-client domains use this rather than calling CQRS directly.
- **Per-domain consumers**: file I/O (`attachment`), theme (`theme`), profile-avatar, notifications, idle (used by presence), and game-activity domains each inject the bridge to reach their respective IPC slice.
---
## Error handling
`electron/CONTEXT.md` says:
> IPC handler errors are translated to typed error envelopes before crossing back into the renderer — the renderer never sees a raw `Error` from main.
In practice today:
- The CQRS layer throws raw `Error` objects on unknown `type` (caller sees the serialized message).
- Most `electron/ipc/system.ts` handlers catch errors and return structured response objects (e.g. `{ opened: false, reason: string }`), but the shape is per-handler, not centralised.
- There is no global error-envelope wrapper around `ipcMain.handle`.
**TODO**: reconcile the CONTEXT.md invariant with reality — either introduce a shared error-envelope wrapper or update the invariant to match the per-handler convention. Until then, treat error shapes as a per-method concern.
---
## Technical implementation
- **Preload**: `electron/preload.ts` (single source of truth for the exposed surface).
- **Registration**: `electron/ipc/index.ts` calls three setup functions at app boot — `setupCqrsHandlers`, `setupSystemHandlers`, `setupWindowControlHandlers`.
- **System handlers**: `electron/ipc/system.ts` (~40 channels, ~780 lines).
- **Window controls**: `electron/ipc/window-controls.ts` (3 channels, fire-and-forget).
- **CQRS handlers**: `electron/ipc/cqrs.ts` plus typed command/query unions in `electron/cqrs/types.ts` and per-handler implementations under `electron/cqrs/handlers/`.
- **Local SQLite access** is gated behind CQRS — no other channel exposes the database directly. See `electron/data-source.ts` and `electron/entities/`.
## Invariants
- The renderer never imports `electron`, Node APIs, or TypeORM directly. (Enforced by Electron's `contextIsolation` + no `nodeIntegration`.)
- Every method on `window.electronAPI` has exactly one IPC channel and exactly one main-process handler.
- Schema mutations go through a TypeORM migration in `electron/migrations/`; raw SQL never crosses the IPC bridge.
- All file access is path-based on the main side, URL-based on the renderer side (`getFileUrl`).
## Testing
- `electron/plugin-library.spec.ts` — plugin discovery (touches the same IPC path but tests the library, not the channel).
- `electron/idle/idle-monitor.spec.ts` — idle source unit test.
- **TODO**: no spec covers `preload.ts` exposure, the system handler set, the CQRS dispatcher, or the error path. Renderer-side `ElectronBridgeService` spec status not verified.
## Security considerations
- `contextIsolation: true` + no `nodeIntegration` in the renderer; `electron/preload.ts` is the only crossing.
- Adding a channel requires touching both `preload.ts` and `electron/ipc/`. There is no dynamic channel registration.
- File-system handlers should validate paths against user-data scope — TODO: audit `system.ts` for path-traversal protections beyond what the plugin loader does.
- Deep-link handling: `consumePendingDeepLink` returns a queued URL; validation lives in renderer routing. TODO: confirm allow-list / scheme filtering on the main side.
## Performance considerations
- IPC traffic is per-call serialization; large payloads (file chunks, attachment imports) go via `readFileChunk` + offsets instead of single `readFile` to avoid blocking the main process.
- CQRS calls hit the local SQLite database synchronously inside the main process. There is no batching layer.
## Known issues and limitations
- **Documented vs. actual API name** — the `window` global is `electronAPI`, not `api`. CONTEXT.md uses `window.api.*`. Reconcile in a future cleanup.
- **No typed error envelope** despite the CONTEXT.md invariant.
- **No preload-surface test** — additions are caught only at runtime / lint.
## Related features
- **[plugin-system](./plugin-system.md)** — surfaces `getLocalPluginsPath`, `listLocalPluginManifests`, and plugin data CQRS commands through this bridge.
- **[websocket-envelopes](./websocket-envelopes.md)** — the realtime path that bypasses the bridge; included here only to delineate the two surfaces.
- **[voice-signaling](./voice-signaling.md)** — uses `getSources` and the Linux audio routing methods for screen-share media capture.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,195 @@
# Messaging
> **Area:** messaging
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
Messaging in Toju covers two transports that share a single domain model. Server-channel chat is broadcast by the signaling server over WebSocket — fire-and-forget, no server-side persistence today. Direct messages (1:1 and group DMs) are peer-to-peer over the WebRTC chat data channel, with a signaling-server fallback when no data channel is open and an offline queue for when neither path is available. On both transports the client maintains a **monotonic delivery state machine** per message and a **chunked inventory-sync protocol** that lets two peers reconcile missing history without flooding the link.
This document is the cross-context contract: envelope names, sync protocol, delivery states, edit/delete rules, and storage decisions. The product-client domain READMEs at `toju-app/src/app/domains/chat/README.md` and `toju-app/src/app/domains/direct-message/README.md` cover internal NgRx state and effects; the wire shapes live in [websocket-envelopes](./websocket-envelopes.md).
## Responsibilities
- Send, edit, and delete server-channel chat messages over WebSocket (`chat_message`, `edit_message`, `delete_message`).
- Send, edit, and delete direct messages over the WebRTC data channel with signaling fallback.
- Carry typing indicators on server-channel chat (`user_typing`).
- Reconcile peer history via the inventory-sync protocol (chunked, capped backfill).
- Drive a monotonic delivery state machine: `QUEUED → SENT → DELIVERED → ACKNOWLEDGED`.
- Persist direct messages locally; the server keeps no message store.
This area does **not** own:
- Attachment payloads or the chunked file-transfer protocol → [attachments](./attachments.md).
- RTC negotiation that brings the data channel up → [voice-signaling](./voice-signaling.md).
- Permission to send a message (`writeMessages`, `manageMessages`, channel overrides, slowmode hint) → [access-control](./access-control.md).
- The wire shape of every envelope used here → [websocket-envelopes](./websocket-envelopes.md).
## Key concepts
- **Server-channel message** — broadcast through the signaling server to every connected peer of a server. No server-side persistence in the current build.
- **Direct message** — point-to-point or group P2P message, persisted locally per-user via Electron CQRS (and via `localStorage` on browser fallback today — TODO confirm).
- **Conversation** — 1:1 or group DM thread. Group DMs can be created by adding a third participant to a 1:1, which spawns a new conversation while preserving the original.
- **Inventory event** — peer-to-peer announcement of "here is what I have for this conversation/channel"; the receiver replies with a request for missing pieces.
- **Sync batch** — chunked response carrying up to 200 messages per envelope, capped at 1000 messages of backfill per inventory exchange.
- **Delivery state** — monotonic enum on a direct message: `QUEUED (0) → SENT (1) → DELIVERED (2) → ACKNOWLEDGED (3)`. Defined in the chat-events shared kernel; advanced via `advanceDirectMessageStatus`.
- **Peer-delivery service** — `PeerDeliveryService` (`toju-app/src/app/domains/direct-message/application/services/peer-delivery.service.ts`) — the dispatcher that tries the data channel first, then the signaling forward, then the offline queue.
---
## Transports
### Server-channel chat (WebSocket)
- Client sends `chat_message` to the signaling server; `handleChatMessage` (`server/src/websocket/handler.ts:274`) validates the user is in the target server and broadcasts to every other connection.
- `edit_message` and `delete_message` follow the same fan-out path.
- `user_typing` (`handleTyping`, `handler.ts:309`) is broadcast as a transient signal — no persistence, no sync, no delivery state.
- The server **does not persist** these envelopes. Late joiners do not see chat history older than their join — they can request it from peers via the inventory protocol if any peer present has it stored locally.
### Direct messages (WebRTC data channel)
- DMs ride the `chat`-labelled data channel established alongside each voice peer connection (see [voice-signaling](./voice-signaling.md)).
- `PeerDeliveryService` is the dispatcher. For each outgoing event it:
1. Tries every open data channel to a `recipients`-listed peer.
2. If no data channel is available to a recipient, falls back to a signaling-server `forwardPeerMessage` envelope so the server forwards it to that peer's connection.
3. If neither path is open, enqueues the event in `OfflineMessageQueueService` and replays on `peerConnected$` / `networkRestored$`.
- The server **forwards** DM envelopes opaquely — no inspection, no persistence.
### Storage
- **Direct messages** persist via Electron CQRS — see [ipc-bridge](./ipc-bridge.md). Each user has their own local TypeORM database; messages are written via `save-direct-message` / equivalent commands.
- **Server-channel chat** persists via `DatabaseService` (Electron CQRS) when running on desktop, or in IndexedDB when running purely in browser. TODO: confirm the IndexedDB code path.
- The signaling server holds **zero** message bytes at rest today. Re-deploys lose nothing because there is nothing to lose.
---
## Inventory / sync protocol
Both transports share the same inventory shape, defined in `toju-app/src/app/shared-kernel/chat-events.ts`:
- `ChatInventoryEvent` — sender broadcasts "for conversation X I have messages with these ids and last-modified timestamps" (capped at 1000 entries).
- `ChatSyncBatchEvent` — receiver replies with a chunked batch of full message payloads, **up to 200 per envelope**, repeated until the requested set is satisfied or 1000 messages have been returned.
Rules:
- Inventory is **additive**`mergeIncomingMessage` / `upsertDirectMessage` only insert or update; a sparser peer never wipes a richer peer's history.
- Reactions and attachment-link changes are reconciled by comparing per-message `lastModifiedAt`; the higher wins.
- The 1000-message ceiling is per inventory exchange, not per conversation lifetime; an older history can be filled in piecewise across multiple inventory cycles.
The same protocol is reused for the chat domain (server channels) and the direct-message domain. The implementation lives in `toju-app/src/app/domains/chat/domain/rules/message-sync.rules.ts` and is invoked from the direct-message effects via `DirectMessageService.requestSync()`.
---
## Delivery state machine
For DMs, every outgoing message has a `status`:
| Value | Numeric | Meaning |
|-------|---------|---------|
| `QUEUED` | 0 | Composed locally; no transport attempt has succeeded yet. |
| `SENT` | 1 | At least one transport (data channel or signaling forward) has accepted the payload. |
| `DELIVERED` | 2 | At least one recipient has acknowledged receipt at the application layer. |
| `ACKNOWLEDGED` | 3 | The full recipient set has acknowledged (1:1: the one recipient; group: every participant). |
Transitions are advanced via `advanceDirectMessageStatus`, which **only advances** — a higher value is never replaced by a lower one. A retried message that succeeds after a queue replay can therefore move `QUEUED → SENT` but never `DELIVERED → SENT`.
Server-channel messages do not carry an application-level delivery state today (the server broadcast is fire-and-forget); the UI treats them as `SENT` once the WebSocket accepts the frame.
---
## Edit and delete
- `edit-message` / `delete-message` events carry the original `messageId`. On both transports, the receiver locates the existing row (by id) and applies the mutation via `applyMutation`.
- DMs use the same envelope types but ride the data channel / signaling-forward fabric.
- Edits are last-writer-wins by `editedAt`. A delete removes the message body but keeps a tombstone with `deletedAt` so peers that haven't yet seen the delete can converge on the next inventory sync.
TODO: `applyMutation` does not currently verify the mutation originated from the original author. A non-cooperating client could send `edit-message` for someone else's message and a receiver would accept it. Confirm and either harden client-side or document the trust model.
---
## Typing indicators
- Server-channel only. DMs do not have a typing indicator today.
- Sent as `user_typing`; broadcast to a server scope.
- Transient: no persistence, no sync replay, no delivery state.
---
## Business rules and invariants
- The signaling server is **not authoritative** for messaging. `handleChatMessage` only broadcasts; there is no server-side message log.
- The delivery state machine is **monotonic**`advanceDirectMessageStatus` never moves status backwards.
- DM envelopes are **ignored** unless the local user appears in `participants` / `recipients` (or has an existing local conversation matching the id).
- Inventory merges are **additive**`mergeIncomingMessage` / `upsertDirectMessage` never delete or downgrade a richer local row.
- A 1:1 → group upgrade **preserves** the original 1:1 history; the group is a new conversation.
- Edits / deletes are reconciled by `lastModifiedAt` / `editedAt` / `deletedAt`.
---
## Technical implementation
### Server
- WS handlers — `server/src/websocket/handler.ts`: `handleChatMessage` (line 274), `handleTyping` (309); DM forwarding via `forwardPeerMessage` / `forwardRtcMessage`.
- No CQRS, no entities, no migrations: server messaging is broadcast-only.
### Product client
- Chat domain — `toju-app/src/app/domains/chat/`: services, effects, sync rules at `domain/rules/message-sync.rules.ts`.
- Direct-message domain — `toju-app/src/app/domains/direct-message/`: `DirectMessageService`, `PeerDeliveryService` (`application/services/peer-delivery.service.ts`), offline queue.
- Shared kernel — `toju-app/src/app/shared-kernel/chat-events.ts` (`ChatInventoryEvent`, `ChatSyncBatchEvent`, `chat_message`, `edit-message`, `delete-message`, `direct-message-sync`, `direct-message-sync-request`).
- Persistence — Electron CQRS commands for DMs (see [ipc-bridge](./ipc-bridge.md)); `DatabaseService` for server-channel chat.
### Electron
- DM persistence — TypeORM entity (likely `MessageEntity` and a DM-specific row) + CQRS handlers. Backup / restore is part of the Electron data-management surface.
---
## Testing
- TODO: chat domain has zero `*.spec.ts` files at time of writing.
- TODO: no dedicated server-side spec for `handleChatMessage`, `handleTyping`, or `forwardRtcMessage`.
- TODO: confirm specs for `PeerDeliveryService` and `OfflineMessageQueueService`.
- E2E: `e2e/tests/chat/chat-message-features.spec.ts` covers happy-path chat and attachment sync between users.
---
## Performance considerations
- Inventory batch cap: **200 messages per envelope**.
- Inventory backfill cap: **1000 messages per inventory exchange**.
- `chat_message` broadcast is O(N) over connected peers of the server; no fan-out batching.
- DMs incur O(recipients) data-channel writes (or signaling forwards) per send; large group DMs amplify per-message cost linearly.
---
## Security considerations
- **No end-to-end encryption.** P2P traffic over the data channel is DTLS-encrypted by WebRTC; signaling-forwarded fallback is plain WebSocket; either way the local TypeORM database stores plaintext.
- **`applyMutation` does not verify authorship** on incoming `edit-message` / `delete-message` events. TODO above.
- **No server-side rate limiting** on `chat_message`. A non-cooperating client can flood a server's broadcast.
---
## Known issues and limitations
- **No server-side chat history.** Late joiners depend on peers having local history to replay via inventory sync.
- **No spec coverage** for the chat domain.
- **DM authorship is not verified** by `applyMutation`.
- **No DM typing indicator.**
- **`OfflineMessageQueueService` retry policy** is currently driven by `peerConnected$` / `networkRestored$` events only — there is no scheduled retry; a stuck queue requires one of those events to fire. TODO: confirm behavior across reconnects.
---
## Related features
- **[websocket-envelopes](./websocket-envelopes.md)** — owns the wire shape of every envelope here.
- **[attachments](./attachments.md)** — file payloads ride alongside chat events on the data channel.
- **[voice-signaling](./voice-signaling.md)** — establishes the data channel DMs ride on.
- **[ipc-bridge](./ipc-bridge.md)** — exposes the CQRS persistence DMs and server chat use.
- **[access-control](./access-control.md)** — gates write permissions and slowmode.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,180 @@
# Plugin System
> **Area:** plugin-system
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
Plugins extend Toju's renderer with bundled or local ES modules that can publish events into a server, register UI contributions (pages, panels, actions, channel sections, embed renderers), store per-user or per-server data, and exchange messages over P2P. They are described by a typed manifest, gated by an explicit capability grant model, and coordinated across three subdomains: the Electron plugin loader (`electron/plugin-library.ts`), the renderer plugin runtime (`toju-app/src/app/domains/plugins/`), and the server's plugin-support surface (`server/src/routes/plugin-support.ts`). This area documents the contract those three sides share.
## Responsibilities
- Define the canonical plugin manifest shape (`TojuPluginManifest`) and its semantic versioning, dependency, and capability requirements.
- Discover local plugin manifests from disk in Electron and surface them to the renderer.
- Load plugin modules — local file://, http(s)://, or bundled — into the renderer and run their lifecycle hooks.
- Gate every host API call by an explicit capability grant.
- Persist server-scoped plugin requirements and event definitions on the signaling server, broadcasting changes to connected clients.
This area does **not** own:
- The wire format of `plugin_event` envelopes themselves — those live with [websocket-envelopes](./websocket-envelopes.md); this area defines the **validation rules** applied to them.
- IPC plumbing for plugin manifest discovery — that's the [ipc-bridge](./ipc-bridge.md) surface.
- Per-plugin business logic — that lives in the plugin's own code.
## Key concepts
- **Manifest** — `TojuPluginManifest` (`toju-app/src/app/shared-kernel/plugin-system.contracts.ts`). Required: `id`, `title`, `description`, `version`, `apiVersion`, `kind`, `schemaVersion` (fixed `1`), `compatibility.minimumTojuVersion`. Optional: `entrypoint`, `bundle`, `capabilities[]`, `events[]`, `data[]`, `ui`, `settings`, `relationships`, `authors`, `pluginUser`, `scope`, `homepage`, `changelog`, `license`, `readme`, `load.priority`.
- **Capability** — a string ID (e.g. `messages.send`, `events.server.publish`, `ui.pages`, `storage.local`). Plugins declare what they need in `capabilities[]`; the host enforces grants per plugin.
- **Plugin event** — a declared `{ eventName, direction, scope, schema?, maxPayloadBytes? }` tuple. `direction` is `clientToServer | serverRelay | p2pHint`; `scope` is `server | channel | user | plugin`.
- **Capability grant** — an entry in `metoyou_plugin_capability_grants` (localStorage + desktop file) recording user consent for a `(pluginId, capability)` pair.
- **Activation context** — `TojuPluginActivationContext` — what a plugin module receives in its `activate(context)` hook: `pluginId`, `manifest`, `api` (the capability-gated `TojuClientPluginApi`), and a `subscriptions[]` cleanup list.
- **Local plugin** — a folder under `${app.getPath('userData')}/plugins/<id>/` containing `toju-plugin.json` (preferred) or `plugin.json` and resolved relative assets.
---
## Manifest contract
Declared in `toju-app/src/app/shared-kernel/plugin-system.contracts.ts` (the source of truth on the renderer side; the Electron loader treats the manifest as `unknown` until the renderer validates it).
Highlights:
- **`schemaVersion: 1`** — fixed; bump only with a coordinated migration.
- **`apiVersion`** — declares which host API surface the plugin expects.
- **`kind`** — distinguishes plugin types (currently a string union; see file for exact members).
- **`bundle.url`** + optional `bundle.entrypointUrl` — for remote / store-installed plugins.
- **`entrypoint`** — relative path within the local plugin folder; rejected if it escapes `pluginRoot`.
- **`relationships.{requires,optional,conflicts,before,after}`** — `pluginId` + optional `versionRange`. Resolved at activation; missing required dependencies block activation.
- **`events[]`** — registered with the server via `plugin-support` when the plugin is required by a server. The server uses these definitions to validate inbound `plugin_event` envelopes.
- **`data[]`** — `{ key, scope: server|channel|user|plugin, storage: local|serverData, schema? }`.
- **`load.priority`** — `bootstrap | high | default | low`; controls ordering when several plugins are activated together.
- **`pluginUser`** — synthetic user identity for messages a plugin posts on its own behalf.
---
## Discovery & loading
### Local discovery (Electron main)
`electron/plugin-library.ts`:
- Scans `${app.getPath('userData')}/plugins/` **one level deep** for plugin folders.
- For each folder, reads `toju-plugin.json` (preferred) or `plugin.json` as raw JSON. No schema validation at this layer.
- Resolves relative paths (`entrypoint`, `readme`) against the plugin root, rejecting `..`, absolute paths, or anything that escapes the root via `isPathInside()` realpath check.
- Returns `LocalPluginDiscoveryResult { plugins, errors, pluginsPath }` where each `plugins[i]` is a `LocalPluginManifestDescriptor` carrying the raw manifest, manifest path, plugin root, plugin-root `file://` URL, optional entrypoint and readme paths, and a `discoveredAt` timestamp.
Exposed to the renderer through the [ipc-bridge](./ipc-bridge.md) as `listLocalPluginManifests` and `getLocalPluginsPath`.
### Renderer runtime
`toju-app/src/app/domains/plugins/`:
- **`PluginHostService`** — orchestrates lifecycle: `discoverLocalPlugins`, `registerLocalManifest`, `activate`, `deactivate`, `reload`, `loadPluginModule`.
- **`PluginClientApiService`** — constructs the capability-gated facade `TojuClientPluginApi` per plugin. Subsystems: `channels`, `events`, `messages`, `messageBus`, `p2p`, `profile`, `users`, `roles`, `server`, `attachments`, `media`, `storage`, `serverData`, `clientData`, `ui`, `logger`, `context`.
- **`PluginCapabilityService`** — `grant(pluginId, capability)`, `revoke()`, `grantAll(manifest)`, `assert(pluginId, capability)`. Storage in `metoyou_plugin_capability_grants` (localStorage + desktop file).
- **`PluginMessageBusService`** — plugin-scoped pub/sub with topic, optional channel/peer targeting, optional message replay.
- **`PluginStorageService`** — split storage paths for `local` and `serverData` scopes.
- **`PluginUiRegistryService`** — central registry of UI contributions consumed by `plugin-render-host`, `plugin-page-host`, `plugin-action-menu`.
- **`PluginRequirementStateService`**, **`PluginDesktopStateService`** — state slices.
### Module loading
- Entrypoint URL is `file://` for local plugins, `http(s)://` for remote, or the `bundle.url` for bundled.
- Bytes are fetched, wrapped in a `Blob`-backed object URL, then imported via dynamic `import()` so devtools and stack traces resolve.
- `GuardedPluginMutationObserver` wraps observer callbacks to catch plugin errors and break infinite redispatch loops.
### Lifecycle states
From `plugin-runtime.models.ts`: `discovered → validated → blocked | loading → ready → loaded → failed | unloading → unloaded → disabled`.
### Module contract
```ts
export interface TojuClientPluginModule {
activate?(context: TojuPluginActivationContext): void | Promise<void>;
deactivate?(context: TojuPluginActivationContext): void | Promise<void>;
ready?(context: TojuPluginActivationContext): void | Promise<void>;
onServerRequirementsChanged?(context, snapshot): void | Promise<void>;
onPluginDataChanged?(context, event): void | Promise<void>;
}
```
---
## Server surface (`server/src/routes/plugin-support.ts`)
Each endpoint scoped to `:serverId`. Permission `manageServer` enforced for mutations via `server-permissions.service.ts`.
- `GET /:serverId/plugins``PluginRequirementsSnapshot` — full set of required/optional plugins + event definitions for the server.
- `PUT /:serverId/plugins/:pluginId/requirement` — upsert a requirement: `status: required | optional | recommended | blocked | incompatible`, `installUrl?`, `sourceUrl?`, `manifest?`, `versionRange?`.
- `DELETE /:serverId/plugins/:pluginId/requirement` — remove.
- `PUT /:serverId/plugins/:pluginId/events/:eventName` — register or update an event definition (`direction`, `scope`, `schema?`, `maxPayloadBytes?`).
- `DELETE /:serverId/plugins/:pluginId/events/:eventName` — delete.
- `GET|PUT|DELETE /:serverId/plugins/:pluginId/data/:key`**disabled** on the signaling server (returns HTTP 410). Plugin data on the server is intentionally out of scope.
Identifier patterns:
- `pluginId`: `/^[a-z0-9][a-z0-9.-]{1,126}[a-z0-9]$/`
- `eventName`: `/^[a-z][a-z0-9.:-]{1,126}[a-z0-9]$/`
Changes broadcast to connected clients via the [websocket-envelopes](./websocket-envelopes.md) — the matching `PluginRequirementsSnapshot` is also delivered as part of the `join_server` and `view_server` responses.
---
## Plugin event validation
`server/src/services/plugin-support.service.ts` exposes `validatePluginEventEnvelope()`. The `plugin_event` envelope handler (`server/src/websocket/handler.ts`) calls it before broadcasting. Validation checks:
- `eventName` is registered for `pluginId` on `serverId`.
- `direction` permits the source (clientToServer vs p2pHint vs serverRelay).
- `payload` size ≤ `maxPayloadBytes` (default 64 KB).
- If `schema` was declared in the manifest, the payload conforms — TODO: confirm the schema dialect (looks like JSON Schema subset).
## Security considerations
- **Plugins run in the renderer's JS context.** There is no true sandbox: plugins have DOM access, can read/write `localStorage`, and can issue `fetch` requests subject to the renderer's CSP.
- **Capability model is the primary security boundary.** Every method on `TojuClientPluginApi` calls `PluginCapabilityService.assert(pluginId, capability)`. Missing grant → `PluginCapabilityError`.
- **Path traversal** in the local plugin loader is blocked by `isPathInside()` realpath checks (`electron/plugin-library.ts`).
- **Payload bounds** on plugin events: default 64 KB, configurable per event definition.
- **No code signing or integrity verification.** Plugins are trusted to the extent the user granted capabilities. The plugin store flow is documented in `docs-site/docs/plugin-development/`.
- **TODO**: review whether `bundle.url` fetches go through a CSP / allow-list or are unbounded.
## Configuration
- **Local plugins path**: `${app.getPath('userData')}/plugins/` (Electron). Exposed as `getLocalPluginsPath`.
- **Capability grants**: `metoyou_plugin_capability_grants` in localStorage; mirrored to a desktop file via `PluginDesktopStateService`.
- **Server-side persistence**: plugin requirements and event definitions are stored in the server's database; entities and migrations live alongside other server entities (TODO: enumerate the specific entities).
## Testing
- **Electron**: `electron/plugin-library.spec.ts` — covers valid/invalid JSON, path traversal rejection, escaping entrypoints. Uses fixture `TEST_PLUGIN_FIXTURE_DIR`.
- **Renderer**: `plugin-host.service.spec.ts`, `plugin-store.service.spec.ts`, `local-plugin-discovery.service.spec.ts`.
- **Server**: `server/src/websocket/handler-plugin.spec.ts``plugin_event` validation flow.
- **E2E**: `e2e/tests/.../plugin-support-api.spec.ts`, `plugin-manager-ui.spec.ts`, `plugin-api-two-users.spec.ts`.
## Known issues and limitations
- **Server-side plugin data is intentionally disabled** (`410 Gone` on `*/data/:key` routes). Plugins must currently treat `serverData` storage as not yet implemented on the signaling server. TODO: clarify whether this is a permanent boundary or scheduled work.
- **No true sandbox** for plugin execution. The capability model is the only restraint between a plugin and the renderer's globals.
- **Manifest validation is renderer-side.** The Electron loader treats manifests as raw JSON; malformed or hostile manifests are caught when the renderer registers them.
- **No host-side plugin allow-list** beyond per-server requirements — a user can install any local plugin.
## Related features
- **[ipc-bridge](./ipc-bridge.md)** — surfaces `listLocalPluginManifests`, `getLocalPluginsPath`, and the plugin CQRS commands (`SavePluginData`, `DeletePluginData`, `GetPluginData`).
- **[websocket-envelopes](./websocket-envelopes.md)** — defines the `plugin_event` envelope this area validates.
- **[server-directory](./server-directory.md)** — `join_server` / `view_server` responses include `PluginRequirementsSnapshot` for the joined server.
## Documentation for plugin authors
Author-facing docs ship with the desktop app via Docusaurus:
- `docs-site/docs/plugin-development/create-a-plugin.md`
- `docs-site/docs/user-guide/plugins.md`
- `docs-site/docs/developer/llm-plugin-builder-guide.md`
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,196 @@
# Presence
> **Area:** presence
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
Presence in Toju covers everything that signals "who is here, where, and doing what" — connection lifecycle (`join_server`, `leave_server`), availability status (`online / away / busy / offline`), profile metadata propagation, voice-room membership, and the current-game indicator. The signaling server **forwards and deduplicates** presence over WebSocket but never persists it: every restart of the server resets all presence state to nothing, and every reconnect of a client re-derives the world from scratch via a `server_users` snapshot.
Several signals contribute. Status comes from idle detection in the renderer (Electron `powerMonitor` or browser fallback) and from explicit user choices. Voice membership is **client-derived** from observed `voice_state` broadcasts — the server never tracks who is in a voice room. Game activity is scanned in the renderer using Electron-IPC process inspection, resolved via the server's RAWG-backed `/games/match` API, and broadcast directly to peers over the WebRTC data channel — it never touches the signaling server.
## Responsibilities
- Track which users are connected to which server and broadcast joins/leaves with multi-device dedup.
- Carry profile metadata (`displayName`, `description`, `profileUpdatedAt`) so peers can render rich identity without a separate lookup.
- Propagate availability status (`online / away / busy / offline`) as users choose, idle, or wake.
- Surface voice-room membership to peers via the `voice_state` envelope.
- Surface current-game activity to peers via the chat data channel.
This area does **not** own:
- The WebSocket envelope shape — see [websocket-envelopes](./websocket-envelopes.md).
- RTC negotiation, peer connection lifecycle, RNNoise — see [voice-signaling](./voice-signaling.md).
- Server-side account records, credentials, or the `identify` handshake's authentication semantics — see [authentication](./authentication.md).
- Authorization for joining a server (membership / bans / invites) — see [access-control](./access-control.md).
## Key concepts
- **`oderId`** — client-asserted identity. The deduplication key across multiple sockets and devices.
- **`connectionScope`** — opaque string (typically the signal URL). Used together with `oderId` to coexist multi-URL sockets without an eviction loop.
- **Status** — `'online' | 'away' | 'busy' | 'offline'`. `VALID_STATUSES` lives in `server/src/websocket/handler.ts`. Client maps incoming `offline` to a local `disconnected` rendering tag.
- **Manual vs automatic status** — manual user choices override the idle-detector.
- **Voice presence** — derived client-side from `voice_state` broadcasts; the signaling server has no voice-room model.
- **Game activity** — currently-detected game; resolved via `/games/match` and announced to peers over the data channel as a `game-activity` chat event.
- **`ConnectedUser`** — server-side per-connection row (`server/src/websocket/types.ts`); see [authentication](./authentication.md) for the full shape.
---
## Envelopes (consumed and emitted)
Schemas live in [websocket-envelopes](./websocket-envelopes.md). Presence-relevant types:
- `identify` — first envelope a client sends; updates profile metadata. Re-broadcasts `user_joined` per joined server when profile fields change.
- `join_server` / `leave_server` — connection joins/leaves a specific server scope; gated by `authorizeWebSocketJoin` (see [access-control](./access-control.md)).
- `server_users` — full peer roster sent to a connection when it joins a server; the only "snapshot" envelope.
- `user_joined` — broadcast to peers on a server when a new *identity* arrives (i.e. no other connection of the same `oderId` already had this server).
- `user_left` — broadcast to peers when an identity fully releases a server; payload includes `serverIds` listing the servers the user is still in elsewhere.
- `status_update` — availability status change (`online / away / busy / offline`).
- `voice_state` — broadcast to a server when the user enters/leaves voice or toggles mute/deafen. Carries `roomId`, `voiceGateway`, mute/deafen flags. Voice membership is reconstructed from these events client-side.
- `keepalive` — bumps `lastPong` on the server to keep the connection from being reaped.
- `access_denied` — server response when authorization for `join_server` fails.
Game activity events ride the WebRTC **chat data channel** as `game-activity` chat events — not as WebSocket envelopes.
---
## Lifecycle
A connection moves through these stages:
1. **WebSocket connect** — server allocates a `ConnectedUser` row keyed by `connectionId`.
2. **`identify`** — client claims `oderId`, profile metadata, and an optional `connectionScope`. See [authentication](./authentication.md) for the handshake details.
3. **`join_server`** — gated by `authorizeWebSocketJoin`. On success, the server adds the server to `user.serverIds`, sends a private `server_users` snapshot to the joiner, and broadcasts `user_joined` to other peers on that server *only if* this is a new identity for the server (multi-device dedup).
4. **Steady state**`status_update`, `voice_state`, profile-bearing `identify` updates, and chat / RTC envelopes flow. The server bumps `lastPong` on every inbound frame.
5. **`leave_server` / disconnect** — the server removes the server from `user.serverIds`. `user_left` is broadcast to peers *only* once every connection of the same `oderId` has released the server. The payload's `serverIds` field reports which servers the identity is still in, so clients can distinguish "moved tabs" from "fully left."
6. **Dead-connection sweep** — every `PING_INTERVAL_MS = 30 000` the server sweeps; any connection with `lastPong` older than `PONG_TIMEOUT_MS = 45 000` is closed and processed as a disconnect (`server/src/websocket/index.ts`).
---
## Multi-device deduplication
`broadcastToServer` (`server/src/websocket/broadcast.ts`) deduplicates fan-out by `oderId`, so a user logged in on two devices sees each peer event once.
`handleJoinServer` (`handler.ts:155`) only emits `user_joined` when the join is a **new identity membership** — i.e. no other connection of the same `oderId` already held the server. Renaming a tab or opening a second window does not produce spurious join notifications.
Symmetrically, `handleLeaveServer` only emits `user_left` when no other connection of the same `oderId` still holds the server. The `serverIds` field on the payload lets clients see "the identity is still in these other servers" rather than treating a tab close as a full logout.
`connectionScope` keeps this stable across multi-signal-URL deployments: an identity that opens connections to two signal URLs is still one identity from the broadcast layer's perspective, but the per-scope stale-eviction does not loop.
---
## Status
Two writers update status:
- **Manual** — the user picks `online / away / busy / offline` from the UI. The chosen value is sent as a `status_update` envelope and persists locally.
- **Automatic** — `UserStatusService` (`toju-app/src/app/core/services/user-status.service.ts`) listens to Electron `powerMonitor` events (suspend, resume, lock, unlock) when running on desktop, or falls back to a 15-minute idle timer in the browser. It emits `status_update` via `RealtimeSessionFacade.sendRawMessage`.
Manual overrides automatic for the session — explicit user input prevents the idle detector from overwriting `away` back to `online`.
Server-side, `handleStatusUpdate` (`handler.ts:337`) validates the value against `VALID_STATUSES`, mutates `user.status`, and broadcasts the event to every server the user is in.
---
## Game activity
`GameActivityService` (`toju-app/src/app/domains/game-activity/application/game-activity.service.ts`) is the renderer-side scanner:
- Polls every 560 seconds (default 10 s).
- Asks Electron for active and running process names via the IPC bridge (`getActiveGameCandidate`, `getRunningProcessNames` — see [ipc-bridge](./ipc-bridge.md)).
- Resolves candidates to RAWG metadata via `POST /games/match` on the signaling server.
- Broadcasts the result to peers as a `game-activity` chat event on the WebRTC chat data channel.
The signaling server is **not** in the broadcast path for game activity — it only matches process names to RAWG entries. Once a peer connection exists, the game-activity envelope flows P2P.
---
## Business rules and invariants
- The signaling server **forwards** presence but **never persists** it. Server restart = full reset; clients rederive via `server_users`.
- Presence is **per-connection**; identity is reconstructed at broadcast time by collapsing connections that share `oderId`.
- `user_joined` is emitted **only** on a new-identity membership; `user_left` **only** on full release of a server by an `oderId`.
- `identify` is the canonical channel for profile-metadata updates. Profile-bearing `identify` envelopes rebroadcast `user_joined` only if at least one of `displayName` / `description` / `profileUpdatedAt` actually changed.
- **Voice room membership is never server-tracked.** It is client-derived from `voice_state` broadcasts.
- Manual status overrides automatic status for the session.
- Reconnection resets all presence state; the joiner's first `server_users` snapshot is authoritative for that server.
- Dead connections are reaped after 45 s of silence.
---
## Technical implementation
### Server
- WebSocket envelope handlers — `server/src/websocket/handler.ts`: `handleStatusUpdate` (line 337), `handleIdentify` (112), `handleJoinServer` (155), `handleLeaveServer` (224).
- Broadcast / dedup — `server/src/websocket/broadcast.ts`: `broadcastToServer`, `sendServerUsers`.
- Sweep / heartbeat — `server/src/websocket/index.ts` (`PING_INTERVAL_MS`, `PONG_TIMEOUT_MS`).
- `ConnectedUser` row — `server/src/websocket/types.ts`.
- Game-match HTTP — `server/src/routes/games.ts`, `server/src/services/game-matching.service.ts`.
### Product client
- Status writer — `toju-app/src/app/core/services/user-status.service.ts`.
- Game-activity scanner — `toju-app/src/app/domains/game-activity/application/game-activity.service.ts`.
- Voice presence — `toju-app/src/app/domains/voice-session/` (see [voice-signaling](./voice-signaling.md)).
- Presence sync into NgRx — `toju-app/src/app/store/rooms/room-state-sync.effects.ts`, `room-members-sync.effects.ts`.
- Presence reducers — `toju-app/src/app/store/users/`.
### Electron
- Process inspection IPC — `electron/preload.ts` (`getActiveGameCandidate`, `getRunningProcessNames`). See [ipc-bridge](./ipc-bridge.md).
- `powerMonitor` events — wired in `electron/` and surfaced to renderer via IPC events.
---
## Testing
- `server/src/websocket/handler-status.spec.ts` — status validation and broadcast.
- `toju-app/src/app/store/users/users-status.reducer.spec.ts` — status reducer.
- `toju-app/src/app/store/rooms/rooms-helpers-status.spec.ts` — room-level status aggregation.
- `toju-app/src/app/domains/game-activity/application/game-activity.service.spec.ts` — scanner + RAWG match.
- `toju-app/src/app/infrastructure/realtime/signaling/signaling-message-handler.spec.ts` — presence-relevant handling.
- TODO: no spec for multi-device `user_left` suppression.
- TODO: no spec for `identify`-triggered profile rebroadcast.
- TODO: no spec for pong-timeout reaping.
- TODO: no spec for client `offline → disconnected` rendering mapping.
- TODO: no E2E for cross-device presence dedup.
---
## Security considerations
- The `identify` claim is **not verified** — see [authentication](./authentication.md). Presence trust is inherited from that gap: a connection can claim any `oderId` and be broadcast as that user.
- Game-activity scanning surfaces local process names to the signaling server (via `/games/match`) and to peers (via the data channel). This is privacy-sensitive — there is no per-user opt-out documented today; if a user does not want process names leaving their machine, they need a `closeToTraySetting`-style toggle. TODO: confirm the current opt-out path.
- Status is self-asserted. `busy` does not enforce anything; it is purely a presence hint.
---
## Performance considerations
- `broadcastToServer` is O(N) per envelope, where N is the number of connections subscribed to the server. There is no fan-out batching.
- The 30 s ping cadence keeps idle connections cheap; the 45 s reaper keeps `connectedUsers` from leaking on TCP half-closes.
- `GameActivityService` defaults to a 10 s poll; user-configurable, clamped 560 s.
- `identify` rebroadcast is O(serversJoinedByThisConnection); negligible in practice.
---
## Known issues and limitations
- No server-side voice-room membership model means the only way to enumerate a room's occupants is to replay `voice_state` events client-side.
- Status idle detection in the browser falls back to a coarse 15-minute timer (no platform idle API).
- Game-activity opt-out and granularity (per-game blocklist) are not centrally documented; the `gameIgnoreList` setting lives in `electron/desktop-settings.ts` but is undocumented in renderer UX terms — TODO.
---
## Related features
- **[websocket-envelopes](./websocket-envelopes.md)** — owns the wire shape of every envelope this area uses.
- **[voice-signaling](./voice-signaling.md)** — consumes the `voice_state` broadcasts to drive RTC mesh.
- **[authentication](./authentication.md)** — owns the `identify` handshake and the heartbeat / reaping policy.
- **[access-control](./access-control.md)** — gates `join_server`, which precedes any presence broadcast for that server.
- **[ipc-bridge](./ipc-bridge.md)** — exposes `powerMonitor` events and process-list inspection used by status and game-activity.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,174 @@
# Server Directory
> **Area:** server-directory
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
The Server Directory is the public REST surface that lists joinable Toju chat servers, manages invites and join requests, gates membership (passwords, bans, ownership), and exposes moderation actions (kick / ban / unban). It is the only feature where the signaling server holds non-ephemeral, multi-user state: the persistent catalog of servers, their access rules, their memberships, and their pending join requests. The renderer's `server-directory` domain consumes this surface to render the "find a server" experience and to drive the join flow that eventually opens a WebSocket (see [websocket-envelopes](./websocket-envelopes.md)).
## Responsibilities
- Persist the catalog of servers, their access policy (public/private, password, max users), and ownership.
- Mint invites and accept invite redemptions.
- Track join requests on private servers and route owner decisions back to the requester.
- Track memberships and bans; enforce them on join attempts.
- Provide moderation primitives: kick, ban, unban — gated by role/owner permissions.
- Emit user-targeted notifications when a join request changes state.
This area does **not** own:
- Realtime presence, chat, or voice — those flow over the WebSocket once a user has joined (see [websocket-envelopes](./websocket-envelopes.md), [voice-signaling](./voice-signaling.md)).
- Per-channel permissions logic (lives in `server/src/services/server-permissions.service.ts` and is consumed by this area, but is reused beyond it).
## Key concepts
- **Server** — a joinable chat server. Persisted as `ServerEntity` (`servers` table).
- **Public / private** — `isPrivate` flag. Public servers appear in directory listings; private servers do not.
- **Invite** — an opaque token (`ServerInviteEntity`) that grants short-lived access to a specific server. Expires after `SERVER_INVITE_EXPIRY_MS` (10 days).
- **Join request** — a pending request on a private server (`JoinRequestEntity`), `pending → approved | denied`.
- **Membership** — a `ServerMembershipEntity` row, indexed by `serverId` + `userId`.
- **Ban** — a `ServerBanEntity` row, optionally `expiresAt`. Auto-pruned on the next join attempt for the banned user.
- **Heartbeat** — periodic `POST /:id/heartbeat` from the server owner's client that updates `lastSeen` and `currentUsers` on the directory entry.
---
## API Endpoints
All HTTP routes; no auth header — caller identity is supplied per-request in the body (`ownerId`, `actorUserId`, `userId`, `requesterUserId`). Identity is whatever the client claims; authorization is enforced against persisted state. Request body validation is **manual / defensive** (no zod or class-validator).
### `server/src/routes/servers.ts`
| Method | Path | Purpose | Auth |
|--------|------|---------|------|
| `GET` | `/` | List public servers. Query: `q`, `tags`, `limit`, `offset`. | None |
| `POST` | `/` | Create a server. Required body: `name`, `ownerId`, `ownerPublicKey`. | Self-asserted |
| `GET` | `/:id` | Fetch a single server. 404 if missing. | None |
| `PUT` | `/:id` | Update a server. Required body: `currentOwnerId`. Permission check via `canManageServerUpdate`. | Owner / role |
| `POST` | `/:id/join` | Join a server. Required body: `userId`. Optional: `password`, `inviteId`. Returns `signalingUrl`. | Self-asserted + access rules |
| `POST` | `/:id/invites` | Create an invite. Required body: `requesterUserId`. Delegates to `createServerInvite`. | Role permission |
| `POST` | `/:id/moderation/kick` | Kick a user. Required: `actorUserId`, `targetUserId`. Permission: `canModerateServerMember`. | Role permission |
| `POST` | `/:id/moderation/ban` | Ban a user. Required: `actorUserId`, `targetUserId`. Optional: `banId`, `reason`, `expiresAt`. | Role permission |
| `POST` | `/:id/moderation/unban` | Unban a user. Required: `actorUserId`. Permission: `manageBans`. | Role permission |
| `POST` | `/:id/leave` | Leave a server. Required body: `userId`. | Self-asserted |
| `POST` | `/:id/heartbeat` | Update `lastSeen` and `currentUsers`. Optional body: `currentUsers`. | None (TODO: confirm) |
| `DELETE` | `/:id` | Delete a server. Required body: `ownerId` (must match `server.ownerId`). | Owner |
| `GET` | `/:id/requests` | List pending join requests. Query: `ownerId`. | Owner |
### `server/src/routes/invites.ts`
- `GET /invites/:id` (API) — fetch invite metadata; `404` for expired or unknown invite.
- `GET /invites/:id` (page router) — server-rendered HTML preview of the invite (server info, owner, expiry); renders an offline state when the server is unreachable.
### `server/src/routes/join-requests.ts`
- `PUT /requests/:id` — update join-request status. Body: `ownerId`, `status`. Permission: `manageServer`. On success, calls `notifyUser` (WebSocket fan-out, see below).
### Standard error codes
`SERVER_NOT_FOUND`, `MISSING_USER`, `NOT_AUTHORIZED`, `BANNED`, `PASSWORD_REQUIRED`, `INVITE_EXPIRED`, plus 400 for missing required fields.
---
## CQRS handlers
`server/src/cqrs/` backs every mutation; routes are thin adapters around CQRS dispatch.
**Queries** (`server/src/cqrs/queries/handlers/`):
- `getAllPublicServers` — filtered by `isPrivate = 0`, loads relations.
- `getServerById`
- `getJoinRequestById`
- `getPendingRequestsForServer`
**Commands** (`server/src/cqrs/commands/handlers/`):
- `upsertServer` — also calls `replaceServerRelations` to sync `tags`, `channels`, `roles`, `roleAssignments`, `channelPermissions` atomically.
- `deleteServer`
- `createJoinRequest`
- `updateJoinRequestStatus` — emits a `notifyUser` event so the requesting user's client learns the outcome over WebSocket.
All handlers run inside TypeORM transactions where multi-table changes are involved.
---
## Persistence
### Entities (`server/src/entities/`)
- `ServerEntity` (table `servers`) — `id`, `name`, `description`, `ownerId`, `ownerPublicKey`, `passwordHash`, `isPrivate`, `maxUsers`, `currentUsers`, `icon`, `iconUpdatedAt`, `slowModeInterval`, `createdAt`, `lastSeen`.
- `ServerInviteEntity` (`server_invites`) — `id`, `serverId` (indexed), `createdBy`, `createdByDisplayName`, `createdAt`, `expiresAt` (indexed).
- `JoinRequestEntity` (`join_requests`) — `id`, `serverId` (indexed), `userId`, `userPublicKey`, `displayName`, `status` (default `pending`), `createdAt`.
- `ServerMembershipEntity` (`server_memberships`) — `id`, `serverId` (indexed), `userId` (indexed), `joinedAt`, `lastAccessAt`.
- `ServerBanEntity` (`server_bans`) — `id`, `serverId` (indexed), `userId` (indexed), `bannedBy`, `displayName`, `reason`, `expiresAt` (nullable), `createdAt`.
Related (referenced by `replaceServerRelations`): `ServerChannelEntity`, `ServerRoleEntity`, `ServerUserRoleEntity`, `ServerTagEntity`, `ServerChannelPermissionEntity`.
### Migrations (`server/src/migrations/`)
- `1000000000000-InitialSchema.ts``servers`, `users`.
- `1000000000001-ServerAccessControl.ts` — adds `passwordHash` to `servers`; creates `server_memberships`, `server_invites`, `server_bans` with indices.
- `1000000000002-ServerChannels.ts``server_channels`.
- `1000000000005-ServerRoleAccessControl.ts` — role/permission tables.
- TODO: locate the migration that created `join_requests` (not obvious from filenames; likely folded into an earlier migration).
---
## Renderer side
`toju-app/src/app/domains/server-directory/`:
- **API client**: `infrastructure/services/server-directory-api.service.ts``ServerDirectoryApiService` exposes `searchServers`, `getServers`, `getServer`, `findServerAcrossActiveEndpoints`, `registerServer`, `updateServer`, `requestJoin`, `createInvite`, `getInvite`, `kickServerMember`, `banServerMember`, `unbanServerMember`, `notifyLeave`, `sendHeartbeat`. Defensive coercion (`getNumberValue` / `getStringValue` / `getBooleanValue`) is used instead of schema validation.
- **State**: signal-based via `ServerEndpointStateService` (servers, active server) — not NgRx for this slice.
- **Facade**: `application/services/server-directory.service.ts` plus `application/facades/`.
- **Multi-endpoint awareness**: Toju supports several federated signaling endpoints; `findServerAcrossActiveEndpoints` queries each and merges results.
---
## Business rules
- **Public-only listing**: `GET /` only returns servers with `isPrivate = 0`. Private servers must be reached by ID + invite.
- **Owner immutability**: only `currentOwnerId` matching `server.ownerId` may update; only `ownerId` matching `server.ownerId` may delete.
- **Join order of checks** (on `POST /:id/join`): existence → ban check (auto-prune expired bans) → password check (if `passwordHash`) → invite check (if private and no invite) → membership upsert → return `signalingUrl`.
- **Invite expiry**: 10 days (`SERVER_INVITE_EXPIRY_MS = 10 * 24 * 60 * 60 * 1000`). Expired invites are pruned on access via `pruneExpiredServerAccessArtifacts()`.
- **Ban expiry**: optional `expiresAt`; auto-deleted on next join attempt for that user.
- **Join request notifications**: on `PUT /requests/:id`, after CQRS dispatch, `notifyUser` pushes the new status over WebSocket to any open connection for `userPublicKey` / `userId`.
## Security considerations
- **No authentication header.** All identity is self-asserted in the request body. Authorization is enforced by checking the claimed identity against persisted role/owner state.
- **Password storage**: `passwordHash` only; never the cleartext. TODO: confirm the hashing algorithm (likely bcrypt / scrypt — verify in `server/src/services/`).
- **SSRF**: routes in this area do not fetch user-supplied URLs, so the SSRF guard does not apply here (it applies to link-metadata, klipy, proxy).
- **No rate limiting** on directory or moderation routes — TODO: add brute-force protection on `POST /:id/join` for password attempts.
- **No CSRF** (REST + JSON body, no cookies in scope), but spam protection on `POST /` (server creation) is also TODO.
## Configuration
- `SERVER_INVITE_EXPIRY_MS` — currently hardcoded at 10 days. Not exposed via `data/variables.json`.
- Per-server `maxUsers`, `slowModeInterval`, `isPrivate`, `passwordHash` are operator-configurable via `PUT /:id`.
## Testing
- **Server-side**: no direct route specs for `servers.ts`, `invites.ts`, `join-requests.ts`. WebSocket-side handlers (`handler-status.spec.ts`, `handler-plugin.spec.ts`) cover adjacent concerns.
- **Renderer-side**: `application/services/server-endpoint-state.service.spec.ts`.
- **E2E**: TODO — verify whether the Playwright suite covers join / invite / moderation end-to-end.
- **Gap**: routes that mutate persistent state and accept self-asserted identity should ideally have integration tests against a real DB.
## Known issues and limitations
- **OpenAPI coverage is incomplete.** `server/src/routes/openapi-docs.ts` currently documents plugin-support endpoints only; server-directory endpoints are not listed.
- **No structured request validation library.** Inline manual checks are error-prone; consider zod once the team is ready.
- **No rate limiting / spam protection** on server creation or join attempts.
- **`join_requests` migration is undocumented** (file not located by inspection); confirm during the next schema change.
## Related features
- **[websocket-envelopes](./websocket-envelopes.md)** — `join_server` envelope re-uses this area's access rules via `authorizeWebSocketJoin`. `notifyUser` fan-out for join-request decisions is delivered over the same WebSocket.
- **[plugin-system](./plugin-system.md)** — `join_server` responses include the joined server's `PluginRequirementsSnapshot`.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,177 @@
# Voice & WebRTC Signaling
> **Area:** voice-signaling
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
Voice and screen-share in Toju are pure WebRTC mesh: peers establish RTCPeerConnections directly, while the signaling server only forwards SDP and ICE messages. This area covers the end-to-end flow — envelope routing, peer election, RTCPeerConnection lifecycle, RNNoise denoising, and the relationships between the three product-client domains involved: `voice-session`, `voice-connection`, and `direct-call`. Screen-share rides on the same peer connection; its UI orchestration is its own domain but the signaling path is shared.
## Responsibilities
- Negotiate WebRTC sessions between peers using `offer` / `answer` / `ice_candidate` envelopes forwarded by the signaling server.
- Elect an initiator deterministically when multiple peers arrive simultaneously, with a non-initiator fallback timer.
- Maintain the local audio pipeline: mic capture → optional RNNoise denoising → RTCPeerConnection sender.
- Track per-peer playback gain, mute, deafen, and speaking-activity state on the receive side.
- Mirror voice presence (`voice_state`) and direct-call signalling (`direct-call`) to other peers via the WebSocket.
This area does **not** own:
- The WebSocket envelope shape (see [websocket-envelopes](./websocket-envelopes.md)).
- Screen-share UI orchestration (its own domain at `toju-app/src/app/domains/screen-share/`); only the peer connection plumbing is shared.
- Persistent user settings beyond `voiceSettingsStorage` (audio device IDs, volumes, bitrate, latency profile, noise-reduction toggle, persisted to localStorage).
## Key concepts
- **Mesh** — every participant holds an `RTCPeerConnection` per other participant. No SFU / MCU.
- **Voice session** — high-level "user is currently in voice room X" state. Owned by `voice-session` domain.
- **Voice connection** — low-level transport/peer concerns: speaking detection, per-peer gain, mute / deafen state. Owned by `voice-connection` domain.
- **Direct call** — 1:1 voice/video call with an optional group-upgrade path. Owned by `direct-call` domain.
- **Initiator** — the peer responsible for sending the first `offer`. Elected first-peer-wins; non-initiators wait `NON_INITIATOR_GIVE_UP_MS` (≈5 s) before generating their own offer.
- **Data channel** — `chat`-labelled data channel established alongside each peer connection for P2P chat fallback and direct-message delivery.
- **Noise suppressor worklet** — RNNoise WASM running in an `AudioWorkletNode` (`NoiseSuppressorWorklet`), loaded from `rnnoise-worklet.js` at the app root.
---
## Signaling envelopes (consumed)
Defined in [websocket-envelopes](./websocket-envelopes.md). Voice-relevant types:
- `offer`, `answer`, `ice_candidate` — forwarded by the server to `targetUserId` without inspection.
- `direct-call` — forwarded; payload carries call-scoped events (ring, participant join/leave, call end).
- `voice_state` — broadcast to a server. Payload includes `roomId`, `voiceGateway`, mute/deafen flags.
- `server_users` — full peer roster on join; seeds the initial offer fan-out.
- `user_joined` — schedules a fallback offer after a grace delay (`USER_JOINED_FALLBACK_OFFER_DELAY_MS`, ≈1 s).
- `user_left` — peer teardown, with special handling that preserves peers still under an active voice session.
- `connected` / `access_denied` — connection lifecycle (server bootstrap and authorization).
The server is **purely signaling**: it does not track which `oderId` is in which voice room. Voice membership is derived client-side from the `voice_state` broadcasts observed on the server.
---
## Session establishment flow
A new participant joining a voice room produces this exchange (initiator perspective; symmetrical when both arrive at once):
1. Local user clicks "Join voice" → `VoiceSessionFacade.startSession()` populates the session model and asks `voice-connection` to ready peer transport.
2. Server broadcasts `user_joined` to existing peers.
3. Each existing peer evaluates: am I the elected initiator for the (me, new-peer) pair? If yes, the peer-connection manager calls `doCreateAndSendOffer()`.
4. Initiator constructs `new RTCPeerConnection({ iceServers })` (`infrastructure/realtime/peer-connection-manager/.../create-peer-connection.ts`), adds local tracks, creates the data channel `chat`, generates an SDP offer, and sends it via the signaling transport.
5. Responder receives `offer``doHandleOffer()` sets remote description, generates SDP answer, sends `answer`.
6. Initiator receives `answer``doHandleAnswer()` sets remote description.
7. Both sides emit `ice_candidate` as they gather candidates via `onicecandidate`.
8. `iceConnectionState` reaches `connected` / `completed` → media flows.
9. Either side may open the `chat` data channel for P2P text payloads (direct messages, etc.).
If the elected initiator never sends an offer within `NON_INITIATOR_GIVE_UP_MS`, the non-initiator promotes itself and initiates instead — preserves liveness across asymmetric drop-outs.
`user_left` is treated carefully: the `signaling-message-handler.spec.ts` covers the case where a peer is still required by an active voice session and must not be torn down, even if other parts of the system think the peer has disconnected.
---
## Domain responsibilities
### `voice-session` (`toju-app/src/app/domains/voice-session/`)
- `VoiceSessionFacade` (`application/facades/voice-session.facade.ts`) — owns the active session metadata (`serverId`, `roomId`, `participantIds`); drives a `showFloatingControls` signal when the user navigates away from the room.
- `VoiceWorkspaceService` (`application/services/voice-workspace.service.ts`) — UI state for the workspace (hidden / expanded / minimized), focused stream ID, mini-window position.
- `voiceSettingsStorage` (`infrastructure/util/voice-settings-storage.util.ts`) — localStorage persistence: input/output device IDs, output volume (0100), bitrate (32256 kbps), latency profile (`low | balanced | high`), noise-reduction toggle.
- Joining a new voice target first calls `endSession()` so transitions cannot leak peer connections.
### `voice-connection` (`toju-app/src/app/domains/voice-connection/`)
Bridges the application layer to the low-level WebRTC infrastructure under `toju-app/src/app/infrastructure/realtime/`.
- **`VoiceActivityService`** — RMS-based speaking detection via `AnalyserNode` (fftSize 256, RMS ≥ 0.015, 8-frame grace period).
- **`VoicePlaybackService`** — per-peer `GainNode` chains (0200% range), localStorage-persisted; deafen sets all gains to 0.
- **`VoiceConnectionFacade`** — exposes signals like `isVoiceConnected`, `isMuted`; methods like `toggleMute()`, `toggleNoiseReduction()`, `setOutputVolume()`.
Per the domain README, voice-connection does **not** own RTCPeerConnection construction or signaling — those live in `infrastructure/realtime/peer-connection-manager`.
### `direct-call` (`toju-app/src/app/domains/direct-call/`)
- Initiator flow (`DirectCallService.startCall()`): create/reuse the 1:1 DM, start a call-scoped voice session, send a `direct-call` "ring" envelope via `PeerDeliveryService`.
- Recipient flow: store incoming session, ring `assets/audio/call.wav` (unless DND), show in-app modal + desktop notification.
- Group upgrade: adding a third participant spawns a new group conversation; the active call swaps its chat panel to the new conversation but original DM history is preserved.
- Invariant: incoming `direct-call` events are ignored unless the local user is in `participantIds`.
### Screen share (`toju-app/src/app/domains/screen-share/`)
- Adds dedicated `MediaStreamTrack` senders to the existing peer connection (does not open a new one).
- Request / response model: a receiver sends `screen-share-request`; the sender attaches the share track; `screen-share-stop` tears it down.
- Quality presets: `low` / `balanced` / `high` (resolution + FPS).
- On Electron, `ScreenShareSourcePickerService` drives a Promise-based picker over `getSources` (see [ipc-bridge](./ipc-bridge.md)).
---
## RNNoise pipeline
Manager: `infrastructure/realtime/media/noise-reduction.manager.ts`.
```
Raw mic → MediaStreamAudioSourceNode → NoiseSuppressorWorklet (AudioWorkletNode) → MediaStreamAudioDestinationNode → clean stream → RTCPeerConnection sender
```
- AudioContext at 48 kHz.
- Worklet loaded from `rnnoise-worklet.js` (built from `@timephy/rnnoise-wasm`, output written to `toju-app/public/`).
- If worklet load fails, the raw stream is passed through unchanged.
- Mute takes priority — when muted, noise reduction is also disabled.
## Technical implementation
- **Envelope types**: see [websocket-envelopes](./websocket-envelopes.md).
- **Signaling adapter (renderer)**: `toju-app/src/app/infrastructure/realtime/signaling/signaling-message-handler.ts` (and `signaling-transport-handler.ts`).
- **Peer-connection manager**: `toju-app/src/app/infrastructure/realtime/peer-connection-manager/``create-peer-connection.ts`, recovery (grace timers, reconnect), data-channel plumbing.
- **Voice settings**: `domains/voice-session/infrastructure/util/voice-settings-storage.util.ts`.
- **Noise reduction**: `infrastructure/realtime/media/noise-reduction.manager.ts`.
- **Worklet asset**: `toju-app/public/rnnoise-worklet.js`.
- **Server side**: signaling only — `server/src/websocket/handler.ts::forwardRtcMessage`.
## Invariants
- The server forwards `offer` / `answer` / `ice_candidate` / `direct-call` envelopes opaquely and never persists media or call state.
- Switching voice rooms always tears down the prior session before starting the new one.
- Mute overrides noise reduction (the manager disables the worklet path when muted).
- Direct-call events with the local user absent from `participantIds` are ignored.
## Testing
- `toju-app/src/app/infrastructure/realtime/signaling/signaling-message-handler.spec.ts``user_left` peer preservation under active voice.
- `toju-app/src/app/infrastructure/realtime/peer-connection-manager/recovery/peer-recovery.spec.ts` — reconnect, grace timers, exponential backoff.
- `toju-app/src/app/infrastructure/realtime/peer-connection-manager/messaging/data-channel.spec.ts`.
- `toju-app/src/app/domains/direct-call/application/services/direct-call.service.spec.ts`.
- E2E: `e2e/tests/voice/multi-signal-eight-user-voice.spec.ts`, `e2e/tests/voice/direct-call.spec.ts` (verify exact filenames in the suite — TODO).
## Security considerations
- WebRTC bypasses the server entirely once connected — peer IPs may be exposed to other participants via ICE candidates. Standard WebRTC privacy caveat.
- Signaling envelopes are forwarded without verifying that source and target share a server — TODO: confirm whether `forwardRtcMessage` enforces membership.
- The data channel `chat` carries P2P text payloads; integrity / authentication of those payloads is owned by the chat/direct-message domains, not by this area.
- RNNoise runs entirely client-side; mic audio never leaves the local AudioContext until it enters the encrypted RTCPeerConnection.
## Performance considerations
- Mesh topology — N×(N-1)/2 peer connections per voice room. Practical ceiling is bound by client CPU and uplink; no documented soft cap.
- Bitrate is client-controlled (32256 kbps); no server-enforced QoS.
- Voice activity detection runs at fftSize 256 with an 8-frame grace period — chosen to minimise CPU while staying responsive to natural speech.
- The signaling server's only cost is envelope forwarding (O(1) per envelope).
## Known issues and limitations
- **No SFU / MCU.** Large rooms scale linearly with participant count on each client.
- **No recording or server-side mixing** for voice or screen.
- **Bitrate is not enforced server-side** — adversarial clients could ignore the suggested range.
- **No documented call-quality telemetry pipeline.**
## Related features
- **[websocket-envelopes](./websocket-envelopes.md)** — owns the wire types this area consumes.
- **[ipc-bridge](./ipc-bridge.md)** — `getSources` and the Linux audio-routing methods are used by screen-share.
- **[plugin-system](./plugin-system.md)** — plugins may participate as observers via `voice_state` broadcasts (subject to capability grants); no direct call control surface today.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

View File

@@ -0,0 +1,164 @@
# WebSocket Envelopes
> **Area:** websocket-envelopes
> **Status:** Active
> **Last updated:** 2026-05-25
## Overview
The WebSocket envelope contract is the realtime wire-format boundary between the signaling server and every connected client. Every realtime concern in Toju — presence, chat broadcasts, typing indicators, voice state, WebRTC offer/answer/ICE forwarding, direct messages, server icon P2P sync, and plugin events — travels as a typed envelope over a single WebSocket connection per client. Drift between the server definition and the client-side mirror is treated as a wire-protocol break.
## Responsibilities
- Define the canonical shape of every realtime message exchanged between `toju-app` (renderer) and `server`.
- Route incoming envelopes to a single dedicated handler on the server.
- Provide a stable identity for the connection (`connectionId`, `oderId`, `connectionScope`) and a lazy authorization model on `join_server`.
- Forward peer-targeted envelopes (WebRTC signaling, direct messages, server-icon peer transfers) without inspecting their payload.
This area does **not** own:
- The HTTP/REST surface (see [server-directory](./server-directory.md)).
- WebRTC media transport or session orchestration (see [voice-signaling](./voice-signaling.md) — the envelope contract is shared, but session lifecycle lives there).
- Persistence (server entities are owned by the server subdomain; the envelope is the contract, not the entity).
## Key concepts
- **Envelope** — a `{ type, ...payload }` message routed by `type`. Defined in `server/src/websocket/types.ts`.
- **ConnectedUser** — server-side state record per WebSocket: `connectionId`, `oderId`, `connectionScope`, `displayName`, `description`, `status`, `serverIds`, `lastPong`.
- **`oderId`** — opaque user identity. Set by the client in `identify`; falls back to a UUID if absent. Multiple connections may share an `oderId` (e.g. multiple devices) — broadcasts are deduplicated per `oderId`.
- **`connectionScope`** — typically the signal URL; disambiguates several connections from the same `oderId`.
- **Handler** — server-side function mapped to one envelope `type` in `server/src/websocket/handler.ts`.
- **Forwarded envelope** — peer-to-peer envelopes the server relays untouched to a specific `targetUserId` (offer / answer / ice_candidate / direct-call / direct-message family / server_icon_peer_*).
---
## Envelope catalogue
Defined on the server in `server/src/websocket/types.ts` and dispatched by the switch in `server/src/websocket/handler.ts`. Groups below match the dispatch shape, not a literal grouping in code.
### Connection & presence
- `identify` — client → server. Profile + `connectionScope`. Required before any other envelope is meaningful.
- `connected` — server → client. Sent automatically on connect: `{ connectionId, serverTime }`.
- `keepalive` — client ↔ server. Resets `lastPong`. See lifecycle below.
- `status_update` — broadcast presence: `online | away | busy | offline`.
- `access_denied` — server → client when `join_server` authorization fails.
### Server membership
- `join_server` — client requests membership for a `serverId`. Authorization checked via `authorizeWebSocketJoin` (`server/src/services/server-access.service.ts`). Response includes `server_users` + `plugin_requirements`.
- `view_server` — client marks a server as viewed (fetch roster + plugin requirements without joining).
- `leave_server` — client leaves; broadcasts `user_left` to remaining members.
- `server_users` — server → client. Full peer roster for a joined server (used as the seed for P2P offers).
- `user_joined` / `user_left` — broadcast presence changes.
### Chat & typing
- `chat_message` — broadcast to a server. Payload: `{ message, senderId, senderName, timestamp }`.
- `typing` — broadcast: `{ isTyping, channelId, oderId, displayName }`.
### Voice presence
- `voice_state` — broadcast user voice state (mute/deafen/room metadata). Pure signaling — the server does not store voice room membership.
### WebRTC signaling (forwarded)
- `offer` / `answer` / `ice_candidate` — forwarded to `targetUserId` via `forwardRtcMessage()`.
- `direct-call` — forwarded; semantic call lifecycle lives in the `direct-call` product-client domain.
### Direct messages (forwarded)
- `direct-message`, `direct-message-status`, `direct-message-mutation`, `direct-message-sync`, `direct-message-sync-request` — forwarded to `targetUserId`.
### Server icon P2P sync
- `server_icon_available` — client announces it has an icon at version `iconUpdatedAt`.
- `server_icon_sync_request` — client asks the server which peers have a newer icon.
- `server_icon_sync_peers` — server → client. Peer list offering newer icons.
- `server_icon_peer_request` / `server_icon_peer_data` — P2P transfer, forwarded.
### Plugins
- `plugin_event` — validated against the plugin's registered event schema (see [plugin-system](./plugin-system.md) and `server/src/services/plugin-support.service.ts`), then broadcast within the server scope. Payload: `{ serverId, pluginId, eventName, payload, sourcePluginUserId, sourceUserId, emittedAt }`.
---
## Connection lifecycle
Implemented in `server/src/websocket/index.ts`.
1. Client opens WebSocket → server generates `connectionId` (UUID), creates the `ConnectedUser` record, sends `{ type: 'connected', connectionId, serverTime }`.
2. Client sends `identify` with `oderId`, `displayName`, `connectionScope`, optional `description` / `profileUpdatedAt`. Server normalizes and stores.
3. Client sends `join_server` (or `view_server`) per server they care about. Each `join_server` is authorized independently.
4. Heartbeat: server pings every **30 s** (`PING_INTERVAL_MS`). Any incoming message also refreshes `lastPong`. Connections without a pong for **45 s** (`PONG_TIMEOUT_MS`) are terminated.
5. On close: server emits `user_left` to every server the connection had joined. Broadcasts are **deduplicated by `oderId`**, so multi-device users only generate one departure event per logical identity.
---
## Authentication model
There is no bearer token or signed envelope. Identity is whatever the client claims in `identify`. Authorization is **per-`join_server`**, evaluated by `authorizeWebSocketJoin` against persisted server access rules (private flag, password hash, bans, invite/join-request state). `access_denied` is returned when authorization fails; the connection itself stays open.
---
## Technical implementation
### Server
- **Types**: `server/src/websocket/types.ts``WsMessage` (union over `type`), `ConnectedUser`, `ConnectionScope`.
- **Dispatcher**: `server/src/websocket/handler.ts``handleWebSocketMessage(connectionId, message)`. Single switch (~16 dedicated handler functions plus `forwardRtcMessage`).
- **Lifecycle**: `server/src/websocket/index.ts``ws` server, ping/pong, connection registry, dead-connection reaping.
- **Plugin event validation**: `server/src/services/plugin-support.service.ts` — async `validatePluginEventEnvelope()` (runtime schema check).
### Client (renderer)
- **Shared types**: `toju-app/src/app/shared-kernel/signaling-contracts.ts`**stale**, only declares a generic `SignalingMessage` and an obsolete `SignalingMessageType` enum. Not the active wire-format definition.
- **Active envelope shapes** are defined inline as `IncomingSignalingMessage` in `toju-app/src/app/infrastructure/realtime/signaling/signaling-message-handler.ts`.
- **Constants**: `toju-app/src/app/infrastructure/realtime/realtime.constants.ts` — every envelope `type` string lives here as `SIGNALING_TYPE_*`.
- **Transport**: `toju-app/src/app/infrastructure/realtime/signaling/signaling-transport-handler.ts` — socket lifecycle, sends `identify`, `join_server`, raw envelopes.
- **Coordinator**: `toju-app/src/app/infrastructure/realtime/signaling/server-signaling-coordinator.ts` — maps `serverId` to signal URL (Toju supports multiple federated signaling endpoints).
- **Inbound dispatch**: `signaling-message-handler.ts``handleConnectedSignalingMessage`, `handleServerUsersSignalingMessage`, `handleUserJoinedSignalingMessage`, `handleUserLeftSignalingMessage`, `handleOfferSignalingMessage`, `handleAnswerSignalingMessage`, `handleIceCandidateSignalingMessage`, `handleAccessDeniedSignalingMessage`. Domain envelopes (chat/typing/direct-message/etc.) are consumed in the respective product-client domains, not in this central adapter — TODO: enumerate exact subscription points.
### Versioning
No `version` field on envelopes. No `Accept-Version` header. Drift between server and client is enforced only by code review (per `server/CONTEXT.md` invariants).
---
## Testing
- `server/src/websocket/handler-status.spec.ts``status_update` broadcast and profile metadata in `user_joined` / `server_users`.
- `server/src/websocket/handler-plugin.spec.ts``plugin_event` validation and broadcast.
- `toju-app/src/app/infrastructure/realtime/signaling/signaling-message-handler.spec.ts` — inbound handler unit tests (notably `user_left` preserving peers under voice).
- **TODO**: no round-trip envelope-shape test between server `WsMessage` and client `IncomingSignalingMessage`. Drift can only be caught by E2E or manual review today.
## Security considerations
- No transport-level auth — identity is self-asserted via `identify`. The server trusts `oderId` for routing but checks authorization on every `join_server`.
- WebRTC signaling envelopes (`offer` / `answer` / `ice_candidate`) are forwarded **without inspection**. The server does not verify that the sender is a member of the same server as the target — TODO: confirm whether `forwardRtcMessage` enforces server-membership before forwarding.
- `plugin_event` payloads are bounded by the plugin's declared `maxPayloadBytes` (default 64 KB) and validated against the plugin's declared event schema. See [plugin-system](./plugin-system.md).
- Multi-connection identities: a single `oderId` may have many open sockets. Broadcasts dedupe by `oderId`, but per-connection state (e.g. `voice_state`) does not — TODO: document the cross-connection invariants.
## Performance considerations
- Single WebSocket per client. No fan-out worker; broadcast is in-process via the in-memory connection map.
- Ping cadence 30 s / pong timeout 45 s. Reaping is per-connection on next tick.
- TODO: no documented soft cap on connected users per signaling server.
## Known issues and limitations
- **Stale shared-kernel contract.** `toju-app/src/app/shared-kernel/signaling-contracts.ts` does not enumerate the live envelope set; client code uses `IncomingSignalingMessage` in `signaling-message-handler.ts` instead. Update or replace this file when adjacent work touches the wire format.
- **No envelope versioning.** Any field rename is an immediate break for older clients.
- **TODO — operator concerns**: rate limits, max-message-size, and backpressure are not documented.
## Related features
- **[voice-signaling](./voice-signaling.md)** — consumes `offer` / `answer` / `ice_candidate` / `voice_state` / `direct-call`.
- **[plugin-system](./plugin-system.md)** — defines and validates `plugin_event`.
- **[server-directory](./server-directory.md)** — REST counterpart for server discovery, joining, and moderation; `join_server` envelope authorization reuses the same access rules.
## Changelog
| Date | Change |
|------|--------|
| 2026-05-25 | Initial documentation |

44
docs-site/CONTEXT.md Normal file
View File

@@ -0,0 +1,44 @@
# Application Documentation (docs-site)
Owns the Docusaurus-based application and plugin-author documentation. The build output (`docs-site/build/`) is bundled into the Electron app and served by the Local API server at runtime, so documentation is available offline inside the desktop client.
> **Format reference:**
> - **Vocabulary** — bold term, one-sentence definition, aliases to avoid.
> - **Relationships** — bullets with bold terms and cardinality.
> - **Boundaries / IO** — what this subdomain exposes and consumes.
> - **Invariants** — rules that always hold.
> - **Flagged ambiguities** — terms in dispute with proposed resolutions.
>
> See `agents-docs/AGENTS_CONTEXT.md` for the contract. Update in the same turn a trigger fires (see `agents-docs/AGENT_WORKFLOW.md` § CONTEXT.md upkeep).
## Vocabulary
| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **App docs** | End-user-facing documentation for the MetoYou desktop client. | "manual" |
| **Plugin docs** | Developer-facing reference for the plugin runtime — manifest format, lifecycle hooks, host APIs. Authoritative source for the plugin contract surface. | "API docs" |
| **Local API server** | The Electron in-process HTTP server that mounts `docs-site/build/` so the renderer can browse docs offline. Defined under `electron/api/`. | "embedded server" |
## Relationships
- **Plugin docs** describe contracts implemented in `toju-app/src/app/shared-kernel/plugin-system.contracts.ts` (renderer side) and `electron/plugin-library.ts` (host side) — keep them in lockstep with code changes.
- The **build output** at `docs-site/build/` is a deploy artifact for the **electron** Local API server; `npm run build:all` requires `npm run build:docs` to have run.
- The site is also deployed publicly via `.gitea/workflows/deploy-web-apps.yml` for browsing outside the app.
## Boundaries / IO
- **Exposes:** static Docusaurus bundle at `docs-site/build/`, mounted by Electron's Local API server and also deployed as a public static site.
- **Consumes:** Markdown sources under `docs-site/docs/`, plus any code-derived references (e.g. OpenAPI documents from `electron/api/openapi.ts`).
## Invariants
- Plugin-contract documentation must match the code; if the manifest schema or lifecycle changes, **plugin docs** and `agents-docs/features/<plugin-doc>.md` both update in the same task.
- Build artifacts (`docs-site/build/`) are generated, not committed.
## Flagged ambiguities
- _None recorded yet._
---
*Agent-procedural rules (TDD, lint, build) live in `/AGENTS.md`. This file is the bounded-context domain artefact for the documentation site.*

View File

@@ -19,11 +19,11 @@ Capabilities protect privileged app surfaces. A plugin must declare a capability
| `messages.editOwn` | `messages.edit()` | Edits plugin-owned messages. | | `messages.editOwn` | `messages.edit()` | Edits plugin-owned messages. |
| `messages.deleteOwn` | `messages.delete()` | Deletes plugin-owned messages. | | `messages.deleteOwn` | `messages.delete()` | Deletes plugin-owned messages. |
| `messages.moderate` | `messages.moderateDelete()` | Moderation delete path. | | `messages.moderate` | `messages.moderateDelete()` | Moderation delete path. |
| `messages.sync` | `messages.sync()` | Syncs message arrays into client state. | | `messages.sync` | `messages.sync()`, `messages.import()`, `attachments.import()` | Syncs message arrays, imports historical messages locally, or imports files for those messages. |
| `channels.read` | `channels.list()`, `channels.select()` | Reads and selects channels. | | `channels.read` | `channels.list()`, `channels.select()` | Reads and selects channels. |
| `channels.manage` | `channels.addAudioChannel()`, `channels.addVideoChannel()`, `channels.remove()`, `channels.rename()` | Mutates channel or channel-section state. | | `channels.manage` | `channels.addTextChannel()`, `channels.addAudioChannel()`, `channels.addVideoChannel()`, `channels.remove()`, `channels.rename()` | Mutates channel or channel-section state. |
| `server.read` | `server.getCurrent()` | Reads active server. | | `server.read` | `server.getCurrent()` | Reads active server. |
| `server.manage` | `server.updatePermissions()`, `server.updateSettings()` | Updates server permissions or settings. | | `server.manage` | `server.updateIcon()`, `server.updatePermissions()`, `server.updateSettings()` | Updates server icon, permissions, or settings. `server.updateIcon()` resolves when the local icon update has been persisted or rejects if the current user is not allowed to manage the server icon. |
| `p2p.data` | `p2p.connectedPeers()`, `p2p.broadcastData()`, `p2p.sendData()` | Uses plugin peer data paths. | | `p2p.data` | `p2p.connectedPeers()`, `p2p.broadcastData()`, `p2p.sendData()` | Uses plugin peer data paths. |
| `p2p.media` | Reserved peer media features. | Included for media-facing plugins. | | `p2p.media` | Reserved peer media features. | Included for media-facing plugins. |
| `media.playAudio` | `media.playAudioClip()` | Plays an audio URL locally. | | `media.playAudio` | `media.playAudioClip()` | Plays an audio URL locally. |

50
e2e/CONTEXT.md Normal file
View File

@@ -0,0 +1,50 @@
# End-to-End Suite (e2e)
Owns Playwright-based end-to-end verification of the desktop product. Tests boot the real Electron application against the real signaling server and exercise user-visible flows across chat, voice, screen-share, settings, plugins, and auth.
> **Format reference:**
> - **Vocabulary** — bold term, one-sentence definition, aliases to avoid.
> - **Relationships** — bullets with bold terms and cardinality.
> - **Boundaries / IO** — what this subdomain exposes and consumes.
> - **Invariants** — rules that always hold.
> - **Flagged ambiguities** — terms in dispute with proposed resolutions.
>
> See `agents-docs/AGENTS_CONTEXT.md` for the contract. Update in the same turn a trigger fires (see `agents-docs/AGENT_WORKFLOW.md` § CONTEXT.md upkeep).
## Vocabulary
| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **Feature area** | A top-level folder under `tests/` (`auth/`, `chat/`, `voice/`, `screen-share/`, `settings/`, `plugins/`) corresponding to a slice of user-visible behavior. | "category", "section" |
| **Page object** | A test-side abstraction over a screen or panel that exposes user-intent methods rather than raw selectors. | "page model" |
| **Fixture** | A Playwright `test.extend(...)` setup that prepares one or more user/app instances before a test runs. | "helper" |
| **Pair test** | An E2E test that boots two Electron instances simultaneously to verify P2P flows (calls, screen-share, transfers). | "multi-client test" |
## Relationships
- A **Feature area** owns one or more `*.spec.ts` files plus its own **Page objects** and **Fixtures**.
- A **Pair test** depends on the **server** subdomain being reachable — both clients connect to the same signaling server.
- **Page objects** depend only on the rendered DOM produced by **toju-app**; if a selector changes, only the page object should need updating.
- The suite as a whole depends on **electron** (built via `npm run build:electron`) and a usable **server** (`npm run server:dev` or `npm run dev`).
## Boundaries / IO
- **Exposes:** test results (HTML report at `test-results/html-report`, JUnit/JSON output on CI). No production surface.
- **Consumes:**
- The built product (toju-app + electron) — typically launched via Playwright's Electron support.
- The signaling server (started before the suite runs).
- System resources: audio devices for voice tests, screen-capture for screen-share tests. The `.agents/skills/playwright-e2e/SKILL.md` documents how the suite handles the multi-client setup.
## Invariants
- Tests interact only through **Page objects** and **Fixtures** — no raw `page.click('.css-class-name')` scattered across specs.
- Tests must clean up state between runs — a flaky run that leaves cruft in the local database or signaling server is a bug, not an environment issue.
- The suite must run headless on CI (`npm run test:e2e`); the `ui` and `debug` variants exist for local development only.
## Flagged ambiguities
- _None recorded yet — add entries when a test concept (e.g. "pair test" vs "multi-client test") resists clean definition._
---
*Agent-procedural rules (TDD, lint) live in `/AGENTS.md`. Practical patterns for writing Playwright tests on this project live in `.agents/skills/playwright-e2e/SKILL.md`. This file is the bounded-context domain artefact for the E2E suite.*

59
electron/CONTEXT.md Normal file
View File

@@ -0,0 +1,59 @@
# Desktop Shell (electron)
Owns the desktop runtime: the Electron main process, the preload bridge that exposes `window.api` to the renderer, IPC handlers, the local TypeORM + sql.js database, the plugin loader, OS-integration adapters (window controls, idle detection, game detection, audio), update flow, and the Local API server that hosts the Docusaurus bundle inside the app.
> **Format reference:**
> - **Vocabulary** — bold term, one-sentence definition, aliases to avoid.
> - **Relationships** — bullets with bold terms and cardinality.
> - **Boundaries / IO** — what this subdomain exposes and consumes.
> - **Invariants** — rules that always hold.
> - **Flagged ambiguities** — terms in dispute with proposed resolutions.
>
> See `agents-docs/AGENTS_CONTEXT.md` for the contract. Update in the same turn a trigger fires (see `agents-docs/AGENT_WORKFLOW.md` § CONTEXT.md upkeep).
## Vocabulary
| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **Preload bridge** | `electron/preload.ts` — the only surface that the renderer can call into Node through; exposes `window.api.*` after `contextBridge.exposeInMainWorld`. | "preloader" |
| **IPC handler** | A `main`-process function registered against an IPC channel name; lives under `electron/ipc/` (system, window-controls) and `electron/cqrs.ts`. | "rpc handler" |
| **CQRS handler** | Command or query handler dispatched through `electron/ipc/cqrs.ts`; pattern shared with `server/src/cqrs/`. | "command processor" |
| **Local API server** | An in-process HTTP server (`electron/api/local-api-server.ts`) that serves the prebuilt Docusaurus docs and OpenAPI views to the renderer over `http://localhost:<port>/`. | "internal API" |
| **Plugin library** | The plugin loader (`electron/plugin-library.ts`) — resolves manifests, validates entry points, and prepares the sandbox the renderer mounts plugins into. | "plugin manager" |
| **Data archive** | The export/import format implemented in `electron/data-archive.ts` for moving a user's local database between installs. | "backup" |
## Relationships
- The **Preload bridge** is the only path between the **Renderer** (toju-app) and **Main**; the renderer cannot import Electron, Node, or TypeORM directly.
- An **IPC channel** maps 1:1 to a method on `window.api.*`. Adding a method on the preload requires registering its handler in `electron/ipc/` or `electron/cqrs.ts`.
- The **Plugin library** loads manifests at startup and on user action; it owns the contract the renderer's *plugins* domain consumes (defined in `toju-app/src/app/shared-kernel/plugin-system.contracts.ts`).
- TypeORM **migrations** in `electron/migrations/` are applied on startup against the per-user SQLite file resolved by `electron/runtime-paths.ts`.
- The **Local API server** serves the Docusaurus bundle built into `docs-site/build/` and the OpenAPI artifacts under `electron/api/openapi.ts`.
## Boundaries / IO
- **Exposes:**
- `window.api.*` surface (preload bridge) — the canonical IPC contract for the renderer.
- IPC channel names registered in `electron/ipc/index.ts`, `electron/ipc/cqrs.ts`, `electron/ipc/system.ts`, `electron/ipc/window-controls.ts`.
- Local API HTTP endpoints (`electron/api/router.ts`) under `http://localhost:<port>/`.
- Plugin host contract (`electron/plugin-library.ts`) — defines what plugin manifests must declare and what the plugin runtime can call back into.
- **Consumes:**
- The renderer (toju-app) via IPC `invoke`/`handle` and event emitters.
- The local SQLite database via `electron/data-source.ts` and entities under `electron/entities/`.
- OS APIs: window controls, idle detection (`electron/idle/`), game detection (`electron/game-detection/`), process list (`electron/process-list.ts`).
- The audio worklet bundle (`toju-app/public/rnnoise-worklet.js` built from `@timephy/rnnoise-wasm`).
## Invariants
- The **Renderer** never has direct access to Node, the filesystem, or the database — every privileged operation goes through an IPC handler.
- Every schema change is accompanied by a **TypeORM migration**; the database is never mutated outside the migration system.
- IPC handler errors are translated to typed error envelopes before crossing back into the renderer — the renderer never sees a raw `Error` from main.
- The **Preload bridge** exposes a frozen, allow-listed set of methods; adding a method requires touching both `preload.ts` and the matching handler.
## Flagged ambiguities
- _None recorded yet — add entries when an IPC channel name or plugin contract term resists clean definition._
---
*Agent-procedural rules (TDD, lint, build) live in `/AGENTS.md`. Cross-context contract details (IPC envelope shapes, plugin manifest schema) belong in `agents-docs/features/`. This file is the bounded-context domain artefact for the desktop shell.*

View File

@@ -7,20 +7,36 @@ import { getCurrentUserScope } from '../../current-user-scope';
export async function handleGetMessages(query: GetMessagesQuery, dataSource: DataSource) { export async function handleGetMessages(query: GetMessagesQuery, dataSource: DataSource) {
const repo = dataSource.getRepository(MessageEntity); const repo = dataSource.getRepository(MessageEntity);
const { roomId, limit = 100, offset = 0 } = query.payload; const { roomId, limit = 100, offset = 0, channelId, beforeTimestamp } = query.payload;
const currentUserId = await getCurrentUserScope(dataSource); const currentUserId = await getCurrentUserScope(dataSource);
if (!currentUserId) { if (!currentUserId) {
return []; return [];
} }
const rows = await repo.find({ const rowsQuery = repo.createQueryBuilder('message')
where: { roomId, ownerUserId: currentUserId }, .where('message.roomId = :roomId', { roomId })
order: { timestamp: 'ASC' }, .andWhere('message.ownerUserId = :currentUserId', { currentUserId })
take: limit, .orderBy('message.timestamp', 'DESC')
skip: offset .take(limit)
}); .skip(offset);
const reactionsByMessageId = await loadMessageReactionsMap(dataSource, rows.map((row) => row.id));
return rows.map((row) => rowToMessage(row, reactionsByMessageId.get(row.id) ?? [])); if (channelId === 'general') {
rowsQuery.andWhere('(message.channelId = :channelId OR message.channelId IS NULL OR message.channelId = :emptyChannelId)', {
channelId,
emptyChannelId: ''
});
} else if (channelId) {
rowsQuery.andWhere('message.channelId = :channelId', { channelId });
}
if (typeof beforeTimestamp === 'number') {
rowsQuery.andWhere('message.timestamp < :beforeTimestamp', { beforeTimestamp });
}
const rows = await rowsQuery.getMany();
const chronologicalRows = [...rows].reverse();
const reactionsByMessageId = await loadMessageReactionsMap(dataSource, chronologicalRows.map((row) => row.id));
return chronologicalRows.map((row) => rowToMessage(row, reactionsByMessageId.get(row.id) ?? []));
} }

View File

@@ -230,7 +230,16 @@ export type Command =
| SaveMetaCommand | SaveMetaCommand
| ClearAllDataCommand; | ClearAllDataCommand;
export interface GetMessagesQuery { type: typeof QueryType.GetMessages; payload: { roomId: string; limit?: number; offset?: number } } export interface GetMessagesQuery {
type: typeof QueryType.GetMessages;
payload: {
roomId: string;
limit?: number;
offset?: number;
channelId?: string;
beforeTimestamp?: number;
};
}
export interface GetMessagesSinceQuery { type: typeof QueryType.GetMessagesSince; payload: { roomId: string; sinceTimestamp: number } } export interface GetMessagesSinceQuery { type: typeof QueryType.GetMessagesSince; payload: { roomId: string; sinceTimestamp: number } }
export interface GetMessageByIdQuery { type: typeof QueryType.GetMessageById; payload: { messageId: string } } export interface GetMessageByIdQuery { type: typeof QueryType.GetMessageById; payload: { messageId: string } }
export interface GetReactionsForMessageQuery { type: typeof QueryType.GetReactionsForMessage; payload: { messageId: string } } export interface GetReactionsForMessageQuery { type: typeof QueryType.GetReactionsForMessage; payload: { messageId: string } }

View File

@@ -41,7 +41,14 @@ const RETRYABLE_SAVE_ERROR_CODES = new Set([
'EBUSY' 'EBUSY'
]); ]);
let saveQueue: Promise<void> = Promise.resolve(); interface PendingSaveWaiter {
reject: (error: unknown) => void;
resolve: () => void;
}
let pendingSaveSnapshot: Buffer | null = null;
let pendingSaveWaiters: PendingSaveWaiter[] = [];
let saveInProgress = false;
function wait(ms: number): Promise<void> { function wait(ms: number): Promise<void> {
return new Promise((resolve) => setTimeout(resolve, ms)); return new Promise((resolve) => setTimeout(resolve, ms));
@@ -146,16 +153,51 @@ async function writeDatabaseSnapshot(snapshot: Buffer): Promise<void> {
} }
} }
function settleSaveWaiters(waiters: PendingSaveWaiter[], error?: unknown): void {
for (const waiter of waiters) {
if (error === undefined) {
waiter.resolve();
} else {
waiter.reject(error);
}
}
}
async function drainDatabaseSaveQueue(): Promise<void> {
if (saveInProgress) {
return;
}
saveInProgress = true;
try {
while (pendingSaveSnapshot) {
const snapshot = pendingSaveSnapshot;
const waiters = pendingSaveWaiters;
pendingSaveSnapshot = null;
pendingSaveWaiters = [];
try {
await writeDatabaseSnapshot(snapshot);
settleSaveWaiters(waiters);
} catch (error) {
settleSaveWaiters(waiters, error);
}
}
} finally {
saveInProgress = false;
}
}
async function atomicSave(data: Uint8Array): Promise<void> { async function atomicSave(data: Uint8Array): Promise<void> {
const snapshot = Buffer.from(data); const snapshot = Buffer.from(data);
const saveTask = saveQueue.then(
() => writeDatabaseSnapshot(snapshot),
() => writeDatabaseSnapshot(snapshot)
);
saveQueue = saveTask.catch(() => {}); return new Promise<void>((resolve, reject) => {
pendingSaveSnapshot = snapshot;
return saveTask; pendingSaveWaiters.push({ resolve, reject });
void drainDatabaseSaveQueue();
});
} }
export async function initializeDatabase(): Promise<void> { export async function initializeDatabase(): Promise<void> {

View File

@@ -62,6 +62,9 @@ import { listRunningProcessNames } from '../process-list';
import { detectActiveGame } from '../game-detection'; import { detectActiveGame } from '../game-detection';
const DEFAULT_MIME_TYPE = 'application/octet-stream'; const DEFAULT_MIME_TYPE = 'application/octet-stream';
const MAX_ACTIVE_DESKTOP_NOTIFICATIONS = 20;
const activeDesktopNotifications = new Set<Notification>();
const desktopNotificationCleanups = new Map<Notification, () => void>();
const FILE_CLIPBOARD_FORMATS = [ const FILE_CLIPBOARD_FORMATS = [
'x-special/gnome-copied-files', 'x-special/gnome-copied-files',
'text/uri-list', 'text/uri-list',
@@ -399,9 +402,16 @@ export function setupSystemHandlers(): void {
icon: getWindowIconPath(), icon: getWindowIconPath(),
silent: true silent: true
}); });
const cleanup = () => {
notification.on('click', () => { notification.removeListener('click', handleClick);
notification.removeListener('close', cleanup);
notification.removeListener('failed', cleanup);
activeDesktopNotifications.delete(notification);
desktopNotificationCleanups.delete(notification);
};
const handleClick = () => {
if (!mainWindow) { if (!mainWindow) {
cleanup();
return; return;
} }
@@ -414,7 +424,26 @@ export function setupSystemHandlers(): void {
} }
mainWindow.focus(); mainWindow.focus();
}); cleanup();
notification.close();
};
notification.on('click', handleClick);
notification.once('close', cleanup);
notification.once('failed', cleanup);
activeDesktopNotifications.add(notification);
desktopNotificationCleanups.set(notification, cleanup);
while (activeDesktopNotifications.size > MAX_ACTIVE_DESKTOP_NOTIFICATIONS) {
const oldestNotification = activeDesktopNotifications.values().next().value;
if (!oldestNotification) {
break;
}
desktopNotificationCleanups.get(oldestNotification)?.();
oldestNotification.close();
}
notification.show(); notification.show();
} catch { } catch {

57
server/CONTEXT.md Normal file
View File

@@ -0,0 +1,57 @@
# Signaling Server (server)
Owns the shared, internet-reachable runtime: HTTP routes for server directory / invites / join requests / link metadata, WebSocket signaling between clients (P2P session setup, presence, status), CQRS command and query handlers, and the shared TypeORM + sql.js persistence layer that holds signaling state.
> **Format reference:**
> - **Vocabulary** — bold term, one-sentence definition, aliases to avoid.
> - **Relationships** — bullets with bold terms and cardinality.
> - **Boundaries / IO** — what this subdomain exposes and consumes.
> - **Invariants** — rules that always hold.
> - **Flagged ambiguities** — terms in dispute with proposed resolutions.
>
> See `agents-docs/AGENTS_CONTEXT.md` for the contract. Update in the same turn a trigger fires (see `agents-docs/AGENT_WORKFLOW.md` § CONTEXT.md upkeep).
## Vocabulary
| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **Envelope** | The on-the-wire shape of a WebSocket message — `type`, `payload`, and routing metadata, typed in `src/websocket/types.ts` and mirrored in `toju-app/src/app/shared-kernel/signaling-contracts.ts`. | "packet", "frame" |
| **Handler** | A WebSocket message handler registered in `src/websocket/handler.ts`; one per envelope type. | "listener" |
| **CQRS command/query** | A typed request dispatched through `src/cqrs/` — commands mutate state, queries read it; both return a typed result. | "action" (NgRx term) |
| **Server directory** | The catalog of joinable chat servers, exposed by `src/routes/servers.ts` plus invite and join-request routes. | "guild list" |
| **SSRF guard** | The outbound-fetch policy enforced by `src/routes/ssrf-guard.ts` — gates link-metadata and proxy routes that fetch user-supplied URLs. | "proxy filter" |
| **Variables file** | `data/variables.json` — runtime config (klipy key, server host/protocol, release manifest URL, link-preview toggle) normalized on startup. | "config", ".env" (those are separate) |
## Relationships
- A **WebSocket connection** carries many **Envelopes**; each envelope is routed to exactly one **Handler**.
- A **Route** (HTTP) may dispatch zero or more **CQRS commands/queries** to mutate or read persistent state.
- The **Server directory** depends on **Invites** and **Join requests** — listing, accepting, and revoking flows are split across `routes/servers.ts`, `routes/invites.ts`, `routes/join-requests.ts`.
- **Persistence** entities in `src/entities/` are owned by this subdomain and never shipped to the renderer; the wire envelope is the contract instead.
- **SSRF guard** is consumed by `link-metadata`, `proxy`, and `klipy` routes that fetch user-supplied URLs.
## Boundaries / IO
- **Exposes:**
- HTTP routes under `src/routes/`: `health`, `users`, `servers`, `invites`, `join-requests`, `games`, `klipy`, `link-metadata`, `proxy`, `plugin-support`, `openapi-docs`.
- WebSocket envelopes typed in `src/websocket/types.ts` — the realtime contract shared with `toju-app/src/app/shared-kernel/signaling-contracts.ts`.
- OpenAPI document served by `openapi-docs` route.
- **Consumes:**
- The shared TypeORM SQLite database via `src/db/` (entities in `src/entities/`, migrations in `src/migrations/`).
- `data/variables.json` for runtime configuration; `.env` for `PORT` / SSL toggles.
- Optional outbound HTTP for link previews and klipy (all gated by **SSRF guard**).
## Invariants
- Every database schema change ships as a TypeORM **migration**; the live database is never mutated outside the migration system.
- WebSocket **Envelope** types are defined once in `src/websocket/types.ts` and **must** stay structurally compatible with `toju-app/src/app/shared-kernel/signaling-contracts.ts` — drift between the two is a wire-protocol break.
- User-supplied URLs are **never** fetched without going through `ssrf-guard.ts`.
- Secrets (klipy API key, OAuth tokens, signing keys) live in `data/variables.json` or environment variables — never in code, never in logs.
## Flagged ambiguities
- _None recorded yet — add entries when an envelope type or route name resists clean definition._
---
*Agent-procedural rules (TDD, lint, build) live in `/AGENTS.md`. WebSocket envelope schemas and HTTP request/response shapes belong in `agents-docs/features/` when they cross subdomain boundaries. This file is the bounded-context domain artefact for the signaling server.*

Binary file not shown.

View File

@@ -5,6 +5,18 @@
"source": "JuliusBrussee/caveman", "source": "JuliusBrussee/caveman",
"sourceType": "github", "sourceType": "github",
"computedHash": "4d486dd6f9fbb27ce1c51c972c9a5eb25a53236ae05eabf4d076ac1e293f4b7a" "computedHash": "4d486dd6f9fbb27ce1c51c972c9a5eb25a53236ae05eabf4d076ac1e293f4b7a"
},
"document-features": {
"source": "Grade-AI-Labs/Mimas",
"sourceType": "github",
"skillPath": "skills/document-features/SKILL.md",
"computedHash": "e4df8d900aab6698d2ae65c575ca006a05d13ff99a17d3a7273124858d57051d"
},
"find-features": {
"source": "Grade-AI-Labs/Mimas",
"sourceType": "github",
"skillPath": "skills/find-features/SKILL.md",
"computedHash": "2581a85c49fff668c838068c06611723e233890be7e3cdeaab6c7545ecd85e89"
} }
} }
} }

51
toju-app/CONTEXT.md Normal file
View File

@@ -0,0 +1,51 @@
# Product Client (toju-app)
Owns the user-facing Angular 21 desktop chat experience: rendering and orchestrating chat, voice, screen-share, plugin UI, theming, and identity flows on top of the Electron `window.api` bridge and the server WebSocket. Houses every bounded context the end user interacts with, organized DDD-style under `src/app/domains/`.
> **Format reference:**
> - **Vocabulary** — bold term, one-sentence definition, aliases to avoid.
> - **Relationships** — bullets with bold terms and cardinality.
> - **Boundaries / IO** — what this subdomain exposes and consumes.
> - **Invariants** — rules that always hold.
> - **Flagged ambiguities** — terms in dispute with proposed resolutions.
>
> See `agents-docs/AGENTS_CONTEXT.md` for the contract. Update in the same turn a trigger fires (see `agents-docs/AGENT_WORKFLOW.md` § CONTEXT.md upkeep).
## Vocabulary
| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **Domain** | A bounded context under `src/app/domains/<name>/` that owns its own models, services, NgRx slice, and components — e.g. *chat*, *voice-session*, *plugins*. | "module", "feature" (Angular reserves these for different things) |
| **Shared kernel** | Cross-domain contracts in `src/app/shared-kernel/` — wire-format models, P2P transfer utilities, plugin contracts, signaling contracts — imported by multiple domains. | "common", "core" |
| **Infrastructure** | Technical-runtime concerns shared by domains: `persistence/` (client-side store wiring) and `realtime/` (WebSocket adapter). Not a domain. | "shared", "lib" |
| **Rules file** | A pure-function module suffixed `*.rules.ts` that encodes domain logic without Angular or NgRx dependencies — easy to unit-test. | "helpers", "utils" |
## Relationships
- A **Domain** owns zero or more **Components**, **Services**, **NgRx slices**, and **Rules files**.
- A **Domain** may consume **Shared kernel** contracts but must never import from another **Domain** directly — cross-domain coupling goes through the shared kernel or NgRx events.
- The **Realtime** infrastructure adapts server WebSocket envelopes (defined in `src/app/shared-kernel/signaling-contracts.ts` and mirrored in `server/src/websocket/types.ts`) into NgRx actions consumed by domains.
- The **Plugins** domain consumes plugin manifests loaded by Electron's `plugin-library.ts` and exposes a sandboxed runtime that other domains may hook into.
## Boundaries / IO
- **Exposes:** the Angular SPA bundle served at `:4200` in dev (`ng serve`) or mounted by Electron in production; NgRx store events that other domains in this subdomain consume; UI surface to the end user.
- **Consumes:**
- `window.api.*` IPC surface exposed by Electron preload (defined in `electron/preload.ts` and `electron/api/`).
- WebSocket envelopes from `server/src/websocket/` (typed by `shared-kernel/signaling-contracts.ts`).
- REST endpoints from the server's `server/src/routes/` (server directory, invites, join requests, link metadata, klipy).
- Plugin manifests resolved by Electron's plugin library.
## Invariants
- A **Domain** never imports from another **Domain** directly — only through the **Shared kernel** or NgRx actions.
- **Rules files** stay framework-free (no Angular, no NgRx) so they can be Vitest-tested as plain functions.
- Wire-format types (anything that crosses the WebSocket or IPC boundary) live in **Shared kernel**, never inside a single domain.
## Flagged ambiguities
- _None recorded yet — add entries when a domain term resists clean definition._
---
*Agent-procedural rules (TDD, lint, etc.) live in `/AGENTS.md`. Per-domain implementation detail lives in `src/app/domains/<name>/README.md`. This file is the bounded-context domain artefact for the product client as a whole.*

View File

@@ -93,6 +93,16 @@
</main> </main>
</div> </div>
@if (isMobile() && directCalls.mobileOverlaySession(); as call) {
<div class="absolute inset-0 z-[70]">
<app-private-call
class="block h-full w-full"
[callIdInput]="call.callId"
[overlayMode]="true"
/>
</div>
}
@if (isThemeStudioFullscreen()) { @if (isThemeStudioFullscreen()) {
<div <div
#themeStudioControlsRef #themeStudioControlsRef

View File

@@ -38,6 +38,7 @@ import { GameActivityService } from './domains/game-activity';
import { PluginBootstrapService } from './domains/plugins'; import { PluginBootstrapService } from './domains/plugins';
import { DirectCallService } from './domains/direct-call'; import { DirectCallService } from './domains/direct-call';
import { IncomingCallModalComponent } from './domains/direct-call/feature/incoming-call-modal/incoming-call-modal.component'; import { IncomingCallModalComponent } from './domains/direct-call/feature/incoming-call-modal/incoming-call-modal.component';
import { PrivateCallComponent } from './features/direct-call/private-call.component';
import { ServersRailComponent } from './features/servers/servers-rail/servers-rail.component'; import { ServersRailComponent } from './features/servers/servers-rail/servers-rail.component';
import { TitleBarComponent } from './features/shell/title-bar/title-bar.component'; import { TitleBarComponent } from './features/shell/title-bar/title-bar.component';
import { FloatingVoiceControlsComponent } from './domains/voice-session/feature/floating-voice-controls/floating-voice-controls.component'; import { FloatingVoiceControlsComponent } from './domains/voice-session/feature/floating-voice-controls/floating-voice-controls.component';
@@ -70,6 +71,7 @@ import {
DebugConsoleComponent, DebugConsoleComponent,
ScreenShareSourcePickerComponent, ScreenShareSourcePickerComponent,
NativeContextMenuComponent, NativeContextMenuComponent,
PrivateCallComponent,
ThemeNodeDirective, ThemeNodeDirective,
ThemePickerOverlayComponent ThemePickerOverlayComponent
], ],
@@ -265,11 +267,22 @@ export class App implements OnInit, OnDestroy {
if (!currentUserId) { if (!currentUserId) {
if (!this.isPublicRoute(currentUrl)) { if (!this.isPublicRoute(currentUrl)) {
this.router.navigate(['/login'], { // On mobile, new/unauthenticated visitors landing on the app root or
queryParams: { // /search should stay on /search (which already exposes a login CTA).
returnUrl: currentUrl // The login form has no mobile chrome / back button, so dropping new
} // users straight onto it leaves them with no way to navigate away.
}).catch(() => {}); const currentPath = this.getRoutePath(currentUrl);
const isSearchLanding = currentPath === '/' || currentPath === '/search';
if (this.isMobile() && isSearchLanding) {
this.router.navigate(['/search'], { replaceUrl: true }).catch(() => {});
} else {
this.router.navigate(['/login'], {
queryParams: {
returnUrl: currentUrl
}
}).catch(() => {});
}
} }
} else { } else {
this.store.dispatch(UsersActions.loadCurrentUser()); this.store.dispatch(UsersActions.loadCurrentUser());

View File

@@ -35,6 +35,7 @@ export class AttachmentManagerService {
private watchedRoomId: string | null = this.extractWatchedRoomId(this.router.url); private watchedRoomId: string | null = this.extractWatchedRoomId(this.router.url);
private isDatabaseInitialised = false; private isDatabaseInitialised = false;
private autoDownloadRequestsByRoom = new Map<string, Promise<void>>();
constructor() { constructor() {
effect(() => { effect(() => {
@@ -79,27 +80,23 @@ export class AttachmentManagerService {
} }
async requestAutoDownloadsForRoom(roomId: string): Promise<void> { async requestAutoDownloadsForRoom(roomId: string): Promise<void> {
if (!roomId || !this.isRoomWatched(roomId)) if (!roomId || !this.isRoomWatched(roomId) || this.webrtc.getConnectedPeers().length === 0)
return; return;
if (this.database.isReady()) { const activeRequest = this.autoDownloadRequestsByRoom.get(roomId);
const messages = await this.database.getMessages(roomId, 500, 0);
for (const message of messages) { if (activeRequest) {
this.runtimeStore.rememberMessageRoom(message.id, message.roomId); return activeRequest;
await this.requestAutoDownloadsForMessage(message.id);
}
return;
} }
for (const [messageId] of this.runtimeStore.getAttachmentEntries()) { const request = this.runAutoDownloadsForRoom(roomId).finally(() => {
const attachmentRoomId = await this.persistence.resolveMessageRoomId(messageId); if (this.autoDownloadRequestsByRoom.get(roomId) === request) {
this.autoDownloadRequestsByRoom.delete(roomId);
if (attachmentRoomId === roomId) {
await this.requestAutoDownloadsForMessage(messageId);
} }
} });
this.autoDownloadRequestsByRoom.set(roomId, request);
return request;
} }
async deleteForMessage(messageId: string): Promise<void> { async deleteForMessage(messageId: string): Promise<void> {
@@ -180,6 +177,31 @@ export class AttachmentManagerService {
await this.transfer.fulfillRequestWithFile(messageId, fileId, targetPeerId, file); await this.transfer.fulfillRequestWithFile(messageId, fileId, targetPeerId, file);
} }
private async runAutoDownloadsForRoom(roomId: string): Promise<void> {
if (!this.isRoomWatched(roomId)) {
return;
}
if (this.database.isReady()) {
const messages = await this.database.getMessages(roomId, 500, 0);
for (const message of messages) {
this.runtimeStore.rememberMessageRoom(message.id, message.roomId);
await this.requestAutoDownloadsForMessage(message.id);
}
return;
}
for (const [messageId] of this.runtimeStore.getAttachmentEntries()) {
const attachmentRoomId = await this.persistence.resolveMessageRoomId(messageId);
if (attachmentRoomId === roomId) {
await this.requestAutoDownloadsForMessage(messageId);
}
}
}
private async requestAutoDownloadsForMessage(messageId: string, attachmentId?: string): Promise<void> { private async requestAutoDownloadsForMessage(messageId: string, attachmentId?: string): Promise<void> {
if (!messageId) if (!messageId)
return; return;

View File

@@ -1,5 +1,11 @@
/** Maximum number of recent messages to include in sync inventories. */ /** Maximum number of messages to include in sync inventories.
export const INVENTORY_LIMIT = 1000; *
* The inventory protocol now ships every message in the room (id, ts, rc, ac)
* chunked at `CHUNK_SIZE`, so peers converge on the full history regardless
* of how lopsided their message counts are. The constant remains as a safety
* ceiling for pathological rooms.
*/
export const INVENTORY_LIMIT = 1_000_000;
/** Number of messages per chunk for inventory / batch transfers. */ /** Number of messages per chunk for inventory / batch transfers. */
export const CHUNK_SIZE = 200; export const CHUNK_SIZE = 200;
@@ -14,7 +20,7 @@ export const SYNC_POLL_SLOW_MS = 900_000;
export const SYNC_TIMEOUT_MS = 5_000; export const SYNC_TIMEOUT_MS = 5_000;
/** Large limit used for legacy full-sync operations. */ /** Large limit used for legacy full-sync operations. */
export const FULL_SYNC_LIMIT = 10_000; export const FULL_SYNC_LIMIT = 1_000_000;
/** Inventory item representing a message's sync state. */ /** Inventory item representing a message's sync state. */
export interface InventoryItem { export interface InventoryItem {

View File

@@ -11,6 +11,8 @@
[isAdmin]="isAdmin()" [isAdmin]="isAdmin()"
[bottomPadding]="composerBottomPadding()" [bottomPadding]="composerBottomPadding()"
[conversationKey]="conversationKey()" [conversationKey]="conversationKey()"
[loadingOlder]="loadingOlder()"
[conversationExhausted]="conversationExhausted()"
(replyRequested)="setReplyTo($event)" (replyRequested)="setReplyTo($event)"
(deleteRequested)="handleDeleteRequested($event)" (deleteRequested)="handleDeleteRequested($event)"
(editSaved)="handleEditSaved($event)" (editSaved)="handleEditSaved($event)"
@@ -20,6 +22,7 @@
(imageOpened)="openLightbox($event)" (imageOpened)="openLightbox($event)"
(imageContextMenuRequested)="openImageContextMenu($event)" (imageContextMenuRequested)="openImageContextMenu($event)"
(embedRemoved)="handleEmbedRemoved($event)" (embedRemoved)="handleEmbedRemoved($event)"
(loadOlderRequested)="handleLoadOlderRequested($event)"
/> />
<div <div

View File

@@ -8,6 +8,8 @@ import {
inject, inject,
signal signal
} from '@angular/core'; } from '@angular/core';
import { toObservable, toSignal } from '@angular/core/rxjs-interop';
import { switchMap } from 'rxjs/operators';
import { Store } from '@ngrx/store'; import { Store } from '@ngrx/store';
import { ElectronBridgeService } from '../../../../core/platform/electron/electron-bridge.service'; import { ElectronBridgeService } from '../../../../core/platform/electron/electron-bridge.service';
import { ViewportService } from '../../../../core/platform'; import { ViewportService } from '../../../../core/platform';
@@ -18,7 +20,9 @@ import { KlipyGif, KlipyService } from '../../application/services/klipy.service
import { MessagesActions } from '../../../../store/messages/messages.actions'; import { MessagesActions } from '../../../../store/messages/messages.actions';
import { import {
selectAllMessages, selectAllMessages,
selectConversationExhausted,
selectMessagesLoading, selectMessagesLoading,
selectMessagesLoadingOlder,
selectMessagesSyncing selectMessagesSyncing
} from '../../../../store/messages/messages.selectors'; } from '../../../../store/messages/messages.selectors';
import { selectCurrentUser, selectIsCurrentUserAdmin } from '../../../../store/users/users.selectors'; import { selectCurrentUser, selectIsCurrentUserAdmin } from '../../../../store/users/users.selectors';
@@ -72,6 +76,7 @@ export class ChatMessagesComponent {
readonly loading = this.store.selectSignal(selectMessagesLoading); readonly loading = this.store.selectSignal(selectMessagesLoading);
readonly syncing = this.store.selectSignal(selectMessagesSyncing); readonly syncing = this.store.selectSignal(selectMessagesSyncing);
readonly loadingOlder = this.store.selectSignal(selectMessagesLoadingOlder);
readonly currentUser = this.store.selectSignal(selectCurrentUser); readonly currentUser = this.store.selectSignal(selectCurrentUser);
readonly isAdmin = this.store.selectSignal(selectIsCurrentUserAdmin); readonly isAdmin = this.store.selectSignal(selectIsCurrentUserAdmin);
@@ -83,6 +88,12 @@ export class ChatMessagesComponent {
}); });
readonly conversationKey = computed(() => `${this.currentRoom()?.id ?? 'no-room'}:${this.activeChannelId() ?? 'general'}`); readonly conversationKey = computed(() => `${this.currentRoom()?.id ?? 'no-room'}:${this.activeChannelId() ?? 'general'}`);
readonly conversationExhausted = toSignal(
toObservable(this.conversationKey).pipe(
switchMap((key) => this.store.select(selectConversationExhausted(key)))
),
{ initialValue: false }
);
readonly klipyEnabled = computed(() => this.klipy.isEnabled(this.currentRoom())); readonly klipyEnabled = computed(() => this.klipy.isEnabled(this.currentRoom()));
readonly composerBottomPadding = signal(140); readonly composerBottomPadding = signal(140);
readonly klipyGifPickerAnchorRight = signal(16); readonly klipyGifPickerAnchorRight = signal(16);
@@ -213,6 +224,22 @@ export class ChatMessagesComponent {
); );
} }
handleLoadOlderRequested(event: { beforeTimestamp: number; limit: number }): void {
const roomId = this.currentRoom()?.id;
if (!roomId)
return;
this.store.dispatch(
MessagesActions.loadOlderMessages({
roomId,
channelId: this.activeChannelId() ?? 'general',
beforeTimestamp: event.beforeTimestamp,
limit: event.limit
})
);
}
toggleKlipyGifPicker(): void { toggleKlipyGifPicker(): void {
const nextState = !this.showKlipyGifPicker(); const nextState = !this.showKlipyGifPicker();

View File

@@ -2,6 +2,7 @@
import { CommonModule } from '@angular/common'; import { CommonModule } from '@angular/common';
import { FormsModule } from '@angular/forms'; import { FormsModule } from '@angular/forms';
import { import {
ChangeDetectionStrategy,
Component, Component,
computed, computed,
ElementRef, ElementRef,
@@ -153,6 +154,7 @@ interface MissingPluginEmbedFallback {
], ],
templateUrl: './chat-message-item.component.html', templateUrl: './chat-message-item.component.html',
styleUrl: './chat-message-item.component.scss', styleUrl: './chat-message-item.component.scss',
changeDetection: ChangeDetectionStrategy.OnPush,
host: { host: {
style: 'display: contents;' style: 'display: contents;'
} }

View File

@@ -2,6 +2,7 @@
import { CommonModule } from '@angular/common'; import { CommonModule } from '@angular/common';
import { import {
AfterViewChecked, AfterViewChecked,
ChangeDetectionStrategy,
Component, Component,
ElementRef, ElementRef,
OnDestroy, OnDestroy,
@@ -48,6 +49,7 @@ declare global {
ThemeNodeDirective ThemeNodeDirective
], ],
templateUrl: './chat-message-list.component.html', templateUrl: './chat-message-list.component.html',
changeDetection: ChangeDetectionStrategy.OnPush,
host: { host: {
style: 'display: contents;' style: 'display: contents;'
} }
@@ -82,6 +84,16 @@ export class ChatMessageListComponent implements AfterViewChecked, OnDestroy {
readonly imageOpened = output<Attachment>(); readonly imageOpened = output<Attachment>();
readonly imageContextMenuRequested = output<ChatMessageImageContextMenuEvent>(); readonly imageContextMenuRequested = output<ChatMessageImageContextMenuEvent>();
readonly embedRemoved = output<ChatMessageEmbedRemoveEvent>(); readonly embedRemoved = output<ChatMessageEmbedRemoveEvent>();
/**
* Emitted when the user scrolls up past the in-store window and the
* component needs the parent to fetch an older page from the DB.
*/
readonly loadOlderRequested = output<{ beforeTimestamp: number; limit: number }>();
/** True while a DB-backed older-page fetch dispatched by the parent is in flight. */
readonly loadingOlder = input(false);
/** True once the parent has paginated all the way back to the start of DB history. */
readonly conversationExhausted = input(false);
private readonly PAGE_SIZE = 50; private readonly PAGE_SIZE = 50;
@@ -141,6 +153,21 @@ export class ChatMessageListComponent implements AfterViewChecked, OnDestroy {
return lookup; return lookup;
}); });
/**
* O(1) index of messages by id, built once per `allMessages()` change.
* Used by `findRepliedMessage` so each rendered row doing a reply lookup
* costs a Map.get instead of an Array.find over the full message list.
*/
private readonly messagesById = computed<ReadonlyMap<string, Message>>(() => {
const index = new Map<string, Message>();
for (const message of this.allMessages()) {
index.set(message.id, message);
}
return index;
});
private bottomScrollObserver: MutationObserver | null = null; private bottomScrollObserver: MutationObserver | null = null;
private bottomScrollTimer: ReturnType<typeof setTimeout> | null = null; private bottomScrollTimer: ReturnType<typeof setTimeout> | null = null;
private boundOnImageLoad: (() => void) | null = null; private boundOnImageLoad: (() => void) | null = null;
@@ -150,12 +177,41 @@ export class ChatMessageListComponent implements AfterViewChecked, OnDestroy {
private lastMessageCount = 0; private lastMessageCount = 0;
private initialScrollPending = true; private initialScrollPending = true;
private prismHighlightScheduled = false; private prismHighlightScheduled = false;
/**
* Set when an older-page DB fetch is in flight. While true, the
* `onMessagesChanged` effect treats incoming message-count growth as a
* prepend (older history arriving) and preserves the user's scroll
* position instead of running sticky-bottom / new-messages-indicator
* logic.
*/
private pendingOlderFetchScrollHeight: number | null = null;
private readonly onConversationChanged = effect(() => { private readonly onConversationChanged = effect(() => {
void this.conversationKey(); void this.conversationKey();
this.resetScrollingState(); this.resetScrollingState();
}); });
/**
* Clears the in-flight older-fetch flag when the parent reports the
* load has finished (regardless of how many rows were returned, even
* zero). Without this, `loadingMore` would stick on if the DB had no
* rows older than the cursor.
*/
private readonly onLoadingOlderChanged = effect(() => {
const inFlight = this.loadingOlder();
if (!inFlight && this.pendingOlderFetchScrollHeight !== null) {
// If onMessagesChanged already consumed the pending state because
// rows arrived, this is a no-op; otherwise we clear it now.
queueMicrotask(() => {
if (this.pendingOlderFetchScrollHeight !== null) {
this.pendingOlderFetchScrollHeight = null;
this.loadingMore.set(false);
}
});
}
});
private readonly onMessagesChanged = effect(() => { private readonly onMessagesChanged = effect(() => {
const currentCount = this.channelMessages().length; const currentCount = this.channelMessages().length;
const element = this.messagesContainer?.nativeElement; const element = this.messagesContainer?.nativeElement;
@@ -170,6 +226,36 @@ export class ChatMessageListComponent implements AfterViewChecked, OnDestroy {
return; return;
} }
// Handle older-history backfill: messages were prepended, not appended.
// Reveal the new rows by widening the display window, and preserve the
// user's visual scroll position across the height change. We skip the
// sticky-bottom / new-messages-indicator logic entirely for this path.
if (this.pendingOlderFetchScrollHeight !== null && currentCount > this.lastMessageCount) {
const previousScrollHeight = this.pendingOlderFetchScrollHeight;
const previousScrollTop = element.scrollTop;
const newlyLoaded = currentCount - this.lastMessageCount;
this.pendingOlderFetchScrollHeight = null;
this.displayLimit.update((limit) => limit + newlyLoaded);
requestAnimationFrame(() => {
requestAnimationFrame(() => {
const container = this.messagesContainer?.nativeElement;
if (container) {
const newScrollHeight = container.scrollHeight;
container.scrollTop = previousScrollTop + (newScrollHeight - previousScrollHeight);
}
this.loadingMore.set(false);
});
});
this.lastMessageCount = currentCount;
return;
}
const distanceFromBottom = element.scrollHeight - element.scrollTop - element.clientHeight; const distanceFromBottom = element.scrollHeight - element.scrollTop - element.clientHeight;
const newMessages = currentCount > this.lastMessageCount; const newMessages = currentCount > this.lastMessageCount;
const forceLocalSendScroll = this.shouldForceLocalSendScroll(); const forceLocalSendScroll = this.shouldForceLocalSendScroll();
@@ -232,7 +318,7 @@ export class ChatMessageListComponent implements AfterViewChecked, OnDestroy {
if (!messageId) if (!messageId)
return undefined; return undefined;
return this.allMessages().find((message) => message.id === messageId); return this.messagesById().get(messageId);
} }
onScroll(): void { onScroll(): void {
@@ -252,32 +338,68 @@ export class ChatMessageListComponent implements AfterViewChecked, OnDestroy {
this.stopBottomScrollWatch(); this.stopBottomScrollWatch();
} }
if (element.scrollTop < 150 && this.hasMoreMessages() && !this.loadingMore()) { if (element.scrollTop < 150 && !this.loadingMore()) {
this.loadMore(); const canFetchOlderFromDb =
!this.hasMoreMessages()
&& !this.conversationExhausted()
&& !this.loadingOlder()
&& this.channelMessages().length > 0;
if (this.hasMoreMessages() || canFetchOlderFromDb) {
this.loadMore();
}
} }
} }
loadMore(): void { loadMore(): void {
if (this.loadingMore() || !this.hasMoreMessages()) if (this.loadingMore())
return; return;
this.loadingMore.set(true); // Case 1: there are still in-store messages above the rendered window.
// Just widen the display window and preserve scroll position.
if (this.hasMoreMessages()) {
this.loadingMore.set(true);
const element = this.messagesContainer?.nativeElement; const element = this.messagesContainer?.nativeElement;
const previousScrollHeight = element?.scrollHeight ?? 0; const previousScrollHeight = element?.scrollHeight ?? 0;
this.displayLimit.update((limit) => limit + this.PAGE_SIZE); this.displayLimit.update((limit) => limit + this.PAGE_SIZE);
requestAnimationFrame(() => {
requestAnimationFrame(() => { requestAnimationFrame(() => {
if (element) { requestAnimationFrame(() => {
const newScrollHeight = element.scrollHeight; if (element) {
const newScrollHeight = element.scrollHeight;
element.scrollTop += newScrollHeight - previousScrollHeight; element.scrollTop += newScrollHeight - previousScrollHeight;
} }
this.loadingMore.set(false); this.loadingMore.set(false);
});
}); });
return;
}
// Case 2: in-store window is exhausted. Ask the parent to fetch the
// next older page from the DB. The parent dispatches loadOlderMessages
// and the resulting store update is handled by onMessagesChanged via
// pendingOlderFetchScrollHeight (prepend-aware scroll preservation).
if (this.loadingOlder() || this.conversationExhausted())
return;
const all = this.channelMessages();
if (all.length === 0)
return;
const oldest = all[0];
const element = this.messagesContainer?.nativeElement;
this.loadingMore.set(true);
this.pendingOlderFetchScrollHeight = element?.scrollHeight ?? 0;
this.loadOlderRequested.emit({
beforeTimestamp: oldest.timestamp,
limit: this.PAGE_SIZE
}); });
} }
@@ -359,6 +481,8 @@ export class ChatMessageListComponent implements AfterViewChecked, OnDestroy {
this.showNewMessagesBar.set(false); this.showNewMessagesBar.set(false);
this.lastMessageCount = 0; this.lastMessageCount = 0;
this.displayLimit.set(this.PAGE_SIZE); this.displayLimit.set(this.PAGE_SIZE);
this.pendingOlderFetchScrollHeight = null;
this.loadingMore.set(false);
} }
private startBottomScrollWatch(): void { private startBottomScrollWatch(): void {

View File

@@ -9,6 +9,7 @@ import {
import { Router } from '@angular/router'; import { Router } from '@angular/router';
import { Store } from '@ngrx/store'; import { Store } from '@ngrx/store';
import { NotificationAudioService, AppSound } from '../../../../core/services/notification-audio.service'; import { NotificationAudioService, AppSound } from '../../../../core/services/notification-audio.service';
import { ViewportService } from '../../../../core/platform';
import { import {
VoiceActivityService, VoiceActivityService,
VoiceConnectionFacade, VoiceConnectionFacade,
@@ -38,9 +39,11 @@ export class DirectCallService {
private readonly voiceSession = inject(VoiceSessionFacade); private readonly voiceSession = inject(VoiceSessionFacade);
private readonly voiceActivity = inject(VoiceActivityService); private readonly voiceActivity = inject(VoiceActivityService);
private readonly playback = inject(VoicePlaybackService); private readonly playback = inject(VoicePlaybackService);
private readonly viewport = inject(ViewportService);
private readonly currentUser = this.store.selectSignal(selectCurrentUser); private readonly currentUser = this.store.selectSignal(selectCurrentUser);
private readonly users = this.store.selectSignal(selectAllUsers); private readonly users = this.store.selectSignal(selectAllUsers);
private readonly sessionsSignal = signal<DirectCallSession[]>([]); private readonly sessionsSignal = signal<DirectCallSession[]>([]);
private readonly mobileOverlayCallId = signal<string | null>(null);
readonly sessions = computed(() => this.sessionsSignal()); readonly sessions = computed(() => this.sessionsSignal());
readonly activeSessions = computed(() => this.sessions().filter((session) => session.status !== 'ended')); readonly activeSessions = computed(() => this.sessions().filter((session) => session.status !== 'ended'));
@@ -65,6 +68,15 @@ export class DirectCallService {
}); });
readonly currentSession = signal<DirectCallSession | null>(null); readonly currentSession = signal<DirectCallSession | null>(null);
readonly hasActiveCall = computed(() => this.visibleActiveSessions().length > 0); readonly hasActiveCall = computed(() => this.visibleActiveSessions().length > 0);
readonly mobileOverlaySession = computed(() => {
const callId = this.mobileOverlayCallId();
if (!callId) {
return null;
}
return this.visibleActiveSessions().find((session) => session.callId === callId) ?? null;
});
constructor() { constructor() {
this.delivery.directCallEvents$.subscribe((event) => { this.delivery.directCallEvents$.subscribe((event) => {
@@ -92,6 +104,12 @@ export class DirectCallService {
this.audio.stop(AppSound.Call); this.audio.stop(AppSound.Call);
}); });
effect(() => {
if (this.mobileOverlayCallId() && !this.mobileOverlaySession()) {
this.mobileOverlayCallId.set(null);
}
});
} }
sessionById(callId: string | null | undefined): DirectCallSession | null { sessionById(callId: string | null | undefined): DirectCallSession | null {
@@ -155,7 +173,7 @@ export class DirectCallService {
this.currentSession.set(session); this.currentSession.set(session);
await this.joinCall(session.callId, false); await this.joinCall(session.callId, false);
this.sendCallEvent(peerParticipant.userId, 'ring', session); this.sendCallEvent(peerParticipant.userId, 'ring', session);
await this.router.navigate(['/call', session.callId]); await this.openCallView(session.callId);
return session; return session;
} }
@@ -186,6 +204,24 @@ export class DirectCallService {
this.currentSession.set(session); this.currentSession.set(session);
} }
async openCallView(callId: string): Promise<void> {
if (this.viewport.isMobile()) {
await this.openMobileCallOverlay(callId);
return;
}
await this.router.navigate(['/call', callId]);
}
async openMobileCallOverlay(callId: string): Promise<void> {
await this.openCall(callId);
this.mobileOverlayCallId.set(callId);
}
closeMobileCallOverlay(): void {
this.mobileOverlayCallId.set(null);
}
async answerIncomingCall(callId: string): Promise<void> { async answerIncomingCall(callId: string): Promise<void> {
const session = this.sessionById(callId); const session = this.sessionById(callId);

View File

@@ -6,17 +6,39 @@
appThemeNode="dmChatHeader" appThemeNode="dmChatHeader"
class="flex h-14 shrink-0 items-center gap-3 border-b border-border px-4" class="flex h-14 shrink-0 items-center gap-3 border-b border-border px-4"
> >
<app-user-avatar @if (peerUser()) {
[name]="peerName()" <button
[avatarUrl]="peerUser()?.avatarUrl" type="button"
[status]="peerUser()?.status" class="flex min-w-0 flex-1 items-center gap-3 rounded-md py-1 pr-2 text-left transition-colors hover:bg-secondary/60 focus:outline-none focus:ring-2 focus:ring-primary/50"
[showStatusBadge]="true" [attr.aria-label]="'Open profile for ' + peerName()"
size="md" [title]="'Open profile for ' + peerName()"
/> (click)="openHeaderProfileCard($event)"
<div class="min-w-0 flex-1"> >
<h1 class="truncate text-base font-semibold text-foreground">{{ peerName() }}</h1> <app-user-avatar
<p class="text-xs text-muted-foreground">{{ isGroupConversation() ? 'Group Chat' : 'Direct Message' }}</p> [name]="peerName()"
</div> [avatarUrl]="peerUser()?.avatarUrl"
[status]="peerUser()?.status"
[showStatusBadge]="true"
size="md"
/>
<div class="min-w-0 flex-1">
<h1 class="truncate text-base font-semibold text-foreground">{{ peerName() }}</h1>
<p class="text-xs text-muted-foreground">Direct Message</p>
</div>
</button>
} @else {
<app-user-avatar
[name]="peerName()"
[avatarUrl]="peerUser()?.avatarUrl"
[status]="peerUser()?.status"
[showStatusBadge]="true"
size="md"
/>
<div class="min-w-0 flex-1">
<h1 class="truncate text-base font-semibold text-foreground">{{ peerName() }}</h1>
<p class="text-xs text-muted-foreground">{{ isGroupConversation() ? 'Group Chat' : 'Direct Message' }}</p>
</div>
}
@if (showCallButton() && conversation()) { @if (showCallButton() && conversation()) {
<button <button
type="button" type="button"

View File

@@ -16,7 +16,11 @@ import { toSignal } from '@angular/core/rxjs-interop';
import { map } from 'rxjs'; import { map } from 'rxjs';
import { ElectronBridgeService } from '../../../../core/platform/electron/electron-bridge.service'; import { ElectronBridgeService } from '../../../../core/platform/electron/electron-bridge.service';
import { ViewportService } from '../../../../core/platform'; import { ViewportService } from '../../../../core/platform';
import { BottomSheetComponent, UserAvatarComponent } from '../../../../shared'; import {
BottomSheetComponent,
ProfileCardService,
UserAvatarComponent
} from '../../../../shared';
import { DirectCallService } from '../../../direct-call'; import { DirectCallService } from '../../../direct-call';
import { Attachment, AttachmentFacade } from '../../../attachment'; import { Attachment, AttachmentFacade } from '../../../attachment';
import { ThemeNodeDirective } from '../../../theme'; import { ThemeNodeDirective } from '../../../theme';
@@ -82,6 +86,7 @@ export class DmChatComponent {
private readonly attachments = inject(AttachmentFacade); private readonly attachments = inject(AttachmentFacade);
private readonly klipy = inject(KlipyService); private readonly klipy = inject(KlipyService);
private readonly linkMetadata = inject(LinkMetadataService); private readonly linkMetadata = inject(LinkMetadataService);
private readonly profileCard = inject(ProfileCardService);
private readonly viewport = inject(ViewportService); private readonly viewport = inject(ViewportService);
private readonly metadataRequestKeys = new Set<string>(); private readonly metadataRequestKeys = new Set<string>();
private openedConversationId: string | null = null; private openedConversationId: string | null = null;
@@ -309,6 +314,17 @@ export class DmChatComponent {
} }
} }
openHeaderProfileCard(event: MouseEvent): void {
const user = this.peerUser();
if (!user) {
return;
}
event.stopPropagation();
this.profileCard.open(event.currentTarget as HTMLElement, user, { editable: false });
}
setReplyTo(message: ChatMessageReplyEvent): void { setReplyTo(message: ChatMessageReplyEvent): void {
this.replyTo.set(message); this.replyTo.set(message);
} }

View File

@@ -3,7 +3,7 @@
<div class="group/server relative flex w-full justify-center"> <div class="group/server relative flex w-full justify-center">
<button <button
type="button" type="button"
class="relative z-10 flex h-10 w-10 cursor-pointer flex-shrink-0 items-center justify-center border border-transparent text-muted-foreground transition-[border-radius,box-shadow,background-color,color] duration-100 hover:rounded-lg hover:bg-card hover:text-foreground" class="relative z-10 flex h-11 w-11 cursor-pointer flex-shrink-0 items-center justify-center border border-transparent text-muted-foreground transition-[border-radius,box-shadow,background-color,color] duration-100 hover:rounded-lg hover:bg-card hover:text-foreground md:h-10 md:w-10"
title="Direct Messages" title="Direct Messages"
aria-label="Direct Messages" aria-label="Direct Messages"
[ngClass]="isOnDirectMessages() ? 'rounded-lg ring-2 ring-primary/40 bg-primary/10 text-foreground' : 'rounded-xl bg-card'" [ngClass]="isOnDirectMessages() ? 'rounded-lg ring-2 ring-primary/40 bg-primary/10 text-foreground' : 'rounded-xl bg-card'"
@@ -12,7 +12,7 @@
> >
<ng-icon <ng-icon
name="lucideMessageCircle" name="lucideMessageCircle"
class="h-4 w-4" class="h-[18px] w-[18px] md:h-4 md:w-4"
/> />
@if (directMessages.totalUnreadCount() > 0) { @if (directMessages.totalUnreadCount() > 0) {
<span class="dm-rail-slide-in absolute -right-1 -top-1 h-3 w-3 rounded-full bg-amber-400 ring-2 ring-card"></span> <span class="dm-rail-slide-in absolute -right-1 -top-1 h-3 w-3 rounded-full bg-amber-400 ring-2 ring-card"></span>
@@ -24,7 +24,7 @@
<div class="group/server relative flex w-full justify-center"> <div class="group/server relative flex w-full justify-center">
<button <button
type="button" type="button"
class="relative z-10 flex h-10 w-10 cursor-pointer flex-shrink-0 items-center justify-center border border-transparent transition-[border-radius,box-shadow,background-color] duration-100 hover:rounded-lg hover:bg-card" class="relative z-10 flex h-11 w-11 cursor-pointer flex-shrink-0 items-center justify-center border border-transparent transition-[border-radius,box-shadow,background-color] duration-100 hover:rounded-lg hover:bg-card md:h-10 md:w-10"
[class.dm-rail-slide-in]="!item.isExiting" [class.dm-rail-slide-in]="!item.isExiting"
[class.dm-rail-slide-out]="item.isExiting" [class.dm-rail-slide-out]="item.isExiting"
[class.pointer-events-none]="item.isExiting" [class.pointer-events-none]="item.isExiting"

View File

@@ -1,6 +1,6 @@
<div <div
appThemeNode="dmConversationItem" appThemeNode="dmConversationItem"
class="group flex w-full items-center gap-2 rounded-md px-2 py-2 text-left transition-colors hover:bg-secondary/60" class="group flex w-full cursor-pointer items-center gap-2 rounded-md px-2 py-2 text-left transition-colors hover:bg-secondary/60"
[class.bg-primary/10]="isSelected()" [class.bg-primary/10]="isSelected()"
[class.text-foreground]="isSelected()" [class.text-foreground]="isSelected()"
[attr.aria-current]="isSelected() ? 'page' : null" [attr.aria-current]="isSelected() ? 'page' : null"

View File

@@ -4,7 +4,8 @@ import {
computed, computed,
effect, effect,
inject, inject,
input input,
output
} from '@angular/core'; } from '@angular/core';
import { CommonModule } from '@angular/common'; import { CommonModule } from '@angular/common';
import { ActivatedRoute, Router } from '@angular/router'; import { ActivatedRoute, Router } from '@angular/router';
@@ -48,6 +49,7 @@ export class DmConversationItemComponent {
private readonly directMessages = inject(DirectMessageService); private readonly directMessages = inject(DirectMessageService);
private readonly directCalls = inject(DirectCallService); private readonly directCalls = inject(DirectCallService);
readonly conversation = input.required<DirectMessageConversation>(); readonly conversation = input.required<DirectMessageConversation>();
readonly conversationOpened = output<string>();
readonly users = this.store.selectSignal(selectAllUsers); readonly users = this.store.selectSignal(selectAllUsers);
readonly routeConversationId = toSignal(this.route.paramMap.pipe(map((params) => params.get('conversationId'))), { readonly routeConversationId = toSignal(this.route.paramMap.pipe(map((params) => params.get('conversationId'))), {
initialValue: this.route.snapshot.paramMap.get('conversationId') initialValue: this.route.snapshot.paramMap.get('conversationId')
@@ -71,6 +73,7 @@ export class DmConversationItemComponent {
} }
openConversation(): void { openConversation(): void {
this.conversationOpened.emit(this.conversation().id);
void this.router.navigate(['/dm', this.conversation().id]); void this.router.navigate(['/dm', this.conversation().id]);
} }

View File

@@ -1,6 +1,6 @@
<aside <aside
appThemeNode="dmConversationsPanel" appThemeNode="dmConversationsPanel"
class="flex min-h-0 overflow-hidden border-r border-border bg-card" class="flex min-h-0 w-full min-w-0 overflow-hidden border-r border-border bg-card"
[ngStyle]="listPanelStyles()" [ngStyle]="listPanelStyles()"
> >
<section class="flex h-full w-full min-w-0 flex-col"> <section class="flex h-full w-full min-w-0 flex-col">
@@ -28,10 +28,12 @@
<div class="flex h-full items-center justify-center px-4 text-center text-sm text-muted-foreground">No direct messages yet.</div> <div class="flex h-full items-center justify-center px-4 text-center text-sm text-muted-foreground">No direct messages yet.</div>
} @else { } @else {
<div class="space-y-1"> <div class="space-y-1">
<app-dm-conversation-item @for (conversation of directMessages.conversations(); track trackConversationId($index, conversation)) {
*ngFor="let conversation of directMessages.conversations(); trackBy: trackConversationId" <app-dm-conversation-item
[conversation]="conversation" [conversation]="conversation"
></app-dm-conversation-item> (conversationOpened)="conversationSelected.emit($event)"
/>
}
</div> </div>
} }
</div> </div>

View File

@@ -2,7 +2,8 @@
import { import {
Component, Component,
computed, computed,
inject inject,
output
} from '@angular/core'; } from '@angular/core';
import { CommonModule } from '@angular/common'; import { CommonModule } from '@angular/common';
import { NgIcon, provideIcons } from '@ng-icons/core'; import { NgIcon, provideIcons } from '@ng-icons/core';
@@ -31,6 +32,7 @@ export class DmConversationsPanelComponent {
private readonly theme = inject(ThemeService); private readonly theme = inject(ThemeService);
readonly directMessages = inject(DirectMessageService); readonly directMessages = inject(DirectMessageService);
readonly listPanelStyles = computed(() => this.theme.getLayoutItemStyles('dmConversationsPanel')); readonly listPanelStyles = computed(() => this.theme.getLayoutItemStyles('dmConversationsPanel'));
readonly conversationSelected = output<string>();
trackConversationId(index: number, conversation: DirectMessageConversation): string { trackConversationId(index: number, conversation: DirectMessageConversation): string {
return conversation.id; return conversation.id;

View File

@@ -13,7 +13,10 @@
<div class="flex h-full w-full min-h-0 overflow-hidden"> <div class="flex h-full w-full min-h-0 overflow-hidden">
<app-servers-rail class="block h-full shrink-0" /> <app-servers-rail class="block h-full shrink-0" />
<div class="flex min-h-0 flex-1 overflow-hidden border-l border-border"> <div class="flex min-h-0 flex-1 overflow-hidden border-l border-border">
<app-dm-conversations-panel class="block h-full w-full" /> <app-dm-conversations-panel
(conversationSelected)="setMobilePage('chat')"
class="block h-full w-full"
/>
</div> </div>
</div> </div>
</swiper-slide> </swiper-slide>
@@ -32,7 +35,21 @@
class="h-5 w-5" class="h-5 w-5"
/> />
</button> </button>
<p class="truncate text-sm font-semibold text-foreground">Direct messages</p> <p class="min-w-0 flex-1 truncate text-sm font-semibold text-foreground">Direct messages</p>
@if (activeCall()) {
<button
type="button"
(click)="openActiveCall()"
class="grid h-11 w-11 place-items-center rounded-lg text-emerald-600 transition-colors hover:bg-emerald-500/10 hover:text-emerald-500"
aria-label="Return to call"
title="Return to call"
>
<ng-icon
name="lucidePhoneCall"
class="h-5 w-5"
/>
</button>
}
</div> </div>
<div class="min-h-0 flex-1 overflow-hidden"> <div class="min-h-0 flex-1 overflow-hidden">
<app-dm-chat-panel class="block h-full w-full" /> <app-dm-chat-panel class="block h-full w-full" />
@@ -50,4 +67,3 @@
<app-dm-chat-panel /> <app-dm-chat-panel />
</div> </div>
} }

View File

@@ -16,10 +16,11 @@ import { ActivatedRoute, Router } from '@angular/router';
import { toSignal } from '@angular/core/rxjs-interop'; import { toSignal } from '@angular/core/rxjs-interop';
import { map } from 'rxjs'; import { map } from 'rxjs';
import { NgIcon, provideIcons } from '@ng-icons/core'; import { NgIcon, provideIcons } from '@ng-icons/core';
import { lucideChevronLeft } from '@ng-icons/lucide'; import { lucideChevronLeft, lucidePhoneCall } from '@ng-icons/lucide';
import { ServersRailComponent } from '../../../../features/servers/servers-rail/servers-rail.component'; import { ServersRailComponent } from '../../../../features/servers/servers-rail/servers-rail.component';
import { ViewportService } from '../../../../core/platform'; import { ViewportService } from '../../../../core/platform';
import { ThemeService } from '../../../theme'; import { ThemeService } from '../../../theme';
import { DirectCallService } from '../../../direct-call';
import { DirectMessageService } from '../../application/services/direct-message.service'; import { DirectMessageService } from '../../application/services/direct-message.service';
import { DmChatPanelComponent } from './dm-chat-panel.component'; import { DmChatPanelComponent } from './dm-chat-panel.component';
import { DmConversationsPanelComponent } from './dm-conversations-panel.component'; import { DmConversationsPanelComponent } from './dm-conversations-panel.component';
@@ -47,7 +48,7 @@ interface SwiperElement extends HTMLElement {
DmConversationsPanelComponent, DmConversationsPanelComponent,
ServersRailComponent ServersRailComponent
], ],
viewProviders: [provideIcons({ lucideChevronLeft })], viewProviders: [provideIcons({ lucideChevronLeft, lucidePhoneCall })],
schemas: [CUSTOM_ELEMENTS_SCHEMA], schemas: [CUSTOM_ELEMENTS_SCHEMA],
templateUrl: './dm-workspace.component.html' templateUrl: './dm-workspace.component.html'
}) })
@@ -57,6 +58,7 @@ export class DmWorkspaceComponent implements OnDestroy {
private readonly theme = inject(ThemeService); private readonly theme = inject(ThemeService);
private readonly viewport = inject(ViewportService); private readonly viewport = inject(ViewportService);
private readonly zone = inject(NgZone); private readonly zone = inject(NgZone);
private readonly directCalls = inject(DirectCallService);
private lastSeenConversationId: string | null = null; private lastSeenConversationId: string | null = null;
private swiperListenerAttached: SwiperElement | null = null; private swiperListenerAttached: SwiperElement | null = null;
readonly directMessages = inject(DirectMessageService); readonly directMessages = inject(DirectMessageService);
@@ -66,6 +68,12 @@ export class DmWorkspaceComponent implements OnDestroy {
readonly layoutStyles = computed(() => this.theme.getLayoutContainerStyles('dmLayout')); readonly layoutStyles = computed(() => this.theme.getLayoutContainerStyles('dmLayout'));
readonly isMobile = this.viewport.isMobile; readonly isMobile = this.viewport.isMobile;
readonly swiperRef = viewChild<ElementRef<SwiperElement>>('swiperEl'); readonly swiperRef = viewChild<ElementRef<SwiperElement>>('swiperEl');
readonly activeCall = computed(() => {
const currentSession = this.directCalls.currentSession();
const visibleSessions = this.directCalls.visibleActiveSessions();
return visibleSessions.find((session) => session.callId === currentSession?.callId) ?? visibleSessions[0] ?? null;
});
/** Active page within the mobile single-pane navigation flow. Ignored on desktop. */ /** Active page within the mobile single-pane navigation flow. Ignored on desktop. */
readonly mobilePage = signal<DmWorkspaceMobilePage>('conversations'); readonly mobilePage = signal<DmWorkspaceMobilePage>('conversations');
@@ -150,6 +158,14 @@ export class DmWorkspaceComponent implements OnDestroy {
this.mobilePage.set(page); this.mobilePage.set(page);
} }
openActiveCall(): void {
const call = this.activeCall();
if (call) {
void this.directCalls.openCallView(call.callId);
}
}
ngOnDestroy(): void { ngOnDestroy(): void {
this.directMessages.closeConversationView(this.routeConversationId()); this.directMessages.closeConversationView(this.routeConversationId());
} }

View File

@@ -3,6 +3,9 @@ import { Store } from '@ngrx/store';
import { Subscription } from 'rxjs'; import { Subscription } from 'rxjs';
import { RealtimeSessionFacade } from '../../../../core/realtime'; import { RealtimeSessionFacade } from '../../../../core/realtime';
import { DatabaseService } from '../../../../infrastructure/persistence'; import { DatabaseService } from '../../../../infrastructure/persistence';
import { ServerDirectoryFacade } from '../../../server-directory';
import { resolveRoomPermission } from '../../../access-control';
import { AttachmentFacade } from '../../../attachment';
import { VoiceConnectionFacade } from '../../../voice-connection/application/facades/voice-connection.facade'; import { VoiceConnectionFacade } from '../../../voice-connection/application/facades/voice-connection.facade';
import type { import type {
Channel, Channel,
@@ -14,6 +17,7 @@ import type {
User User
} from '../../../../shared-kernel'; } from '../../../../shared-kernel';
import { MessagesActions } from '../../../../store/messages/messages.actions'; import { MessagesActions } from '../../../../store/messages/messages.actions';
import { CHUNK_SIZE, chunkArray } from '../../../../store/messages/messages.helpers';
import { selectCurrentRoomMessages } from '../../../../store/messages/messages.selectors'; import { selectCurrentRoomMessages } from '../../../../store/messages/messages.selectors';
import { RoomsActions } from '../../../../store/rooms/rooms.actions'; import { RoomsActions } from '../../../../store/rooms/rooms.actions';
import { import {
@@ -24,10 +28,13 @@ import {
} from '../../../../store/rooms/rooms.selectors'; } from '../../../../store/rooms/rooms.selectors';
import { UsersActions } from '../../../../store/users/users.actions'; import { UsersActions } from '../../../../store/users/users.actions';
import { selectAllUsers, selectCurrentUser } from '../../../../store/users/users.selectors'; import { selectAllUsers, selectCurrentUser } from '../../../../store/users/users.selectors';
import { defaultChannels } from '../../../../store/rooms/room-channels.defaults';
import { isChannelNameTaken, normalizeChannelName } from '../../../../store/rooms/room-channels.rules';
import type { import type {
PluginApiAvatarUpdate, PluginApiAvatarUpdate,
PluginApiActionContext, PluginApiActionContext,
PluginApiActionSource, PluginApiActionSource,
PluginApiAttachmentImportRequest,
PluginApiChannelRequest, PluginApiChannelRequest,
PluginApiCustomStreamRequest, PluginApiCustomStreamRequest,
PluginApiMessageAsPluginUserRequest, PluginApiMessageAsPluginUserRequest,
@@ -44,11 +51,13 @@ import { PluginUiRegistryService } from './plugin-ui-registry.service';
@Injectable({ providedIn: 'root' }) @Injectable({ providedIn: 'root' })
export class PluginClientApiService { export class PluginClientApiService {
private readonly attachments = inject(AttachmentFacade);
private readonly capabilities = inject(PluginCapabilityService); private readonly capabilities = inject(PluginCapabilityService);
private readonly db = inject(DatabaseService); private readonly db = inject(DatabaseService);
private readonly logger = inject(PluginLoggerService); private readonly logger = inject(PluginLoggerService);
private readonly messageBus = inject(PluginMessageBusService); private readonly messageBus = inject(PluginMessageBusService);
private readonly realtime = inject(RealtimeSessionFacade); private readonly realtime = inject(RealtimeSessionFacade);
private readonly serverDirectory = inject(ServerDirectoryFacade);
private readonly store = inject(Store); private readonly store = inject(Store);
private readonly storage = inject(PluginStorageService); private readonly storage = inject(PluginStorageService);
private readonly uiRegistry = inject(PluginUiRegistryService); private readonly uiRegistry = inject(PluginUiRegistryService);
@@ -71,7 +80,11 @@ export class PluginClientApiService {
channels: { channels: {
addAudioChannel: (request) => { addAudioChannel: (request) => {
requireCapability('channels.manage'); requireCapability('channels.manage');
this.store.dispatch(RoomsActions.addChannel({ channel: createChannel(request, 'voice') })); this.addPluginManagedChannel(pluginId, createChannel(request, 'voice'));
},
addTextChannel: (request) => {
requireCapability('channels.manage');
this.addPluginManagedChannel(pluginId, createChannel(request, 'text'));
}, },
addVideoChannel: (request) => { addVideoChannel: (request) => {
requireCapability('channels.manage'); requireCapability('channels.manage');
@@ -143,6 +156,15 @@ export class PluginClientApiService {
await this.storage.writeClientData(pluginId, key, value); await this.storage.writeClientData(pluginId, key, value);
} }
}, },
attachments: {
import: async (request: PluginApiAttachmentImportRequest) => {
requireCapability('messages.sync');
const roomId = this.requireRoomId();
this.attachments.rememberMessageRoom(request.messageId, roomId);
await this.attachments.publishAttachments(request.messageId, request.files, this.currentUser()?.id);
}
},
media: { media: {
addCustomAudioStream: async (request) => { addCustomAudioStream: async (request) => {
requireCapability('media.addAudioStream'); requireCapability('media.addAudioStream');
@@ -190,6 +212,10 @@ export class PluginClientApiService {
requireCapability('messages.send'); requireCapability('messages.send');
this.receivePluginUserMessage(pluginId, request); this.receivePluginUserMessage(pluginId, request);
}, },
import: async (messages) => {
requireCapability('messages.sync');
await this.importPluginMessages(pluginId, messages);
},
setTyping: (isTyping, channelId) => { setTyping: (isTyping, channelId) => {
requireCapability('messages.send'); requireCapability('messages.send');
this.setTyping(pluginId, isTyping, channelId); this.setTyping(pluginId, isTyping, channelId);
@@ -301,6 +327,58 @@ export class PluginClientApiService {
return userId; return userId;
}, },
updateIcon: async (icon) => {
requireCapability('server.manage');
const room = this.currentRoom();
const currentUser = this.currentUser();
if (!room) {
throw new Error('Room not found');
}
if (!currentUser) {
throw new Error('Not logged in');
}
const isOwner = room.hostId === currentUser.id || room.hostId === currentUser.oderId;
const isServerAdmin = currentUser.role === 'admin' || currentUser.role === 'host';
const canByRole = resolveRoomPermission(room, currentUser, 'manageIcon');
if (!isOwner && !isServerAdmin && !canByRole) {
throw new Error('Permission denied');
}
const iconUpdatedAt = Date.now();
await this.db.updateRoom(room.id, { icon, iconUpdatedAt });
this.store.dispatch(RoomsActions.updateServerIconSuccess({ roomId: room.id, icon, iconUpdatedAt }));
this.realtime.broadcastMessage({
type: 'server-icon-update',
roomId: room.id,
icon,
iconUpdatedAt
});
this.realtime.sendRawMessage({
type: 'server_icon_available',
serverId: room.id,
iconUpdatedAt
});
this.serverDirectory.updateServer(room.id, {
actingRole: isOwner ? 'host' : undefined,
currentOwnerId: currentUser.id,
icon,
iconUpdatedAt
}, {
sourceId: room.sourceId,
sourceUrl: room.sourceUrl
}).subscribe({
error: () => {}
});
},
updatePermissions: (permissions) => { updatePermissions: (permissions) => {
requireCapability('server.manage'); requireCapability('server.manage');
this.store.dispatch(RoomsActions.updateRoomPermissions({ roomId: this.requireRoomId(), permissions })); this.store.dispatch(RoomsActions.updateRoomPermissions({ roomId: this.requireRoomId(), permissions }));
@@ -648,6 +726,106 @@ export class PluginClientApiService {
}); });
} }
private async importPluginMessages(pluginId: string, messages: Message[]): Promise<void> {
const roomId = this.requireRoomId();
const normalizedMessages = messages
.filter((message) => message.roomId === roomId)
.map((message) => ({
...message,
channelId: message.channelId ?? this.activeChannelId() ?? 'general',
isDeleted: message.isDeleted === true,
reactions: message.reactions ?? []
}));
if (normalizedMessages.length === 0) {
return;
}
for (const message of normalizedMessages) {
await this.db.saveMessage(message);
}
this.store.dispatch(MessagesActions.syncMessages({ messages: normalizedMessages }));
// Broadcast imported history to peers in CHUNK_SIZE batches so they don't
// depend on the inventory-limited background sync to discover bulk imports.
for (const chunk of chunkArray(normalizedMessages, CHUNK_SIZE)) {
this.voice.broadcastMessage({
type: 'chat-sync-batch',
roomId,
messages: chunk
} as unknown as ChatEvent);
}
this.logger.info(pluginId, 'Historical messages imported', { count: normalizedMessages.length });
}
private addPluginManagedChannel(pluginId: string, channel: Channel): void {
const room = this.currentRoom();
const currentUser = this.currentUser();
if (!room || !currentUser) {
return;
}
const isOwner = room.hostId === currentUser.id || room.hostId === currentUser.oderId;
const isServerAdmin = currentUser.role === 'admin' || currentUser.role === 'host';
const canManageChannels = resolveRoomPermission(room, currentUser, 'manageChannels');
if (!isOwner && !isServerAdmin && !canManageChannels) {
this.logger.warn(pluginId, 'Plugin channel creation denied by room permissions', {
channelId: channel.id,
roomId: room.id
});
return;
}
const existingChannels = room.channels ?? defaultChannels();
const normalizedName = normalizeChannelName(channel.name);
const channelExists = existingChannels.some((entry) => entry.id === channel.id) ||
isChannelNameTaken(existingChannels, normalizedName, channel.type);
if (!normalizedName || channelExists) {
return;
}
const channels = [
...existingChannels,
{ ...channel,
name: normalizedName }
];
this.store.dispatch(RoomsActions.updateRoom({ roomId: room.id,
changes: { channels } }));
void this.db.updateRoom(room.id, { channels }).catch((error: unknown) => {
this.logger.warn(pluginId, 'Failed to persist plugin-created channel', error);
});
this.realtime.broadcastMessage({
type: 'channels-update',
roomId: room.id,
channels
});
this.serverDirectory.updateServer(room.id, {
actingRole: isOwner ? 'host' : undefined,
channels,
currentOwnerId: currentUser.id
}, {
sourceId: room.sourceId,
sourceUrl: room.sourceUrl
}).subscribe({
error: () => {}
});
this.logger.info(pluginId, 'Plugin channel created', {
channelId: channel.id,
roomId: room.id
});
}
private persistPluginMessageUpdate(pluginId: string, messageId: string, updates: Partial<Message>): void { private persistPluginMessageUpdate(pluginId: string, messageId: string, updates: Partial<Message>): void {
void this.db.updateMessage(messageId, updates).catch((error: unknown) => { void this.db.updateMessage(messageId, updates).catch((error: unknown) => {
this.logger.warn(pluginId, 'Failed to persist plugin message update', error); this.logger.warn(pluginId, 'Failed to persist plugin message update', error);

View File

@@ -1107,7 +1107,7 @@ function parsePluginEntry(sourceUrl: string, sourceTitle: string, value: unknown
githubUrl: resolveOptionalUrl(sourceUrl, readGithubUrl(value)), githubUrl: resolveOptionalUrl(sourceUrl, readGithubUrl(value)),
homepageUrl: resolveOptionalUrl(sourceUrl, readString(value, 'homepage', 'homepageUrl', 'website')), homepageUrl: resolveOptionalUrl(sourceUrl, readString(value, 'homepage', 'homepageUrl', 'website')),
id, id,
imageUrl: resolveOptionalUrl(sourceUrl, readString(value, 'image', 'imageUrl', 'icon', 'iconUrl', 'banner')), imageUrl: normalizeImageUrl(resolveOptionalUrl(sourceUrl, readString(value, 'image', 'imageUrl', 'icon', 'iconUrl', 'banner'))),
installUrl: resolveOptionalUrl(sourceUrl, readString(value, 'install', 'installUrl', 'manifest', 'manifestUrl')), installUrl: resolveOptionalUrl(sourceUrl, readString(value, 'install', 'installUrl', 'manifest', 'manifestUrl')),
readmeUrl: resolveOptionalUrl(sourceUrl, readString(value, 'readme', 'readmeUrl')), readmeUrl: resolveOptionalUrl(sourceUrl, readString(value, 'readme', 'readmeUrl')),
scope: readPluginInstallScope(value), scope: readPluginInstallScope(value),
@@ -1300,6 +1300,44 @@ function normalizeOptionalSourceUrl(rawUrl: string): string | undefined {
} }
} }
/**
* Rewrites human-friendly GitHub URLs so the browser can load the underlying
* binary asset. Users typically paste links copied from the GitHub web UI which
* point at the rendered HTML preview (`github.com/<owner>/<repo>/blob/...`) or
* the raw redirector (`github.com/<owner>/<repo>/raw/...`). Both forms must be
* mapped to `raw.githubusercontent.com` for `<img>` tags to work.
*/
function normalizeImageUrl(rawUrl: string | undefined): string | undefined {
if (!rawUrl) {
return undefined;
}
let url: URL;
try {
url = new URL(rawUrl);
} catch {
return rawUrl;
}
if (url.hostname !== 'github.com' && url.hostname !== 'www.github.com') {
return rawUrl;
}
const segments = url.pathname.split('/').filter(Boolean);
const kindIndex = segments.findIndex((segment) => segment === 'blob' || segment === 'raw');
if (kindIndex < 2 || kindIndex >= segments.length - 1) {
return rawUrl;
}
const owner = segments[0];
const repo = segments[1];
const ref = segments.slice(kindIndex + 1).join('/');
return `https://raw.githubusercontent.com/${owner}/${repo}/${ref}${url.search}`;
}
function resolveOptionalUrl(sourceUrl: string, rawUrl?: string): string | undefined { function resolveOptionalUrl(sourceUrl: string, rawUrl?: string): string | undefined {
if (!rawUrl) { if (!rawUrl) {
return undefined; return undefined;

View File

@@ -74,6 +74,11 @@ export interface PluginApiAudioClipRequest {
url: string; url: string;
} }
export interface PluginApiAttachmentImportRequest {
files: File[];
messageId: string;
}
export interface PluginApiCustomStreamRequest { export interface PluginApiCustomStreamRequest {
label?: string; label?: string;
stream: MediaStream; stream: MediaStream;
@@ -195,6 +200,7 @@ export interface PluginApiUiContributionMap {
export interface TojuClientPluginApi { export interface TojuClientPluginApi {
readonly channels: { readonly channels: {
addAudioChannel: (request: PluginApiChannelRequest) => void; addAudioChannel: (request: PluginApiChannelRequest) => void;
addTextChannel: (request: PluginApiChannelRequest) => void;
addVideoChannel: (request: PluginApiChannelRequest) => void; addVideoChannel: (request: PluginApiChannelRequest) => void;
list: () => Channel[]; list: () => Channel[];
remove: (channelId: string) => void; remove: (channelId: string) => void;
@@ -221,6 +227,9 @@ export interface TojuClientPluginApi {
remove: (key: string) => Promise<void>; remove: (key: string) => Promise<void>;
write: (key: string, value: unknown) => Promise<void>; write: (key: string, value: unknown) => Promise<void>;
}; };
readonly attachments: {
import: (request: PluginApiAttachmentImportRequest) => Promise<void>;
};
readonly media: { readonly media: {
addCustomAudioStream: (request: PluginApiCustomStreamRequest) => Promise<void>; addCustomAudioStream: (request: PluginApiCustomStreamRequest) => Promise<void>;
addCustomVideoStream: (request: PluginApiCustomStreamRequest) => Promise<void>; addCustomVideoStream: (request: PluginApiCustomStreamRequest) => Promise<void>;
@@ -235,6 +244,7 @@ export interface TojuClientPluginApi {
readCurrent: () => Message[]; readCurrent: () => Message[];
send: (content: string, channelId?: string) => Message; send: (content: string, channelId?: string) => Message;
sendAsPluginUser: (request: PluginApiMessageAsPluginUserRequest) => void; sendAsPluginUser: (request: PluginApiMessageAsPluginUserRequest) => void;
import: (messages: Message[]) => Promise<void>;
setTyping: (isTyping: boolean, channelId?: string) => void; setTyping: (isTyping: boolean, channelId?: string) => void;
subscribeTyping: (handler: (event: PluginApiTypingEvent) => void) => TojuPluginDisposable; subscribeTyping: (handler: (event: PluginApiTypingEvent) => void) => TojuPluginDisposable;
sync: (messages: Message[]) => void; sync: (messages: Message[]) => void;
@@ -261,6 +271,7 @@ export interface TojuClientPluginApi {
readonly server: { readonly server: {
getCurrent: () => Room | null; getCurrent: () => Room | null;
registerPluginUser: (request: PluginApiPluginUserRequest) => string; registerPluginUser: (request: PluginApiPluginUserRequest) => string;
updateIcon: (icon: string) => Promise<void>;
updatePermissions: (permissions: Partial<RoomPermissions>) => void; updatePermissions: (permissions: Partial<RoomPermissions>) => void;
updateSettings: (settings: PluginApiServerSettingsUpdate) => void; updateSettings: (settings: PluginApiServerSettingsUpdate) => void;
}; };

View File

@@ -1,13 +1,13 @@
<!-- eslint-disable @angular-eslint/template/cyclomatic-complexity --> <!-- eslint-disable @angular-eslint/template/cyclomatic-complexity -->
<section <section
class="flex h-full min-h-0 flex-col bg-background text-foreground" class="flex min-h-full flex-col bg-background text-foreground md:h-full md:min-h-0"
data-testid="plugin-manager" data-testid="plugin-manager"
> >
<header class="flex items-center justify-between border-b border-border px-4 py-3"> <header class="flex flex-col gap-3 border-b border-border px-3 py-3 md:flex-row md:items-center md:justify-between md:px-4">
<div class="flex min-w-0 items-center gap-3"> <div class="flex min-w-0 items-center gap-3 md:flex-1">
<button <button
type="button" type="button"
class="inline-flex h-8 w-8 items-center justify-center rounded-md text-muted-foreground hover:bg-muted hover:text-foreground" class="inline-flex h-11 w-11 flex-shrink-0 items-center justify-center rounded-md text-muted-foreground hover:bg-muted hover:text-foreground md:h-8 md:w-8"
aria-label="Back to settings" aria-label="Back to settings"
(click)="close()" (click)="close()"
> >
@@ -21,38 +21,40 @@
<p class="truncate text-xs text-muted-foreground">{{ managerDescription() }}</p> <p class="truncate text-xs text-muted-foreground">{{ managerDescription() }}</p>
</div> </div>
</div> </div>
<button <div class="grid grid-cols-1 gap-2 sm:grid-cols-2 md:flex md:flex-shrink-0 md:items-center">
type="button" <button
class="inline-flex h-8 items-center gap-2 rounded-md border border-border px-3 text-sm hover:bg-muted disabled:opacity-50" type="button"
[disabled]="busyAll()" class="inline-flex min-h-11 items-center justify-center gap-2 rounded-md border border-border px-3 text-sm hover:bg-muted disabled:opacity-50 md:h-8 md:min-h-0"
(click)="activateAll()" [disabled]="busyAll()"
> (click)="activateAll()"
<ng-icon >
name="lucidePlay" <ng-icon
size="16" name="lucidePlay"
/> size="16"
Activate ready plugins />
</button> Activate ready plugins
<button </button>
type="button" <button
class="inline-flex h-8 items-center gap-2 rounded-md border border-border px-3 text-sm hover:bg-muted" type="button"
(click)="openStore()" class="inline-flex min-h-11 items-center justify-center gap-2 rounded-md border border-border px-3 text-sm hover:bg-muted md:h-8 md:min-h-0"
> (click)="openStore()"
<ng-icon >
name="lucideStore" <ng-icon
size="16" name="lucideStore"
/> size="16"
Open Plugin Store />
</button> Open Plugin Store
</button>
</div>
</header> </header>
<nav <nav
class="flex gap-2 border-b border-border px-4 py-2" class="no-scrollbar flex gap-2 overflow-x-auto border-b border-border px-3 py-2 md:px-4"
aria-label="Plugin manager sections" aria-label="Plugin manager sections"
> >
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-2 rounded-md px-3 text-sm" class="inline-flex h-11 flex-shrink-0 items-center gap-2 rounded-md px-3 text-sm md:h-8"
[class.bg-muted]="activeTab() === 'installed'" [class.bg-muted]="activeTab() === 'installed'"
(click)="setTab('installed')" (click)="setTab('installed')"
> >
@@ -64,7 +66,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-2 rounded-md px-3 text-sm" class="inline-flex h-11 flex-shrink-0 items-center gap-2 rounded-md px-3 text-sm md:h-8"
[class.bg-muted]="activeTab() === 'extensions'" [class.bg-muted]="activeTab() === 'extensions'"
(click)="setTab('extensions')" (click)="setTab('extensions')"
> >
@@ -76,7 +78,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-2 rounded-md px-3 text-sm" class="inline-flex h-11 flex-shrink-0 items-center gap-2 rounded-md px-3 text-sm md:h-8"
[class.bg-muted]="activeTab() === 'requirements'" [class.bg-muted]="activeTab() === 'requirements'"
(click)="setTab('requirements')" (click)="setTab('requirements')"
> >
@@ -88,7 +90,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-2 rounded-md px-3 text-sm" class="inline-flex h-11 flex-shrink-0 items-center gap-2 rounded-md px-3 text-sm md:h-8"
[class.bg-muted]="activeTab() === 'settings'" [class.bg-muted]="activeTab() === 'settings'"
(click)="setTab('settings')" (click)="setTab('settings')"
> >
@@ -100,7 +102,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-2 rounded-md px-3 text-sm" class="inline-flex h-11 flex-shrink-0 items-center gap-2 rounded-md px-3 text-sm md:h-8"
[class.bg-muted]="activeTab() === 'docs'" [class.bg-muted]="activeTab() === 'docs'"
(click)="setTab('docs')" (click)="setTab('docs')"
> >
@@ -112,7 +114,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-2 rounded-md px-3 text-sm" class="inline-flex h-11 flex-shrink-0 items-center gap-2 rounded-md px-3 text-sm md:h-8"
[class.bg-muted]="activeTab() === 'logs'" [class.bg-muted]="activeTab() === 'logs'"
(click)="setTab('logs')" (click)="setTab('logs')"
> >
@@ -124,7 +126,7 @@
</button> </button>
</nav> </nav>
<div class="min-h-0 flex-1 overflow-auto p-4"> <div class="min-h-0 flex-1 overflow-auto p-3 md:p-4">
@switch (activeTab()) { @switch (activeTab()) {
@case ('extensions') { @case ('extensions') {
<div class="space-y-4"> <div class="space-y-4">
@@ -216,7 +218,7 @@
@for (entry of entries(); track trackEntry($index, entry)) { @for (entry of entries(); track trackEntry($index, entry)) {
<button <button
type="button" type="button"
class="w-full rounded-md border border-border px-3 py-2 text-left text-sm hover:bg-muted" class="min-h-11 w-full rounded-md border border-border px-3 py-2 text-left text-sm hover:bg-muted md:min-h-0"
[class.bg-muted]="isSelected(entry)" [class.bg-muted]="isSelected(entry)"
(click)="selectPlugin(entry.manifest.id)" (click)="selectPlugin(entry.manifest.id)"
> >
@@ -224,7 +226,7 @@
</button> </button>
} }
</div> </div>
<section class="rounded-lg border border-border bg-card p-4"> <section class="rounded-lg border border-border bg-card p-3 md:p-4">
@if (selectedPlugin(); as plugin) { @if (selectedPlugin(); as plugin) {
<h3 class="text-sm font-semibold">{{ plugin.manifest.title }} settings</h3> <h3 class="text-sm font-semibold">{{ plugin.manifest.title }} settings</h3>
@if (selectedSettingsPages().length > 0) { @if (selectedSettingsPages().length > 0) {
@@ -255,7 +257,7 @@
@for (entry of entries(); track trackEntry($index, entry)) { @for (entry of entries(); track trackEntry($index, entry)) {
<button <button
type="button" type="button"
class="w-full rounded-md border border-border px-3 py-2 text-left text-sm hover:bg-muted" class="min-h-11 w-full rounded-md border border-border px-3 py-2 text-left text-sm hover:bg-muted md:min-h-0"
[class.bg-muted]="isSelected(entry)" [class.bg-muted]="isSelected(entry)"
(click)="selectPlugin(entry.manifest.id)" (click)="selectPlugin(entry.manifest.id)"
> >
@@ -263,14 +265,14 @@
</button> </button>
} }
</div> </div>
<section class="rounded-lg border border-border bg-card p-4"> <section class="rounded-lg border border-border bg-card p-3 md:p-4">
@if (selectedPlugin(); as plugin) { @if (selectedPlugin(); as plugin) {
<h3 class="text-sm font-semibold">{{ plugin.manifest.title }}</h3> <h3 class="text-sm font-semibold">{{ plugin.manifest.title }}</h3>
<p class="mt-2 text-sm text-muted-foreground">{{ plugin.manifest.description }}</p> <p class="mt-2 text-sm text-muted-foreground">{{ plugin.manifest.description }}</p>
<div class="mt-4 flex flex-wrap gap-2"> <div class="mt-4 flex flex-wrap gap-2">
@for (doc of selectedDocs(); track doc.label) { @for (doc of selectedDocs(); track doc.label) {
<a <a
class="rounded-md border border-border px-3 py-1.5 text-sm hover:bg-muted" class="inline-flex min-h-11 items-center rounded-md border border-border px-3 py-1.5 text-sm hover:bg-muted md:min-h-0"
[href]="doc.url" [href]="doc.url"
target="_blank" target="_blank"
rel="noreferrer" rel="noreferrer"
@@ -292,7 +294,7 @@
@for (entry of entries(); track trackEntry($index, entry)) { @for (entry of entries(); track trackEntry($index, entry)) {
<button <button
type="button" type="button"
class="rounded-md border border-border px-3 py-1 text-sm hover:bg-muted" class="min-h-11 rounded-md border border-border px-3 py-1 text-sm hover:bg-muted md:min-h-0"
[class.bg-muted]="isSelected(entry)" [class.bg-muted]="isSelected(entry)"
(click)="selectPlugin(entry.manifest.id)" (click)="selectPlugin(entry.manifest.id)"
> >
@@ -323,7 +325,7 @@
<div class="space-y-3"> <div class="space-y-3">
@if (entries().length === 0) { @if (entries().length === 0) {
<div <div
class="rounded-lg border border-dashed border-border p-8 text-center" class="rounded-lg border border-dashed border-border p-5 text-center md:p-8"
data-testid="plugin-empty-state" data-testid="plugin-empty-state"
> >
<ng-icon <ng-icon
@@ -337,7 +339,7 @@
} @else { } @else {
@for (entry of entries(); track trackEntry($index, entry)) { @for (entry of entries(); track trackEntry($index, entry)) {
<article <article
class="rounded-lg border border-border bg-card p-4" class="rounded-lg border border-border bg-card p-3 md:p-4"
[class.ring-2]="isSelected(entry)" [class.ring-2]="isSelected(entry)"
[class.ring-primary]="isSelected(entry)" [class.ring-primary]="isSelected(entry)"
> >
@@ -351,17 +353,17 @@
<p class="mt-1 text-sm text-muted-foreground">{{ entry.manifest.description }}</p> <p class="mt-1 text-sm text-muted-foreground">{{ entry.manifest.description }}</p>
<p class="mt-2 text-xs text-muted-foreground">{{ entry.manifest.id }}</p> <p class="mt-2 text-xs text-muted-foreground">{{ entry.manifest.id }}</p>
</div> </div>
<div class="flex flex-wrap gap-2"> <div class="grid w-full grid-cols-2 gap-2 sm:flex sm:w-auto sm:flex-wrap">
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted" class="inline-flex min-h-11 items-center justify-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted md:h-8 md:min-h-0"
(click)="selectPlugin(entry.manifest.id)" (click)="selectPlugin(entry.manifest.id)"
> >
Select Select
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted" class="inline-flex min-h-11 items-center justify-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted md:h-8 md:min-h-0"
(click)="setEnabled(entry, !entry.enabled)" (click)="setEnabled(entry, !entry.enabled)"
> >
<ng-icon <ng-icon
@@ -372,7 +374,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted disabled:opacity-50" class="inline-flex min-h-11 items-center justify-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted disabled:opacity-50 md:h-8 md:min-h-0"
[disabled]="busyPluginId() === entry.manifest.id || !entry.enabled || isActive(entry)" [disabled]="busyPluginId() === entry.manifest.id || !entry.enabled || isActive(entry)"
(click)="activate(entry)" (click)="activate(entry)"
> >
@@ -384,7 +386,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted disabled:opacity-50" class="inline-flex min-h-11 items-center justify-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted disabled:opacity-50 md:h-8 md:min-h-0"
[disabled]="busyPluginId() === entry.manifest.id" [disabled]="busyPluginId() === entry.manifest.id"
(click)="reload(entry)" (click)="reload(entry)"
> >
@@ -396,7 +398,7 @@
</button> </button>
<button <button
type="button" type="button"
class="inline-flex h-8 items-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted disabled:opacity-50" class="inline-flex min-h-11 items-center justify-center gap-1.5 rounded-md border border-border px-2 text-sm hover:bg-muted disabled:opacity-50 md:h-8 md:min-h-0"
[disabled]="busyPluginId() === entry.manifest.id" [disabled]="busyPluginId() === entry.manifest.id"
(click)="unload(entry)" (click)="unload(entry)"
> >
@@ -416,7 +418,7 @@
} }
</div> </div>
<aside class="rounded-lg border border-border bg-card p-4"> <aside class="rounded-lg border border-border bg-card p-3 md:p-4">
@if (selectedPlugin(); as plugin) { @if (selectedPlugin(); as plugin) {
<div class="flex items-center gap-2"> <div class="flex items-center gap-2">
<ng-icon <ng-icon
@@ -430,14 +432,14 @@
} @else { } @else {
<button <button
type="button" type="button"
class="mt-3 h-8 rounded-md border border-border px-3 text-sm hover:bg-muted" class="mt-3 min-h-11 rounded-md border border-border px-3 text-sm hover:bg-muted md:h-8 md:min-h-0"
(click)="grantAll(plugin)" (click)="grantAll(plugin)"
> >
Grant all requested Grant all requested
</button> </button>
<div class="mt-3 space-y-2"> <div class="mt-3 space-y-2">
@for (capability of plugin.manifest.capabilities; track trackCapability($index, capability)) { @for (capability of plugin.manifest.capabilities; track trackCapability($index, capability)) {
<label class="flex items-center gap-2 rounded-md border border-border px-3 py-2 text-sm"> <label class="flex min-h-11 items-center gap-2 rounded-md border border-border px-3 py-2 text-sm md:min-h-0">
<input <input
type="checkbox" type="checkbox"
class="h-4 w-4" class="h-4 w-4"

View File

@@ -257,11 +257,13 @@
@for (plugin of filteredPlugins(); track trackPlugin($index, plugin)) { @for (plugin of filteredPlugins(); track trackPlugin($index, plugin)) {
<article class="grid min-w-0 overflow-hidden rounded-lg border border-border bg-background sm:grid-cols-[5.5rem_minmax(0,1fr)]"> <article class="grid min-w-0 overflow-hidden rounded-lg border border-border bg-background sm:grid-cols-[5.5rem_minmax(0,1fr)]">
<div class="grid min-h-24 place-items-center bg-secondary text-muted-foreground sm:min-h-full"> <div class="grid min-h-24 place-items-center bg-secondary text-muted-foreground sm:min-h-full">
@if (plugin.imageUrl) { @if (plugin.imageUrl && !hasBrokenImage(plugin)) {
<img <img
[src]="plugin.imageUrl" [src]="plugin.imageUrl"
[alt]="plugin.title" [alt]="plugin.title"
(error)="hideBrokenImage($event)" (error)="hideBrokenImage($event, plugin)"
loading="lazy"
referrerpolicy="no-referrer"
class="h-full w-full object-cover" class="h-full w-full object-cover"
/> />
} @else { } @else {

View File

@@ -155,6 +155,7 @@ export class PluginStoreComponent implements OnInit {
readonly serverInstallOptional = signal(false); readonly serverInstallOptional = signal(false);
readonly serverInstallError = signal<string | null>(null); readonly serverInstallError = signal<string | null>(null);
readonly serverInstallBusy = signal(false); readonly serverInstallBusy = signal(false);
readonly brokenImageKeys = signal<Set<string>>(new Set());
private destroyed = false; private destroyed = false;
private readonly destroyRef = inject(DestroyRef); private readonly destroyRef = inject(DestroyRef);
@@ -530,12 +531,26 @@ export class PluginStoreComponent implements OnInit {
return `${plugin.sourceUrl}:${plugin.id}`; return `${plugin.sourceUrl}:${plugin.id}`;
} }
hideBrokenImage(event: Event): void { hideBrokenImage(event: Event, plugin: PluginStoreEntry): void {
const image = event.target as HTMLImageElement | null; const image = event.target as HTMLImageElement | null;
if (image) { if (image) {
image.hidden = true; image.hidden = true;
} }
const key = this.imageKey(plugin);
const next = new Set(this.brokenImageKeys());
next.add(key);
this.brokenImageKeys.set(next);
}
hasBrokenImage(plugin: PluginStoreEntry): boolean {
return this.brokenImageKeys().has(this.imageKey(plugin));
}
private imageKey(plugin: PluginStoreEntry): string {
return `${plugin.sourceUrl}:${plugin.id}:${plugin.imageUrl ?? ''}`;
} }
trackServer(index: number, server: Room): string { trackServer(index: number, server: Room): string {

View File

@@ -22,17 +22,32 @@
<h1 class="min-w-0 flex-1 truncate text-center text-base font-semibold text-foreground">Search</h1> <h1 class="min-w-0 flex-1 truncate text-center text-base font-semibold text-foreground">Search</h1>
<button @if (!currentUser()) {
type="button" <button
aria-label="Settings" type="button"
class="grid h-11 w-11 shrink-0 place-items-center rounded-lg border border-border bg-secondary text-muted-foreground transition-colors hover:bg-secondary/80" aria-label="Log in"
(click)="openSettings()" class="inline-flex h-11 shrink-0 items-center justify-center gap-1.5 rounded-lg bg-primary px-3 text-sm font-semibold text-primary-foreground transition-colors hover:bg-primary/90"
> (click)="goLogin()"
<ng-icon >
name="lucideSettings" <ng-icon
class="h-5 w-5" name="lucideLogIn"
/> class="h-5 w-5"
</button> />
<span>Log in</span>
</button>
} @else {
<button
type="button"
aria-label="Settings"
class="grid h-11 w-11 shrink-0 place-items-center rounded-lg border border-border bg-secondary text-muted-foreground transition-colors hover:bg-secondary/80"
(click)="openSettings()"
>
<ng-icon
name="lucideSettings"
class="h-5 w-5"
/>
</button>
}
</div> </div>
<div class="flex flex-row items-center gap-2"> <div class="flex flex-row items-center gap-2">

View File

@@ -27,7 +27,8 @@ import {
lucideGlobe, lucideGlobe,
lucidePlus, lucidePlus,
lucideSettings, lucideSettings,
lucideChevronDown lucideChevronDown,
lucideLogIn
} from '@ng-icons/lucide'; } from '@ng-icons/lucide';
import { RoomsActions } from '../../../../store/rooms/rooms.actions'; import { RoomsActions } from '../../../../store/rooms/rooms.actions';
@@ -94,7 +95,8 @@ interface JoinPluginConsentDialog {
lucideGlobe, lucideGlobe,
lucidePlus, lucidePlus,
lucideSettings, lucideSettings,
lucideChevronDown lucideChevronDown,
lucideLogIn
}) })
], ],
templateUrl: './server-search.component.html' templateUrl: './server-search.component.html'
@@ -246,6 +248,11 @@ export class ServerSearchComponent implements OnInit {
this.settingsModal.open('network'); this.settingsModal.open('network');
} }
/** Navigate to the login screen, preserving the search route as the return URL. */
goLogin(): void {
this.router.navigate(['/login'], { queryParams: { returnUrl: '/search' } });
}
/** /**
* Navigate back from the Search page to the chat-room view (server rail + current server). * Navigate back from the Search page to the chat-room view (server rail + current server).
* Prefers the current room; falls back to the first saved room. No-op when the user has not * Prefers the current room; falls back to the first saved room. No-op when the user has not

View File

@@ -1,4 +1,4 @@
<div class="flex w-full flex-wrap items-center justify-center gap-3 rounded-2xl bg-background/75 px-4 py-3 backdrop-blur"> <div class="flex w-full flex-wrap items-center justify-center gap-3 px-3 py-3 sm:px-4">
@if (!connected()) { @if (!connected()) {
<button <button
type="button" type="button"

View File

@@ -1,11 +1,6 @@
<article <article
class="flex aspect-square min-w-0 flex-col items-center justify-center overflow-hidden rounded-2xl border border-border/80 bg-card/80 text-center shadow-sm backdrop-blur" class="flex min-w-0 flex-col items-center justify-center overflow-hidden rounded-xl text-center"
[class.w-[11rem]]="compact()" [ngClass]="compact() ? 'min-h-[9.5rem] w-[12rem] shrink-0 p-3 sm:w-[14rem] sm:p-4' : 'min-h-[14rem] w-full p-3 sm:min-h-[17rem] sm:p-[clamp(1.25rem,4vw,2rem)]'"
[class.shrink-0]="compact()"
[class.p-4]="compact()"
[class.sm:w-[12.5rem]]="compact()"
[class.w-full]="!compact()"
[class.p-[clamp(1rem,4vw,1.5rem)]]="!compact()"
> >
<div <div
class="relative h-[var(--participant-avatar-size)] w-[var(--participant-avatar-size)] rounded-full ring-2 transition-all duration-150 sm:h-[var(--participant-avatar-size-sm)] sm:w-[var(--participant-avatar-size-sm)]" class="relative h-[var(--participant-avatar-size)] w-[var(--participant-avatar-size)] rounded-full ring-2 transition-all duration-150 sm:h-[var(--participant-avatar-size-sm)] sm:w-[var(--participant-avatar-size-sm)]"
@@ -67,16 +62,9 @@
@if (connected()) { @if (connected()) {
<span <span
class="absolute rounded-full border-card" class="absolute rounded-full border-card"
[class.bottom-3]="compact()" [ngClass]="
[class.right-3]="compact()" compact() ? 'bottom-1 right-1 h-4 w-4 border-[3px] sm:bottom-3 sm:right-3' : 'bottom-1 right-1 h-5 w-5 border-4 sm:bottom-5 sm:right-5'
[class.h-4]="compact()" "
[class.w-4]="compact()"
[class.border-[3px]]="compact()"
[class.bottom-5]="!compact()"
[class.right-5]="!compact()"
[class.h-5]="!compact()"
[class.w-5]="!compact()"
[class.border-4]="!compact()"
[class.bg-emerald-400]="speaking()" [class.bg-emerald-400]="speaking()"
[class.bg-muted-foreground]="!speaking()" [class.bg-muted-foreground]="!speaking()"
></span> ></span>

View File

@@ -20,11 +20,11 @@ export class PrivateCallParticipantCardComponent {
readonly compact = input(false); readonly compact = input(false);
avatarSize(): string { avatarSize(): string {
return this.compact() ? '5rem' : 'clamp(4.25rem, 22vw, 10rem)'; return this.compact() ? '5.75rem' : 'clamp(6.5rem, 38vw, 13rem)';
} }
avatarSizeSm(): string { avatarSizeSm(): string {
return this.compact() ? '6rem' : this.avatarSize(); return this.compact() ? '6rem' : 'clamp(4.25rem, 22vw, 10rem)';
} }
participantInitial(): string { participantInitial(): string {

View File

@@ -1,9 +1,30 @@
@if (isMobile()) {
<swiper-container
class="block h-full min-h-0 w-full"
direction="vertical"
slides-per-view="1"
space-between="0"
initial-slide="1"
threshold="10"
resistance-ratio="0"
(swiperslidechange)="onMobileCallSlideChange($event)"
>
<swiper-slide class="block h-full w-full" />
<swiper-slide class="block h-full w-full">
<ng-container *ngTemplateOutlet="privateCallSurface" />
</swiper-slide>
</swiper-container>
} @else {
<ng-container *ngTemplateOutlet="privateCallSurface" />
}
<ng-template #privateCallSurface>
<section <section
class="grid h-full min-h-0 bg-background lg:grid-cols-[minmax(0,1fr)_var(--private-call-chat-width)]" class="grid h-full min-h-0 bg-background lg:grid-cols-[minmax(0,1fr)_var(--private-call-chat-width)]"
[style.--private-call-chat-width]="chatWidthPx() + 'px'" [style.--private-call-chat-width]="chatWidthPx() + 'px'"
> >
<main class="flex min-h-0 min-w-0 flex-col overflow-hidden bg-[radial-gradient(circle_at_top,rgba(16,185,129,0.10),transparent_34rem)]"> <main class="flex min-h-0 min-w-0 flex-col overflow-hidden bg-[radial-gradient(circle_at_top,rgba(16,185,129,0.10),transparent_34rem)]">
<header class="flex min-h-16 shrink-0 items-center justify-between gap-3 border-b border-border/70 bg-background/80 px-5 backdrop-blur"> <header class="flex min-h-16 shrink-0 items-center justify-between gap-3 border-b border-border/70 bg-background/80 px-3 backdrop-blur sm:px-5">
<div class="flex min-w-0 items-center gap-3"> <div class="flex min-w-0 items-center gap-3">
<div class="grid h-10 w-10 shrink-0 place-items-center rounded-2xl bg-emerald-500/10 text-emerald-500"> <div class="grid h-10 w-10 shrink-0 place-items-center rounded-2xl bg-emerald-500/10 text-emerald-500">
<ng-icon <ng-icon
@@ -26,8 +47,22 @@
@if (session()) { @if (session()) {
<div class="flex items-center gap-2"> <div class="flex items-center gap-2">
@if (isMobile()) {
<button
type="button"
class="grid h-10 w-10 place-items-center rounded-full bg-secondary text-foreground transition-colors hover:bg-secondary/80"
(click)="minimizeCall()"
aria-label="Minimize call"
title="Minimize call"
>
<ng-icon
name="lucideX"
class="h-5 w-5"
/>
</button>
}
<select <select
class="h-9 max-w-44 rounded-md border border-border bg-secondary px-2 text-sm text-foreground" class="hidden h-9 max-w-44 rounded-md border border-border bg-secondary px-2 text-sm text-foreground sm:block"
[ngModel]="inviteUserId()" [ngModel]="inviteUserId()"
(ngModelChange)="inviteUserId.set($event)" (ngModelChange)="inviteUserId.set($event)"
aria-label="Add user to call" aria-label="Add user to call"
@@ -39,7 +74,7 @@
</select> </select>
<button <button
type="button" type="button"
class="grid h-9 w-9 place-items-center rounded-md bg-secondary text-foreground transition-colors hover:bg-secondary/80 disabled:opacity-50" class="hidden h-9 w-9 place-items-center rounded-md bg-secondary text-foreground transition-colors hover:bg-secondary/80 disabled:opacity-50 sm:grid"
[disabled]="!inviteUserId()" [disabled]="!inviteUserId()"
(click)="inviteSelectedUser()" (click)="inviteSelectedUser()"
aria-label="Add user" aria-label="Add user"
@@ -55,8 +90,8 @@
</header> </header>
@if (session()) { @if (session()) {
<div class="flex min-h-0 flex-1 flex-col overflow-hidden px-4 py-4 sm:px-5"> <div class="flex min-h-0 flex-1 flex-col overflow-hidden px-3 py-3 sm:px-5 sm:py-4">
<div class="relative min-h-0 flex-1 overflow-hidden rounded-2xl border border-border/80 bg-card/45 shadow-sm"> <div class="relative min-h-0 flex-1 overflow-hidden">
@if (activeShares().length > 0) { @if (activeShares().length > 0) {
@if (focusedShare()) { @if (focusedShare()) {
@if (hasMultipleShares()) { @if (hasMultipleShares()) {
@@ -103,17 +138,18 @@
</div> </div>
} }
} @else { } @else {
<div class="flex h-full min-h-0 items-center justify-center p-4 sm:p-6"> <div class="flex h-full min-h-0 items-center justify-center p-1 sm:p-5">
<div <div
class="grid w-full max-w-5xl grid-cols-[repeat(auto-fit,minmax(min(10rem,100%),1fr))] items-stretch justify-center gap-3 sm:grid-cols-[repeat(auto-fit,minmax(min(13rem,100%),1fr))] sm:gap-5 lg:gap-7" class="grid w-full max-w-7xl grid-cols-[repeat(auto-fit,minmax(min(11rem,100%),1fr))] items-stretch justify-center gap-3 sm:grid-cols-[repeat(auto-fit,minmax(min(16rem,100%),1fr))] sm:gap-5 lg:gap-7"
> >
<app-private-call-participant-card @for (user of participantUsers(); track trackUserKey($index, user)) {
*ngFor="let user of participantUsers(); trackBy: trackUserKey" <app-private-call-participant-card
[user]="user" [user]="user"
[connected]="isParticipantConnected(user)" [connected]="isParticipantConnected(user)"
[speaking]="isSpeaking(user)" [speaking]="isSpeaking(user)"
[issueLabel]="participantIssueLabel(user)" [issueLabel]="participantIssueLabel(user)"
></app-private-call-participant-card> />
}
</div> </div>
</div> </div>
} }
@@ -122,14 +158,15 @@
@if (activeShares().length > 0) { @if (activeShares().length > 0) {
<div class="shrink-0 pt-4"> <div class="shrink-0 pt-4">
<div class="flex w-full items-stretch gap-3 overflow-x-auto pb-1"> <div class="flex w-full items-stretch gap-3 overflow-x-auto pb-1">
<app-private-call-participant-card @for (user of participantUsers(); track trackUserKey($index, user)) {
*ngFor="let user of participantUsers(); trackBy: trackUserKey" <app-private-call-participant-card
[user]="user" [user]="user"
[connected]="isParticipantConnected(user)" [connected]="isParticipantConnected(user)"
[speaking]="isSpeaking(user)" [speaking]="isSpeaking(user)"
[issueLabel]="participantIssueLabel(user)" [issueLabel]="participantIssueLabel(user)"
[compact]="true" [compact]="true"
></app-private-call-participant-card> />
}
@if (hasMultipleShares()) { @if (hasMultipleShares()) {
@for (share of focusedShare() ? thumbnailShares() : activeShares(); track share.id) { @for (share of focusedShare() ? thumbnailShares() : activeShares(); track share.id) {
@@ -166,7 +203,7 @@
(cameraToggled)="toggleCamera()" (cameraToggled)="toggleCamera()"
(screenShareToggled)="toggleScreenShare()" (screenShareToggled)="toggleScreenShare()"
(leaveRequested)="leave()" (leaveRequested)="leave()"
></app-private-call-controls> />
</div> </div>
</div> </div>
} @else { } @else {
@@ -191,6 +228,7 @@
/> />
</aside> </aside>
</section> </section>
</ng-template>
@if (showScreenShareQualityDialog()) { @if (showScreenShareQualityDialog()) {
<app-screen-share-quality-dialog <app-screen-share-quality-dialog

View File

@@ -1,11 +1,13 @@
/* eslint-disable @typescript-eslint/member-ordering */ /* eslint-disable @typescript-eslint/member-ordering */
import { import {
CUSTOM_ELEMENTS_SCHEMA,
Component, Component,
DestroyRef, DestroyRef,
HostListener, HostListener,
computed, computed,
effect, effect,
inject, inject,
input,
signal, signal,
untracked untracked
} from '@angular/core'; } from '@angular/core';
@@ -17,6 +19,7 @@ import { Store } from '@ngrx/store';
import { NgIcon, provideIcons } from '@ng-icons/core'; import { NgIcon, provideIcons } from '@ng-icons/core';
import { import {
lucidePhone, lucidePhone,
lucideX,
lucideUsers, lucideUsers,
lucideUserPlus lucideUserPlus
} from '@ng-icons/lucide'; } from '@ng-icons/lucide';
@@ -39,6 +42,7 @@ import {
} from '../../domains/screen-share'; } from '../../domains/screen-share';
import { loadVoiceSettingsFromStorage, saveVoiceSettingsToStorage } from '../../domains/voice-session'; import { loadVoiceSettingsFromStorage, saveVoiceSettingsToStorage } from '../../domains/voice-session';
import { ScreenShareQualityDialogComponent } from '../../shared'; import { ScreenShareQualityDialogComponent } from '../../shared';
import { ViewportService } from '../../core/platform';
import { selectAllUsers, selectCurrentUser } from '../../store/users/users.selectors'; import { selectAllUsers, selectCurrentUser } from '../../store/users/users.selectors';
import { UsersActions } from '../../store/users/users.actions'; import { UsersActions } from '../../store/users/users.actions';
import { User } from '../../shared-kernel'; import { User } from '../../shared-kernel';
@@ -60,9 +64,12 @@ import { PrivateCallParticipantCardComponent } from './private-call-participant-
ScreenShareQualityDialogComponent, ScreenShareQualityDialogComponent,
VoiceWorkspaceStreamTileComponent VoiceWorkspaceStreamTileComponent
], ],
schemas: [CUSTOM_ELEMENTS_SCHEMA],
host: { class: 'block h-full w-full' },
viewProviders: [ viewProviders: [
provideIcons({ provideIcons({
lucidePhone, lucidePhone,
lucideX,
lucideUsers, lucideUsers,
lucideUserPlus lucideUserPlus
}) })
@@ -79,13 +86,18 @@ export class PrivateCallComponent {
private readonly voiceActivity = inject(VoiceActivityService); private readonly voiceActivity = inject(VoiceActivityService);
private readonly playback = inject(VoicePlaybackService); private readonly playback = inject(VoicePlaybackService);
private readonly screenShare = inject(ScreenShareFacade); private readonly screenShare = inject(ScreenShareFacade);
private readonly viewport = inject(ViewportService);
private chatResizing = false; private chatResizing = false;
readonly allUsers = this.store.selectSignal(selectAllUsers); readonly allUsers = this.store.selectSignal(selectAllUsers);
readonly currentUser = this.store.selectSignal(selectCurrentUser); readonly currentUser = this.store.selectSignal(selectCurrentUser);
readonly callId = toSignal(this.route.paramMap.pipe(map((params) => params.get('callId'))), { readonly isMobile = this.viewport.isMobile;
readonly callIdInput = input<string | null>(null);
readonly overlayMode = input(false);
readonly routeCallId = toSignal(this.route.paramMap.pipe(map((params) => params.get('callId'))), {
initialValue: this.route.snapshot.paramMap.get('callId') initialValue: this.route.snapshot.paramMap.get('callId')
}); });
readonly callId = computed(() => this.callIdInput() ?? this.routeCallId());
readonly session = computed(() => this.calls.sessionById(this.callId())); readonly session = computed(() => this.calls.sessionById(this.callId()));
readonly participantUsers = computed(() => { readonly participantUsers = computed(() => {
const session = this.session(); const session = this.session();
@@ -146,13 +158,11 @@ export class PrivateCallComponent {
} }
for (const user of this.participantUsers()) { for (const user of this.participantUsers()) {
const peerKey = this.getPeerKeyCandidates(user).find( const peerKey =
(candidate) => candidate !== localPeerKey this.getPeerKeyCandidates(user).find(
&& ( (candidate) =>
!!this.screenShare.getRemoteScreenShareStream(candidate) candidate !== localPeerKey && (!!this.screenShare.getRemoteScreenShareStream(candidate) || !!this.voice.getRemoteCameraStream(candidate))
|| !!this.voice.getRemoteCameraStream(candidate) ) ?? this.userKey(user);
)
) ?? this.userKey(user);
if (peerKey === localPeerKey) { if (peerKey === localPeerKey) {
continue; continue;
@@ -192,9 +202,7 @@ export class PrivateCallComponent {
return null; return null;
}); });
readonly focusedShare = computed( readonly focusedShare = computed(() => this.activeShares().find((share) => share.id === this.focusedShareId()) ?? null);
() => this.activeShares().find((share) => share.id === this.focusedShareId()) ?? null
);
readonly thumbnailShares = computed(() => { readonly thumbnailShares = computed(() => {
const focusedShareId = this.focusedShareId(); const focusedShareId = this.focusedShareId();
@@ -217,14 +225,31 @@ export class PrivateCallComponent {
const session = this.session(); const session = this.session();
if (session && !this.calls.hasOngoingActivity(session)) { if (session && !this.calls.hasOngoingActivity(session)) {
if (this.overlayMode()) {
untracked(() => this.calls.closeMobileCallOverlay());
return;
}
untracked(() => void this.router.navigate(['/dm', session.conversationId], { replaceUrl: true })); untracked(() => void this.router.navigate(['/dm', session.conversationId], { replaceUrl: true }));
} }
}); });
effect(() => {
const callId = this.callId();
const session = this.session();
if (callId && session?.conversationId && this.isMobile() && !this.overlayMode()) {
untracked(() => {
void this.calls.openMobileCallOverlay(callId);
void this.router.navigate(['/pm', session.conversationId], { replaceUrl: true });
});
}
});
effect(() => { effect(() => {
const session = this.session(); const session = this.session();
const currentUserId = this.currentUserKey(); const currentUserId = this.currentUserKey();
const peerIds = (session ? this.remoteParticipantPeerIds(session, currentUserId) : []); const peerIds = session ? this.remoteParticipantPeerIds(session, currentUserId) : [];
this.screenShare.syncRemoteScreenShareRequests(peerIds, this.isConnected() && !!session && session.status === 'connected'); this.screenShare.syncRemoteScreenShareRequests(peerIds, this.isConnected() && !!session && session.status === 'connected');
}); });
@@ -240,13 +265,9 @@ export class PrivateCallComponent {
this.untrackLocalMic(); this.untrackLocalMic();
}); });
this.screenShare.onRemoteStream this.screenShare.onRemoteStream.pipe(takeUntilDestroyed(this.destroyRef)).subscribe(() => this.bumpRemoteStreamRevision());
.pipe(takeUntilDestroyed(this.destroyRef))
.subscribe(() => this.bumpRemoteStreamRevision());
this.screenShare.onPeerDisconnected this.screenShare.onPeerDisconnected.pipe(takeUntilDestroyed(this.destroyRef)).subscribe(() => this.bumpRemoteStreamRevision());
.pipe(takeUntilDestroyed(this.destroyRef))
.subscribe(() => this.bumpRemoteStreamRevision());
this.destroyRef.onDestroy(() => { this.destroyRef.onDestroy(() => {
this.screenShare.syncRemoteScreenShareRequests([], false); this.screenShare.syncRemoteScreenShareRequests([], false);
@@ -284,10 +305,38 @@ export class PrivateCallComponent {
} }
this.calls.leaveCall(session.callId); this.calls.leaveCall(session.callId);
this.calls.closeMobileCallOverlay();
this.untrackLocalMic(); this.untrackLocalMic();
if (!this.overlayMode()) {
void this.router.navigate(['/dm', session.conversationId]);
}
}
minimizeCall(): void {
const session = this.session();
if (!session) {
return;
}
if (this.overlayMode()) {
this.calls.closeMobileCallOverlay();
return;
}
void this.router.navigate(['/dm', session.conversationId]); void this.router.navigate(['/dm', session.conversationId]);
} }
onMobileCallSlideChange(event: Event): void {
const detail = (event as CustomEvent).detail;
const swiper = Array.isArray(detail) ? detail[0] : detail;
if (this.isMobile() && swiper?.activeIndex === 0) {
this.minimizeCall();
}
}
toggleMute(): void { toggleMute(): void {
this.voice.toggleMute(!this.isMuted()); this.voice.toggleMute(!this.isMuted());
this.broadcastLocalVoiceState(); this.broadcastLocalVoiceState();
@@ -378,12 +427,10 @@ export class PrivateCallComponent {
return false; return false;
} }
return !!session.participants[userId]?.joined return (
|| !!( !!session.participants[userId]?.joined ||
user.voiceState?.isConnected !!(user.voiceState?.isConnected && user.voiceState.roomId === session.callId && user.voiceState.serverId === session.callId)
&& user.voiceState.roomId === session.callId );
&& user.voiceState.serverId === session.callId
);
} }
participantIssueLabel(user: User): string | null { participantIssueLabel(user: User): string | null {
@@ -437,16 +484,18 @@ export class PrivateCallComponent {
return; return;
} }
this.store.dispatch(UsersActions.updateVoiceState({ this.store.dispatch(
userId: user.id, UsersActions.updateVoiceState({
voiceState: { userId: user.id,
isConnected: this.isConnected(), voiceState: {
isMuted: this.isMuted(), isConnected: this.isConnected(),
isDeafened: this.isDeafened(), isMuted: this.isMuted(),
roomId: session.callId, isDeafened: this.isDeafened(),
serverId: session.callId roomId: session.callId,
} serverId: session.callId
})); }
})
);
} }
private remoteParticipantPeerIds(session: DirectCallSession, currentUserId: string): string[] { private remoteParticipantPeerIds(session: DirectCallSession, currentUserId: string): string[] {

View File

@@ -17,6 +17,7 @@
<div class="flex min-h-0 flex-1 overflow-hidden border-l border-border bg-card"> <div class="flex min-h-0 flex-1 overflow-hidden border-l border-border bg-card">
<app-rooms-side-panel <app-rooms-side-panel
panelMode="channels" panelMode="channels"
(textChannelSelected)="setMobilePage('main')"
class="block h-full w-full" class="block h-full w-full"
/> />
</div> </div>
@@ -52,6 +53,20 @@
<p class="truncate text-sm font-semibold text-foreground">{{ currentRoom()?.name }}</p> <p class="truncate text-sm font-semibold text-foreground">{{ currentRoom()?.name }}</p>
} }
</div> </div>
@if (activeCall()) {
<button
type="button"
(click)="openActiveCall()"
class="grid h-11 w-11 place-items-center rounded-lg text-emerald-600 transition-colors hover:bg-emerald-500/10 hover:text-emerald-500"
aria-label="Return to call"
title="Return to call"
>
<ng-icon
name="lucidePhoneCall"
class="h-5 w-5"
/>
</button>
}
<button <button
type="button" type="button"
(click)="setMobilePage('members')" (click)="setMobilePage('members')"
@@ -208,4 +223,3 @@
</div> </div>
} }
</div> </div>

View File

@@ -20,7 +20,8 @@ import {
lucideUsers, lucideUsers,
lucideMenu, lucideMenu,
lucideX, lucideX,
lucideChevronLeft lucideChevronLeft,
lucidePhoneCall
} from '@ng-icons/lucide'; } from '@ng-icons/lucide';
import { ChatMessagesComponent } from '../../../domains/chat/feature/chat-messages/chat-messages.component'; import { ChatMessagesComponent } from '../../../domains/chat/feature/chat-messages/chat-messages.component';
@@ -38,6 +39,7 @@ import { ViewportService } from '../../../core/platform';
import { selectIsCurrentUserAdmin } from '../../../store/users/users.selectors'; import { selectIsCurrentUserAdmin } from '../../../store/users/users.selectors';
import { VoiceWorkspaceService } from '../../../domains/voice-session'; import { VoiceWorkspaceService } from '../../../domains/voice-session';
import { ThemeNodeDirective, ThemeService } from '../../../domains/theme'; import { ThemeNodeDirective, ThemeService } from '../../../domains/theme';
import { DirectCallService } from '../../../domains/direct-call';
/** Mobile-only page identifier within the chat-room view. */ /** Mobile-only page identifier within the chat-room view. */
export type ChatRoomMobilePage = 'channels' | 'main' | 'members'; export type ChatRoomMobilePage = 'channels' | 'main' | 'members';
@@ -77,7 +79,8 @@ interface SwiperElement extends HTMLElement {
lucideUsers, lucideUsers,
lucideMenu, lucideMenu,
lucideX, lucideX,
lucideChevronLeft lucideChevronLeft,
lucidePhoneCall
}) })
], ],
schemas: [CUSTOM_ELEMENTS_SCHEMA], schemas: [CUSTOM_ELEMENTS_SCHEMA],
@@ -96,6 +99,7 @@ export class ChatRoomComponent {
private readonly settingsModal = inject(SettingsModalService); private readonly settingsModal = inject(SettingsModalService);
private readonly theme = inject(ThemeService); private readonly theme = inject(ThemeService);
private readonly viewport = inject(ViewportService); private readonly viewport = inject(ViewportService);
private readonly directCalls = inject(DirectCallService);
private readonly zone = inject(NgZone); private readonly zone = inject(NgZone);
private voiceWorkspace = inject(VoiceWorkspaceService); private voiceWorkspace = inject(VoiceWorkspaceService);
private lastSeenChannelId: string | null = null; private lastSeenChannelId: string | null = null;
@@ -128,6 +132,12 @@ export class ChatRoomComponent {
}); });
isVoiceWorkspaceExpanded = this.voiceWorkspace.isExpanded; isVoiceWorkspaceExpanded = this.voiceWorkspace.isExpanded;
hasTextChannels = computed(() => this.textChannels().length > 0); hasTextChannels = computed(() => this.textChannels().length > 0);
activeCall = computed(() => {
const currentSession = this.directCalls.currentSession();
const visibleSessions = this.directCalls.visibleActiveSessions();
return visibleSessions.find((session) => session.callId === currentSession?.callId) ?? visibleSessions[0] ?? null;
});
roomLayoutStyles = computed(() => this.theme.getLayoutContainerStyles('roomLayout')); roomLayoutStyles = computed(() => this.theme.getLayoutContainerStyles('roomLayout'));
channelsPanelLayoutStyles = computed(() => this.theme.getLayoutItemStyles('chatRoomChannelsPanel')); channelsPanelLayoutStyles = computed(() => this.theme.getLayoutItemStyles('chatRoomChannelsPanel'));
mainPanelLayoutStyles = computed(() => this.theme.getLayoutItemStyles('chatRoomMainPanel')); mainPanelLayoutStyles = computed(() => this.theme.getLayoutItemStyles('chatRoomMainPanel'));
@@ -209,6 +219,14 @@ export class ChatRoomComponent {
this.mobilePage.set(page); this.mobilePage.set(page);
} }
openActiveCall(): void {
const call = this.activeCall();
if (call) {
void this.directCalls.openCallView(call.callId);
}
}
/** Open the settings modal to the Server admin page for the current room. */ /** Open the settings modal to the Server admin page for the current room. */
toggleAdminPanel() { toggleAdminPanel() {
const room = this.currentRoom(); const room = this.currentRoom();

View File

@@ -5,6 +5,7 @@ import {
computed, computed,
input, input,
OnDestroy, OnDestroy,
output,
signal signal
} from '@angular/core'; } from '@angular/core';
import { CommonModule } from '@angular/common'; import { CommonModule } from '@angular/common';
@@ -138,6 +139,7 @@ export class RoomsSidePanelComponent implements OnDestroy {
readonly panelMode = input<PanelMode>('channels'); readonly panelMode = input<PanelMode>('channels');
readonly showVoiceControls = input(true); readonly showVoiceControls = input(true);
readonly textChannelSelected = output<string>();
showFloatingControls = this.voiceSessionService.showFloatingControls; showFloatingControls = this.voiceSessionService.showFloatingControls;
isVoiceWorkspaceExpanded = this.voiceWorkspace.isExpanded; isVoiceWorkspaceExpanded = this.voiceWorkspace.isExpanded;
onlineUsers = this.store.selectSignal(selectOnlineUsers); onlineUsers = this.store.selectSignal(selectOnlineUsers);
@@ -379,6 +381,7 @@ export class RoomsSidePanelComponent implements OnDestroy {
this.voiceWorkspace.showChat(); this.voiceWorkspace.showChat();
this.store.dispatch(RoomsActions.selectChannel({ channelId })); this.store.dispatch(RoomsActions.selectChannel({ channelId }));
this.textChannelSelected.emit(channelId);
} }
openChannelContextMenu(evt: MouseEvent, channel: Channel) { openChannelContextMenu(evt: MouseEvent, channel: Channel) {

View File

@@ -63,15 +63,45 @@
</div> </div>
</div> </div>
@if (!item().isLocal && item().hasAudio) { @if (canControlStreamAudio()) {
<div class="flex min-w-32 items-center gap-2 rounded-full border border-white/10 bg-black/35 px-2.5 py-1.5 text-white/75">
<button
type="button"
class="inline-flex h-7 w-7 shrink-0 items-center justify-center rounded-full text-white/75 transition hover:bg-white/10 hover:text-white"
[title]="muted() ? 'Unmute stream audio' : 'Mute stream audio'"
(click)="toggleMuted(); $event.stopPropagation()"
>
<ng-icon
[name]="muted() ? 'lucideVolumeX' : 'lucideVolume2'"
class="h-4 w-4"
/>
</button>
<input
type="range"
min="0"
max="100"
[value]="volume()"
class="w-20 accent-primary sm:w-28"
aria-label="Stream volume"
(click)="$event.stopPropagation()"
(input)="updateVolume($event)"
/>
<span class="w-9 text-right text-xs tabular-nums">{{ muted() ? 'Off' : volume() + '%' }}</span>
</div>
}
@if (isMobile() && item().kind === 'screen') {
<button <button
type="button" type="button"
class="inline-flex h-9 w-9 items-center justify-center rounded-full border border-white/10 bg-black/45 text-white/75 transition hover:bg-black/60 hover:text-white" class="inline-flex h-9 w-9 items-center justify-center rounded-full border border-white/10 bg-black/45 text-white/75 transition hover:bg-black/60 hover:text-white"
[title]="muted() ? 'Unmute stream audio' : 'Mute stream audio'" title="Rotate to landscape"
(click)="toggleMuted(); $event.stopPropagation()" aria-label="Rotate to landscape"
(click)="enterLandscapeFullscreen($event)"
> >
<ng-icon <ng-icon
[name]="muted() ? 'lucideVolumeX' : 'lucideVolume2'" name="lucideRotateCw"
class="h-4 w-4" class="h-4 w-4"
/> />
</button> </button>
@@ -92,6 +122,72 @@
</div> </div>
} }
@if (immersive() && item().kind === 'screen' && !isFullscreen()) {
<div class="absolute inset-x-3 bottom-3 z-20 sm:inset-x-5 sm:bottom-5">
<div class="mx-auto flex w-full max-w-3xl flex-wrap items-center justify-center gap-2 rounded-2xl border border-white/10 bg-black/55 px-3 py-3 text-white/80 shadow-2xl backdrop-blur-lg sm:gap-3 sm:px-4">
@if (canControlStreamAudio()) {
<div class="flex min-w-0 flex-1 items-center gap-2 rounded-full bg-white/10 px-2.5 py-2 sm:max-w-md">
<button
type="button"
class="grid h-9 w-9 shrink-0 place-items-center rounded-full text-white/85 transition hover:bg-white/10 hover:text-white"
[title]="muted() ? 'Unmute stream audio' : 'Mute stream audio'"
[attr.aria-label]="muted() ? 'Unmute stream audio' : 'Mute stream audio'"
(click)="toggleMuted(); $event.stopPropagation()"
>
<ng-icon
[name]="muted() ? 'lucideVolumeX' : 'lucideVolume2'"
class="h-4 w-4"
/>
</button>
<input
type="range"
min="0"
max="100"
[value]="volume()"
class="min-w-0 flex-1 accent-primary"
aria-label="Screen share volume"
(click)="$event.stopPropagation()"
(input)="updateVolume($event)"
/>
<span class="w-10 text-right text-xs font-semibold tabular-nums text-white/70">{{ muted() ? 'Off' : volume() + '%' }}</span>
</div>
} @else {
<div class="min-w-0 flex-1 px-2 text-center text-xs font-medium text-white/65 sm:text-left">No screen audio</div>
}
<button
type="button"
class="grid h-11 w-11 place-items-center rounded-full bg-white/10 text-white transition hover:bg-white/15"
[title]="isFullscreen() ? 'Exit fullscreen' : 'Fullscreen'"
[attr.aria-label]="isFullscreen() ? 'Exit fullscreen' : 'Fullscreen'"
(click)="toggleFullscreen($event)"
>
<ng-icon
name="lucideMaximize"
class="h-5 w-5"
/>
</button>
@if (isMobile()) {
<button
type="button"
class="grid h-11 w-11 place-items-center rounded-full bg-white/10 text-white transition hover:bg-white/15"
title="Rotate to landscape"
aria-label="Rotate to landscape"
(click)="enterLandscapeFullscreen($event)"
>
<ng-icon
name="lucideRotateCw"
class="h-5 w-5"
/>
</button>
}
</div>
</div>
}
@if (mini()) { @if (mini()) {
<div class="absolute inset-x-0 bottom-0 p-2"> <div class="absolute inset-x-0 bottom-0 p-2">
<div class="rounded-xl border border-white/10 bg-black/55 px-2.5 py-2 backdrop-blur-md"> <div class="rounded-xl border border-white/10 bg-black/55 px-2.5 py-2 backdrop-blur-md">

View File

@@ -17,12 +17,14 @@ import {
lucideMaximize, lucideMaximize,
lucideMinimize, lucideMinimize,
lucideMonitor, lucideMonitor,
lucideRotateCw,
lucideVideo, lucideVideo,
lucideVolume2, lucideVolume2,
lucideVolumeX lucideVolumeX
} from '@ng-icons/lucide'; } from '@ng-icons/lucide';
import { UserAvatarComponent } from '../../../../shared'; import { UserAvatarComponent } from '../../../../shared';
import { ViewportService } from '../../../../core/platform';
import { VoiceWorkspacePlaybackService } from '../voice-workspace-playback.service'; import { VoiceWorkspacePlaybackService } from '../voice-workspace-playback.service';
import { VoiceWorkspaceStreamItem } from '../voice-workspace.models'; import { VoiceWorkspaceStreamItem } from '../voice-workspace.models';
@@ -39,6 +41,7 @@ import { VoiceWorkspaceStreamItem } from '../voice-workspace.models';
lucideMaximize, lucideMaximize,
lucideMinimize, lucideMinimize,
lucideMonitor, lucideMonitor,
lucideRotateCw,
lucideVideo, lucideVideo,
lucideVolume2, lucideVolume2,
lucideVolumeX lucideVolumeX
@@ -51,6 +54,7 @@ import { VoiceWorkspaceStreamItem } from '../voice-workspace.models';
}) })
export class VoiceWorkspaceStreamTileComponent implements OnDestroy { export class VoiceWorkspaceStreamTileComponent implements OnDestroy {
private readonly workspacePlayback = inject(VoiceWorkspacePlaybackService); private readonly workspacePlayback = inject(VoiceWorkspacePlaybackService);
private readonly viewport = inject(ViewportService);
private fullscreenHeaderHideTimeoutId: ReturnType<typeof setTimeout> | null = null; private fullscreenHeaderHideTimeoutId: ReturnType<typeof setTimeout> | null = null;
readonly item = input.required<VoiceWorkspaceStreamItem>(); readonly item = input.required<VoiceWorkspaceStreamItem>();
@@ -64,6 +68,7 @@ export class VoiceWorkspaceStreamTileComponent implements OnDestroy {
readonly videoRef = viewChild<ElementRef<HTMLVideoElement>>('streamVideo'); readonly videoRef = viewChild<ElementRef<HTMLVideoElement>>('streamVideo');
readonly isFullscreen = signal(false); readonly isFullscreen = signal(false);
readonly isMobile = this.viewport.isMobile;
readonly showFullscreenHeader = signal(true); readonly showFullscreenHeader = signal(true);
readonly volume = signal(100); readonly volume = signal(100);
readonly muted = signal(false); readonly muted = signal(false);
@@ -138,6 +143,7 @@ export class VoiceWorkspaceStreamTileComponent implements OnDestroy {
return; return;
} }
this.unlockOrientation();
this.clearFullscreenHeaderHideTimeout(); this.clearFullscreenHeaderHideTimeout();
this.showFullscreenHeader.set(true); this.showFullscreenHeader.set(true);
} }
@@ -150,6 +156,8 @@ export class VoiceWorkspaceStreamTileComponent implements OnDestroy {
if (tile && document.fullscreenElement === tile) { if (tile && document.fullscreenElement === tile) {
void document.exitFullscreen().catch(() => {}); void document.exitFullscreen().catch(() => {});
} }
this.unlockOrientation();
} }
canToggleFullscreen(): boolean { canToggleFullscreen(): boolean {
@@ -168,22 +176,38 @@ export class VoiceWorkspaceStreamTileComponent implements OnDestroy {
event.preventDefault(); event.preventDefault();
event.stopPropagation(); event.stopPropagation();
await this.toggleFullscreen();
}
async toggleFullscreen(event?: Event): Promise<void> {
event?.preventDefault();
event?.stopPropagation();
if (!this.canToggleFullscreen()) { if (!this.canToggleFullscreen()) {
return; return;
} }
const tile = this.tileRef()?.nativeElement; if (this.isFullscreen()) {
if (!tile || !tile.requestFullscreen) {
return;
}
if (document.fullscreenElement === tile) {
await document.exitFullscreen().catch(() => {}); await document.exitFullscreen().catch(() => {});
return; return;
} }
await tile.requestFullscreen().catch(() => {}); await this.enterFullscreen();
}
async enterLandscapeFullscreen(event?: Event): Promise<void> {
event?.preventDefault();
event?.stopPropagation();
if (!this.canToggleFullscreen()) {
return;
}
if (!this.isFullscreen()) {
await this.enterFullscreen();
}
await this.lockLandscape();
} }
async exitFullscreen(event?: Event): Promise<void> { async exitFullscreen(event?: Event): Promise<void> {
@@ -263,6 +287,41 @@ export class VoiceWorkspaceStreamTileComponent implements OnDestroy {
: 'Your preview stays muted locally to avoid audio feedback.'; : 'Your preview stays muted locally to avoid audio feedback.';
} }
canControlStreamAudio(): boolean {
const item = this.item();
return !item.isLocal && item.hasAudio;
}
private async enterFullscreen(): Promise<void> {
const tile = this.tileRef()?.nativeElement;
if (tile?.requestFullscreen) {
await tile.requestFullscreen().catch(() => {});
return;
}
const video = this.videoRef()?.nativeElement as WebKitFullscreenVideoElement | undefined;
if (video?.webkitSupportsFullscreen && video.webkitEnterFullscreen) {
video.webkitEnterFullscreen();
}
}
private async lockLandscape(): Promise<void> {
if (!this.isMobile()) {
return;
}
const orientation = screen.orientation as LockableScreenOrientation | undefined;
await orientation?.lock?.('landscape').catch(() => {});
}
private unlockOrientation(): void {
screen.orientation?.unlock?.();
}
private scheduleFullscreenHeaderHide(): void { private scheduleFullscreenHeaderHide(): void {
this.clearFullscreenHeaderHideTimeout(); this.clearFullscreenHeaderHideTimeout();
@@ -286,3 +345,12 @@ export class VoiceWorkspaceStreamTileComponent implements OnDestroy {
this.fullscreenHeaderHideTimeoutId = null; this.fullscreenHeaderHideTimeoutId = null;
} }
} }
interface WebKitFullscreenVideoElement extends HTMLVideoElement {
webkitEnterFullscreen?: () => void;
webkitSupportsFullscreen?: boolean;
}
interface LockableScreenOrientation extends ScreenOrientation {
lock?: (orientation: 'landscape') => Promise<void>;
}

View File

@@ -1,21 +1,19 @@
<nav class="relative flex h-full w-full flex-col items-center gap-2 border-r border-border bg-secondary/35 px-2 py-3"> <nav class="relative flex h-full min-w-14 flex-col items-center gap-2 border-r border-border bg-secondary/35 px-0 py-3 md:min-w-0 md:w-full">
<!-- Create button --> <!-- Create button -->
<button <button
appThemeNode="serversRailCreateButton" appThemeNode="serversRailCreateButton"
type="button" type="button"
class="flex h-10 w-10 items-center justify-center rounded-md bg-primary text-primary-foreground transition-colors hover:bg-primary/90" class="flex h-11 w-11 items-center justify-center rounded-md bg-primary text-primary-foreground transition-colors hover:bg-primary/90 md:h-10 md:w-10"
title="Create Server" title="Create Server"
(click)="createServer()" (click)="createServer()"
> >
<ng-icon <ng-icon
name="lucidePlus" name="lucidePlus"
class="w-5 h-5" class="h-[22px] w-[22px] md:h-5 md:w-5"
/> />
</button> </button>
@if (dmRailComponent()) { <app-dm-rail />
<ng-container *ngComponentOutlet="dmRailComponent()" />
}
@for (call of directCalls.visibleActiveSessions(); track call.callId + ':' + $index) { @for (call of directCalls.visibleActiveSessions(); track call.callId + ':' + $index) {
<div class="group/call relative flex w-full justify-center"> <div class="group/call relative flex w-full justify-center">
@@ -27,7 +25,7 @@
<button <button
type="button" type="button"
class="relative z-10 grid h-10 w-10 place-items-center overflow-hidden rounded-xl transition-colors hover:rounded-lg" class="relative z-10 grid h-11 w-11 place-items-center overflow-hidden rounded-xl transition-colors hover:rounded-lg md:h-10 md:w-10"
[ngClass]=" [ngClass]="
callAvatarUrls(call).length > 0 callAvatarUrls(call).length > 0
? 'bg-emerald-950 text-white shadow-sm hover:bg-emerald-900' ? 'bg-emerald-950 text-white shadow-sm hover:bg-emerald-900'
@@ -61,7 +59,7 @@
<ng-icon <ng-icon
name="lucidePhone" name="lucidePhone"
class="relative z-10 h-5 w-5 drop-shadow" class="relative z-10 h-[22px] w-[22px] drop-shadow md:h-5 md:w-5"
/> />
</button> </button>
</div> </div>
@@ -83,7 +81,7 @@
<button <button
appThemeNode="serversRailItem" appThemeNode="serversRailItem"
type="button" type="button"
class="relative z-10 flex h-10 w-10 cursor-pointer flex-shrink-0 items-center justify-center border border-transparent transition-[border-radius,box-shadow,background-color] duration-100 hover:rounded-lg hover:bg-card" class="relative z-10 flex h-11 w-11 cursor-pointer flex-shrink-0 items-center justify-center border border-transparent transition-[border-radius,box-shadow,background-color] duration-100 hover:rounded-lg hover:bg-card md:h-10 md:w-10"
[ngClass]="isSelectedRoom(room) ? 'rounded-lg ring-2 ring-primary/40 bg-primary/10' : 'rounded-xl bg-card'" [ngClass]="isSelectedRoom(room) ? 'rounded-lg ring-2 ring-primary/40 bg-primary/10' : 'rounded-xl bg-card'"
[title]="room.name" [title]="room.name"
[attr.aria-current]="isSelectedRoom(room) ? 'page' : null" [attr.aria-current]="isSelectedRoom(room) ? 'page' : null"

View File

@@ -2,7 +2,6 @@
import { import {
Component, Component,
DestroyRef, DestroyRef,
Type,
computed, computed,
effect, effect,
inject, inject,
@@ -36,6 +35,7 @@ import { RoomsActions } from '../../../store/rooms/rooms.actions';
import { DatabaseService } from '../../../infrastructure/persistence'; import { DatabaseService } from '../../../infrastructure/persistence';
import { NotificationsFacade } from '../../../domains/notifications'; import { NotificationsFacade } from '../../../domains/notifications';
import { DirectCallService, DirectCallSession } from '../../../domains/direct-call'; import { DirectCallService, DirectCallSession } from '../../../domains/direct-call';
import { DmRailComponent } from '../../../domains/direct-message/feature/dm-rail/dm-rail.component';
import { type ServerInfo, ServerDirectoryFacade } from '../../../domains/server-directory'; import { type ServerInfo, ServerDirectoryFacade } from '../../../domains/server-directory';
import { ThemeNodeDirective } from '../../../domains/theme'; import { ThemeNodeDirective } from '../../../domains/theme';
import { hasRoomBanForUser } from '../../../domains/access-control'; import { hasRoomBanForUser } from '../../../domains/access-control';
@@ -54,6 +54,7 @@ import {
NgIcon, NgIcon,
ConfirmDialogComponent, ConfirmDialogComponent,
ContextMenuComponent, ContextMenuComponent,
DmRailComponent,
LeaveServerDialogComponent, LeaveServerDialogComponent,
ThemeNodeDirective, ThemeNodeDirective,
UserBarComponent UserBarComponent
@@ -71,15 +72,16 @@ export class ServersRailComponent {
private serverDirectory = inject(ServerDirectoryFacade); private serverDirectory = inject(ServerDirectoryFacade);
private destroyRef = inject(DestroyRef); private destroyRef = inject(DestroyRef);
private banLookupRequestVersion = 0; private banLookupRequestVersion = 0;
private visibleSavedRoomCache: Room[] = [];
private savedRoomJoinRequests = new Subject<{ room: Room; password?: string }>(); private savedRoomJoinRequests = new Subject<{ room: Room; password?: string }>();
savedRooms = this.store.selectSignal(selectSavedRooms); savedRooms = this.store.selectSignal(selectSavedRooms);
currentRoom = this.store.selectSignal(selectCurrentRoom); currentRoom = this.store.selectSignal(selectCurrentRoom);
showMenu = signal(false); showMenu = signal(false);
dmRailComponent = signal<Type<unknown> | null>(null);
menuX = signal(72); menuX = signal(72);
menuY = signal(100); menuY = signal(100);
contextRoom = signal<Room | null>(null); contextRoom = signal<Room | null>(null);
optimisticSelectedRoomId = signal<string | null>(null);
showLeaveConfirm = signal(false); showLeaveConfirm = signal(false);
currentUser = this.store.selectSignal(selectCurrentUser); currentUser = this.store.selectSignal(selectCurrentUser);
onlineUsers = this.store.selectSignal(selectOnlineUsers); onlineUsers = this.store.selectSignal(selectOnlineUsers);
@@ -94,9 +96,9 @@ export class ServersRailComponent {
isOnDirectMessage = toSignal( isOnDirectMessage = toSignal(
this.router.events.pipe( this.router.events.pipe(
filter((navigationEvent): navigationEvent is NavigationEnd => navigationEvent instanceof NavigationEnd), filter((navigationEvent): navigationEvent is NavigationEnd => navigationEvent instanceof NavigationEnd),
map((navigationEvent) => navigationEvent.urlAfterRedirects.startsWith('/dm/') || navigationEvent.urlAfterRedirects.startsWith('/pm/')) map((navigationEvent) => this.isDirectMessageUrl(navigationEvent.urlAfterRedirects))
), ),
{ initialValue: this.router.url.startsWith('/dm/') || this.router.url.startsWith('/pm/') } { initialValue: this.isDirectMessageUrl(this.router.url) }
); );
isOnCall = toSignal( isOnCall = toSignal(
this.router.events.pipe( this.router.events.pipe(
@@ -138,7 +140,7 @@ export class ServersRailComponent {
passwordPromptRoom = signal<Room | null>(null); passwordPromptRoom = signal<Room | null>(null);
joinPassword = signal(''); joinPassword = signal('');
joinPasswordError = signal<string | null>(null); joinPasswordError = signal<string | null>(null);
visibleSavedRooms = computed(() => this.savedRooms().filter((room) => !this.isRoomMarkedBanned(room))); visibleSavedRooms = computed(() => this.stabilizeVisibleSavedRooms(this.savedRooms().filter((room) => !this.isRoomMarkedBanned(room))));
voicePresenceByRoom = computed(() => { voicePresenceByRoom = computed(() => {
const presence: Record<string, number> = {}; const presence: Record<string, number> = {};
const seenByRoom = new Map<string, Set<string>>(); const seenByRoom = new Map<string, Set<string>>();
@@ -181,10 +183,6 @@ export class ServersRailComponent {
}); });
constructor() { constructor() {
void import('../../../domains/direct-message/feature/dm-rail/dm-rail.component').then((module) => {
this.dmRailComponent.set(module.DmRailComponent);
});
effect(() => { effect(() => {
const rooms = this.savedRooms(); const rooms = this.savedRooms();
const currentUser = this.currentUser(); const currentUser = this.currentUser();
@@ -192,6 +190,18 @@ export class ServersRailComponent {
void this.refreshBannedLookup(rooms, currentUser ?? null); void this.refreshBannedLookup(rooms, currentUser ?? null);
}); });
effect(() => {
const optimisticRoomId = this.optimisticSelectedRoomId();
if (!optimisticRoomId) {
return;
}
if (this.currentRoom()?.id === optimisticRoomId && !this.isOnDirectMessage() && !this.isOnCall()) {
this.optimisticSelectedRoomId.set(null);
}
});
this.savedRoomJoinRequests this.savedRoomJoinRequests
.pipe( .pipe(
switchMap(({ room, password }) => this.requestJoinInBackground(room, password)), switchMap(({ room, password }) => this.requestJoinInBackground(room, password)),
@@ -214,6 +224,8 @@ export class ServersRailComponent {
createServer(): void { createServer(): void {
const voiceServerId = this.voiceSession.getVoiceServerId(); const voiceServerId = this.voiceSession.getVoiceServerId();
this.optimisticSelectedRoomId.set(null);
if (voiceServerId) { if (voiceServerId) {
this.voiceSession.setViewingVoiceServer(false); this.voiceSession.setViewingVoiceServer(false);
} }
@@ -222,6 +234,7 @@ export class ServersRailComponent {
} }
joinSavedRoom(room: Room): void { joinSavedRoom(room: Room): void {
const targetRoom = this.savedRooms().find((savedRoom) => savedRoom.id === room.id) ?? room;
const currentUserId = localStorage.getItem('metoyou_currentUserId'); const currentUserId = localStorage.getItem('metoyou_currentUserId');
if (!currentUserId) { if (!currentUserId) {
@@ -229,18 +242,20 @@ export class ServersRailComponent {
return; return;
} }
if (this.isRoomMarkedBanned(room)) { if (this.isRoomMarkedBanned(targetRoom)) {
this.bannedServerName.set(room.name); this.bannedServerName.set(targetRoom.name);
this.showBannedDialog.set(true); this.showBannedDialog.set(true);
return; return;
} }
this.activateSavedRoom(room); this.optimisticSelectedRoomId.set(targetRoom.id);
this.savedRoomJoinRequests.next({ room }); this.activateSavedRoom(targetRoom);
this.savedRoomJoinRequests.next({ room: targetRoom });
} }
openCall(callId: string): void { openCall(callId: string): void {
void this.router.navigate(['/call', callId]); this.optimisticSelectedRoomId.set(null);
void this.directCalls.openCallView(callId);
} }
isSelectedCall(callIndex: number): boolean { isSelectedCall(callIndex: number): boolean {
@@ -335,6 +350,7 @@ export class ServersRailComponent {
); );
if (isCurrentRoom) { if (isCurrentRoom) {
this.optimisticSelectedRoomId.set(null);
this.router.navigate(['/search']); this.router.navigate(['/search']);
} }
@@ -378,9 +394,44 @@ export class ServersRailComponent {
return false; return false;
} }
const optimisticRoomId = this.optimisticSelectedRoomId();
if (optimisticRoomId) {
return optimisticRoomId === room.id;
}
return this.currentRoom()?.id === room.id; return this.currentRoom()?.id === room.id;
} }
private stabilizeVisibleSavedRooms(nextRooms: Room[]): Room[] {
const previousById = new Map(this.visibleSavedRoomCache.map((room) => [room.id, room]));
const stabilizedRooms = nextRooms.map((room) => {
const previousRoom = previousById.get(room.id);
return previousRoom && this.hasSameRailRoomView(previousRoom, room) ? previousRoom : room;
});
if (
stabilizedRooms.length === this.visibleSavedRoomCache.length
&& stabilizedRooms.every((room, index) => room === this.visibleSavedRoomCache[index])
) {
return this.visibleSavedRoomCache;
}
this.visibleSavedRoomCache = stabilizedRooms;
return stabilizedRooms;
}
private hasSameRailRoomView(previousRoom: Room, nextRoom: Room): boolean {
return previousRoom.id === nextRoom.id && previousRoom.name === nextRoom.name && previousRoom.icon === nextRoom.icon;
}
private isDirectMessageUrl(url: string): boolean {
const path = url.split(/[?#]/, 1)[0];
return path === '/dm' || path.startsWith('/dm/') || path === '/pm' || path.startsWith('/pm/');
}
private async refreshBannedLookup(rooms: Room[], currentUser: User | null): Promise<void> { private async refreshBannedLookup(rooms: Room[], currentUser: User | null): Promise<void> {
const requestVersion = ++this.banLookupRequestVersion; const requestVersion = ++this.banLookupRequestVersion;
@@ -492,6 +543,7 @@ export class ServersRailComponent {
if (errorCode === 'BANNED') { if (errorCode === 'BANNED') {
this.closePasswordDialog(); this.closePasswordDialog();
this.optimisticSelectedRoomId.set(null);
this.bannedRoomLookup.update((lookup) => ({ this.bannedRoomLookup.update((lookup) => ({
...lookup, ...lookup,
[room.id]: true [room.id]: true

View File

@@ -57,7 +57,7 @@ The persisted `rooms` store is a local cache of room metadata. Channel topology
### Browser (IndexedDB) ### Browser (IndexedDB)
All operations run inside IndexedDB transactions in the renderer thread. The browser backend resolves the active database name from the logged-in user, reusing a legacy shared database only when it already belongs to that same account. Queries like `getMessages` pull all messages for a room via the `roomId` index, sort them by timestamp in JS, then apply limit/offset. Deleted messages are normalised on read (content replaced with a sentinel string). All operations run inside IndexedDB transactions in the renderer thread. The browser backend resolves the active database name from the logged-in user, reusing a legacy shared database only when it already belongs to that same account. Queries like `getMessages` pull all messages for a room via the `roomId` index, optionally filter to a text channel, sort them by timestamp in JS, then apply limit/offset. Deleted messages are normalised on read (content replaced with a sentinel string).
```mermaid ```mermaid
sequenceDiagram sequenceDiagram
@@ -66,11 +66,11 @@ sequenceDiagram
participant BDB as BrowserDatabaseService participant BDB as BrowserDatabaseService
participant IDB as IndexedDB participant IDB as IndexedDB
Eff->>DB: getMessages(roomId, 50) Eff->>DB: getMessages(roomId, 50, 0, channelId?)
DB->>BDB: getMessages(roomId, 50) DB->>BDB: getMessages(roomId, 50, 0, channelId?)
BDB->>IDB: tx.objectStore("messages")<br/>.index("roomId").getAll(roomId) BDB->>IDB: tx.objectStore("messages")<br/>.index("roomId").getAll(roomId)
IDB-->>BDB: Message[] IDB-->>BDB: Message[]
Note over BDB: Sort by timestamp, slice, normalise Note over BDB: Optional channel filter, sort, slice, normalise
BDB-->>DB: Message[] BDB-->>DB: Message[]
DB-->>Eff: Message[] DB-->>Eff: Message[]
``` ```

View File

@@ -66,31 +66,48 @@ export class BrowserDatabaseService {
} }
/** /**
* Retrieve messages for a room, sorted oldest-first. * Retrieve the latest messages for a room, sorted oldest-first for display.
* @param roomId - Target room. * @param roomId - Target room.
* @param limit - Maximum number of messages to return. * @param limit - Maximum number of messages to return.
* @param offset - Number of messages to skip (for pagination). * @param offset - Number of newer messages to skip (for pagination).
* @param channelId - Optional channel scope; 'general' includes null/empty.
* @param beforeTimestamp - Optional cursor; only messages strictly older
* than this timestamp are returned. Used for
* scroll-up history pagination.
*/ */
async getMessages(roomId: string, limit = 100, offset = 0): Promise<Message[]> { async getMessages(
roomId: string,
limit = 100,
offset = 0,
channelId?: string,
beforeTimestamp?: number
): Promise<Message[]> {
const allRoomMessages = await this.getAllFromIndex<Message>( const allRoomMessages = await this.getAllFromIndex<Message>(
STORE_MESSAGES, 'roomId', roomId STORE_MESSAGES, 'roomId', roomId
); );
const scopedMessages = channelId
? allRoomMessages.filter((message) => (message.channelId || 'general') === channelId)
: allRoomMessages;
const cursorFiltered = beforeTimestamp === undefined
? scopedMessages
: scopedMessages.filter((message) => message.timestamp < beforeTimestamp);
const sortedMessages = cursorFiltered.sort((first, second) => first.timestamp - second.timestamp);
const endIndex = Math.max(sortedMessages.length - offset, 0);
const startIndex = Math.max(endIndex - limit, 0);
const messages = sortedMessages.slice(startIndex, endIndex);
return allRoomMessages return this.hydrateMessages(messages);
.sort((first, second) => first.timestamp - second.timestamp)
.slice(offset, offset + limit)
.map((message) => this.normaliseMessage(message));
} }
async getMessagesSince(roomId: string, sinceTimestamp: number): Promise<Message[]> { async getMessagesSince(roomId: string, sinceTimestamp: number): Promise<Message[]> {
const allRoomMessages = await this.getAllFromIndex<Message>( const allRoomMessages = await this.getAllFromIndex<Message>(
STORE_MESSAGES, 'roomId', roomId STORE_MESSAGES, 'roomId', roomId
); );
const messages = allRoomMessages
return allRoomMessages
.filter((message) => message.timestamp > sinceTimestamp) .filter((message) => message.timestamp > sinceTimestamp)
.sort((first, second) => first.timestamp - second.timestamp) .sort((first, second) => first.timestamp - second.timestamp);
.map((message) => this.normaliseMessage(message));
return this.hydrateMessages(messages);
} }
/** Delete a message by its ID. */ /** Delete a message by its ID. */
@@ -112,7 +129,11 @@ export class BrowserDatabaseService {
async getMessageById(messageId: string): Promise<Message | null> { async getMessageById(messageId: string): Promise<Message | null> {
const message = await this.get<Message>(STORE_MESSAGES, messageId); const message = await this.get<Message>(STORE_MESSAGES, messageId);
return message ? this.normaliseMessage(message) : null; if (!message) {
return null;
}
return (await this.hydrateMessages([message]))[0] ?? null;
} }
/** Remove every message belonging to a room. */ /** Remove every message belonging to a room. */
@@ -520,6 +541,47 @@ export class BrowserDatabaseService {
await this.awaitTransaction(transaction); await this.awaitTransaction(transaction);
} }
private async hydrateMessages(messages: Message[]): Promise<Message[]> {
if (messages.length === 0) {
return [];
}
const reactionsByMessageId = await this.loadReactionsForMessages(messages.map((message) => message.id));
return messages.map((message) => this.normaliseMessage({
...message,
reactions: reactionsByMessageId.get(message.id) ?? message.reactions ?? []
}));
}
private async loadReactionsForMessages(messageIds: readonly string[]): Promise<Map<string, Reaction[]>> {
const messageIdSet = new Set(messageIds.filter((messageId) => messageId.trim().length > 0));
const reactionsByMessageId = new Map<string, Reaction[]>();
if (messageIdSet.size === 0) {
return reactionsByMessageId;
}
const allReactions = await this.getAll<Reaction>(STORE_REACTIONS);
for (const reaction of allReactions) {
if (!messageIdSet.has(reaction.messageId)) {
continue;
}
const reactions = reactionsByMessageId.get(reaction.messageId) ?? [];
reactions.push(reaction);
reactionsByMessageId.set(reaction.messageId, reactions);
}
for (const reactions of reactionsByMessageId.values()) {
reactions.sort((first, second) => first.timestamp - second.timestamp);
}
return reactionsByMessageId;
}
private normaliseMessage(message: Message): Message { private normaliseMessage(message: Message): Message {
if (message.content === DELETED_MESSAGE_CONTENT) { if (message.content === DELETED_MESSAGE_CONTENT) {
return { ...message, return { ...message,

View File

@@ -49,8 +49,19 @@ export class DatabaseService {
/** Persist a single chat message. */ /** Persist a single chat message. */
saveMessage(message: Message) { return this.backend.saveMessage(message); } saveMessage(message: Message) { return this.backend.saveMessage(message); }
/** Retrieve messages for a room with optional pagination. */ /** Retrieve the latest messages for a room or channel with optional pagination.
getMessages(roomId: string, limit = 100, offset = 0) { return this.backend.getMessages(roomId, limit, offset); } *
* When `beforeTimestamp` is provided, only messages strictly older than that
* timestamp are returned. This is how scroll-up history loading paginates
* backwards through the DB without holding the whole history in memory.
*/
getMessages(
roomId: string,
limit = 100,
offset = 0,
channelId?: string,
beforeTimestamp?: number
) { return this.backend.getMessages(roomId, limit, offset, channelId, beforeTimestamp); }
/** Retrieve messages newer than a given timestamp for a room. */ /** Retrieve messages newer than a given timestamp for a room. */
getMessagesSince(roomId: string, sinceTimestamp: number) { return this.backend.getMessagesSince(roomId, sinceTimestamp); } getMessagesSince(roomId: string, sinceTimestamp: number) { return this.backend.getMessagesSince(roomId, sinceTimestamp); }

View File

@@ -37,14 +37,26 @@ export class ElectronDatabaseService {
} }
/** /**
* Retrieve messages for a room, sorted oldest-first. * Retrieve the latest messages for a room, sorted oldest-first for display.
* *
* @param roomId - Target room. * @param roomId - Target room.
* @param limit - Maximum number of messages to return. * @param limit - Maximum number of messages to return.
* @param offset - Number of messages to skip (for pagination). * @param offset - Number of newer messages to skip (for pagination).
* @param channelId - Optional channel scope; 'general' includes null/empty.
* @param beforeTimestamp - Optional cursor; only messages strictly older
* than this timestamp are returned (scroll-up paging).
*/ */
getMessages(roomId: string, limit = 100, offset = 0): Promise<Message[]> { getMessages(
return this.api.query<Message[]>({ type: 'get-messages', payload: { roomId, limit, offset } }); roomId: string,
limit = 100,
offset = 0,
channelId?: string,
beforeTimestamp?: number
): Promise<Message[]> {
return this.api.query<Message[]>({
type: 'get-messages',
payload: { roomId, limit, offset, channelId, beforeTimestamp }
});
} }
getMessagesSince(roomId: string, sinceTimestamp: number): Promise<Message[]> { getMessagesSince(roomId: string, sinceTimestamp: number): Promise<Message[]> {

View File

@@ -250,7 +250,7 @@ Profile avatar sync follows attachment-style chunk transport plus server-icon-st
Every 5 seconds a PING message is sent to each peer. The peer responds with PONG carrying the original timestamp, and the round-trip latency is stored in a signal. Every 5 seconds a PING message is sent to each peer. The peer responds with PONG carrying the original timestamp, and the round-trip latency is stored in a signal.
Data-channel failures are treated as control-plane failures, not proof that RTP audio has stopped. When an open channel reports a non-fatal error, the client requests a fresh voice-state snapshot over that same channel. When the channel closes or cannot carry the resync request, the peer manager waits a short grace period so any still-flowing audio is not interrupted by a transient event. If the `RTCPeerConnection` is still connected after that grace period, the elected initiator replaces only the data channel in-place and preserves the media transport. Full peer recreation is reserved for cases where the media transport is no longer connected or the in-place control-channel repair fails. Data-channel failures are treated as control-plane failures. When an open channel reports a non-fatal error, the client requests a fresh voice-state snapshot over that same channel. When the channel is already closed there is no recovery on it, so the peer manager acts immediately: the deterministic initiator renegotiates a new `RTCDataChannel` on the existing `RTCPeerConnection` (preserving audio/video transport), the non-initiator briefly waits for that replacement and then forces a full peer rebuild if it does not arrive, and a peer whose `RTCPeerConnection` is no longer in `connected` state is recreated immediately through the normal deterministic reconnect path. A closing-but-not-yet-closed channel still waits a short grace period in case the underlying transport flips back. Either way, the rebuild heals chat, state sync, voice, camera, and screen-share transport together instead of preserving a media connection whose control channel can no longer coordinate peer state.
## Media pipeline ## Media pipeline

View File

@@ -13,7 +13,7 @@ describe('peer recovery', () => {
vi.useRealTimers(); vi.useRealTimers();
}); });
it('waits a short grace period before replacing a closed data channel in place', () => { it('recreates a peer immediately when the data channel is already closed', () => {
vi.useFakeTimers(); vi.useFakeTimers();
const channel = createDataChannel('closed'); const channel = createDataChannel('closed');
@@ -24,29 +24,28 @@ describe('peer recovery', () => {
scheduleDataChannelRecovery(context, 'bob', channel, 'close', handlers); scheduleDataChannelRecovery(context, 'bob', channel, 'close', handlers);
expect(handlers.removePeer).toHaveBeenCalledWith('bob', { preserveReconnectState: true });
expect(handlers.createPeerConnection).toHaveBeenCalledWith('bob', true);
expect(handlers.createAndSendOffer).toHaveBeenCalledWith('bob');
expect(context.state.dataChannelRecoveryTimers.has('bob')).toBe(false);
});
it('waits a short grace period before recreating a peer with a closing data channel', () => {
vi.useFakeTimers();
const channel = createDataChannel('closing');
const context = createContext('alice');
const handlers = createRecoveryHandlers(context);
context.state.activePeerConnections.set('bob', createPeerData(channel, 'connected'));
scheduleDataChannelRecovery(context, 'bob', channel, 'close', handlers);
vi.advanceTimersByTime(DATA_CHANNEL_RECOVERY_GRACE_MS - 1); vi.advanceTimersByTime(DATA_CHANNEL_RECOVERY_GRACE_MS - 1);
expect(handlers.removePeer).not.toHaveBeenCalled(); expect(handlers.removePeer).not.toHaveBeenCalled();
expect(handlers.createPeerConnection).not.toHaveBeenCalled(); expect(handlers.createPeerConnection).not.toHaveBeenCalled();
vi.advanceTimersByTime(1); vi.advanceTimersByTime(1);
expect(handlers.replaceDataChannel).toHaveBeenCalledWith('bob', channel);
expect(handlers.removePeer).not.toHaveBeenCalled();
expect(handlers.createPeerConnection).not.toHaveBeenCalled();
expect(handlers.createAndSendOffer).not.toHaveBeenCalled();
});
it('falls back to full peer recreation when in-place data channel replacement fails', () => {
vi.useFakeTimers();
const channel = createDataChannel('closed');
const context = createContext('alice');
const handlers = createRecoveryHandlers(context);
handlers.replaceDataChannel.mockReturnValueOnce(false);
context.state.activePeerConnections.set('bob', createPeerData(channel, 'connected'));
scheduleDataChannelRecovery(context, 'bob', channel, 'close', handlers);
vi.advanceTimersByTime(DATA_CHANNEL_RECOVERY_GRACE_MS);
expect(handlers.removePeer).toHaveBeenCalledWith('bob', { preserveReconnectState: true }); expect(handlers.removePeer).toHaveBeenCalledWith('bob', { preserveReconnectState: true });
expect(handlers.createPeerConnection).toHaveBeenCalledWith('bob', true); expect(handlers.createPeerConnection).toHaveBeenCalledWith('bob', true);
@@ -56,7 +55,7 @@ describe('peer recovery', () => {
it('does not recreate a peer when a replacement data channel is adopted before the grace expires', () => { it('does not recreate a peer when a replacement data channel is adopted before the grace expires', () => {
vi.useFakeTimers(); vi.useFakeTimers();
const staleChannel = createDataChannel('closed'); const staleChannel = createDataChannel('closing');
const replacementChannel = createDataChannel(DATA_CHANNEL_STATE_OPEN); const replacementChannel = createDataChannel(DATA_CHANNEL_STATE_OPEN);
const context = createContext('alice'); const context = createContext('alice');
const handlers = createRecoveryHandlers(context); const handlers = createRecoveryHandlers(context);
@@ -90,7 +89,7 @@ describe('peer recovery', () => {
expect(handlers.createPeerConnection).not.toHaveBeenCalled(); expect(handlers.createPeerConnection).not.toHaveBeenCalled();
}); });
it('preserves a connected non-initiator peer while waiting for the remote initiator to replace the channel', () => { it('recreates a connected non-initiator peer and waits for the remote initiator offer', () => {
vi.useFakeTimers(); vi.useFakeTimers();
const channel = createDataChannel('closed'); const channel = createDataChannel('closed');
@@ -99,11 +98,10 @@ describe('peer recovery', () => {
context.state.activePeerConnections.set('bob', createPeerData(channel, 'connected', false)); context.state.activePeerConnections.set('bob', createPeerData(channel, 'connected', false));
scheduleDataChannelRecovery(context, 'bob', channel, 'close', handlers); scheduleDataChannelRecovery(context, 'bob', channel, 'close', handlers);
vi.advanceTimersByTime(DATA_CHANNEL_RECOVERY_GRACE_MS);
expect(handlers.removePeer).not.toHaveBeenCalled(); expect(handlers.removePeer).toHaveBeenCalledWith('bob', { preserveReconnectState: true });
expect(handlers.replaceDataChannel).not.toHaveBeenCalled(); expect(handlers.replaceDataChannel).not.toHaveBeenCalled();
expect(handlers.createPeerConnection).not.toHaveBeenCalled(); expect(handlers.createPeerConnection).toHaveBeenCalledWith('bob', false);
expect(handlers.createAndSendOffer).not.toHaveBeenCalled(); expect(handlers.createAndSendOffer).not.toHaveBeenCalled();
}); });

View File

@@ -154,6 +154,18 @@ export function scheduleDataChannelRecovery(
if (channel.readyState === DATA_CHANNEL_STATE_OPEN) if (channel.readyState === DATA_CHANNEL_STATE_OPEN)
return; return;
if (channel.readyState === 'closed') {
logger.warn('[data-channel] Control channel closed; reconnecting peer immediately', {
channelLabel: channel.label,
connectionState: peerData.connection.connectionState,
peerId,
reason
});
repairUnavailableDataChannel(context, peerId, channel, reason, handlers);
return;
}
if (state.dataChannelRecoveryTimers.has(peerId)) if (state.dataChannelRecoveryTimers.has(peerId))
return; return;
@@ -183,35 +195,42 @@ export function scheduleDataChannelRecovery(
reason reason
}); });
if (latestPeerData.connection.connectionState === CONNECTION_STATE_CONNECTED) { repairUnavailableDataChannel(context, peerId, channel, reason, handlers);
if (latestPeerData.isInitiator && handlers.replaceDataChannel(peerId, channel)) {
logger.info('[data-channel] Replaced control channel without recreating media transport', {
peerId,
reason
});
return;
}
if (!latestPeerData.isInitiator) {
logger.info('[data-channel] Waiting for initiator to replace control channel; preserving media transport', {
peerId,
reason
});
return;
}
}
trackDisconnectedPeer(state, peerId);
handlers.removePeer(peerId, { preserveReconnectState: true });
attemptPeerReconnect(context, peerId, handlers);
schedulePeerReconnect(context, peerId, handlers);
}, DATA_CHANNEL_RECOVERY_GRACE_MS); }, DATA_CHANNEL_RECOVERY_GRACE_MS);
state.dataChannelRecoveryTimers.set(peerId, timer); state.dataChannelRecoveryTimers.set(peerId, timer);
} }
function repairUnavailableDataChannel(
context: PeerConnectionManagerContext,
peerId: string,
channel: RTCDataChannel,
reason: string,
handlers: RecoveryHandlers
): void {
const { logger, state } = context;
const peerData = state.activePeerConnections.get(peerId);
if (!peerData || peerData.dataChannel !== channel)
return;
if (peerData.dataChannel?.readyState === DATA_CHANNEL_STATE_OPEN)
return;
logger.warn('[data-channel] Recreating peer transport after control channel failure', {
channelLabel: channel.label,
connectionState: peerData.connection.connectionState,
peerId,
readyState: peerData.dataChannel?.readyState ?? null,
reason
});
trackDisconnectedPeer(state, peerId);
handlers.removePeer(peerId, { preserveReconnectState: true });
attemptPeerReconnect(context, peerId, handlers);
schedulePeerReconnect(context, peerId, handlers);
}
export function schedulePeerDisconnectRecovery( export function schedulePeerDisconnectRecovery(
context: PeerConnectionManagerContext, context: PeerConnectionManagerContext,
peerId: string, peerId: string,

View File

@@ -15,7 +15,7 @@
class="h-24 bg-gradient-to-r from-primary/30 to-primary/10" class="h-24 bg-gradient-to-r from-primary/30 to-primary/10"
></div> ></div>
<div class="-mt-12 flex flex-col items-center px-6"> <div class="-mt-16 flex flex-col items-center px-6">
<div class="relative"> <div class="relative">
<button <button
type="button" type="button"
@@ -26,7 +26,7 @@
<app-user-avatar <app-user-avatar
[name]="profileUser.displayName" [name]="profileUser.displayName"
[avatarUrl]="profileUser.avatarUrl" [avatarUrl]="profileUser.avatarUrl"
size="xl" size="2xl"
[status]="profileUser.status" [status]="profileUser.status"
[showStatusBadge]="true" [showStatusBadge]="true"
ringClass="ring-4 ring-card" ringClass="ring-4 ring-card"
@@ -34,11 +34,11 @@
</button> </button>
@if (isEditable) { @if (isEditable) {
<span <span
class="pointer-events-none absolute bottom-1 right-1 flex h-7 w-7 items-center justify-center rounded-full border-2 border-card bg-primary text-primary-foreground shadow" class="pointer-events-none absolute bottom-2 right-2 flex h-9 w-9 items-center justify-center rounded-full border-2 border-card bg-primary text-primary-foreground shadow"
> >
<ng-icon <ng-icon
name="lucideCamera" name="lucideCamera"
class="h-3.5 w-3.5" class="h-4 w-4"
/> />
</span> </span>
} }

View File

@@ -16,29 +16,42 @@ import { UserStatus } from '../../../shared-kernel';
export class UserAvatarComponent { export class UserAvatarComponent {
name = input.required<string>(); name = input.required<string>();
avatarUrl = input<string | undefined | null>(); avatarUrl = input<string | undefined | null>();
size = input<'xs' | 'sm' | 'md' | 'lg' | 'xl'>('sm'); size = input<'xs' | 'sm' | 'md' | 'lg' | 'xl' | '2xl'>('sm');
ringClass = input<string>(''); ringClass = input<string>('');
status = input<UserStatus | undefined>(); status = input<UserStatus | undefined>();
showStatusBadge = input(false); showStatusBadge = input(false);
statusBadgeColor = computed(() => { statusBadgeColor = computed(() => {
switch (this.status()) { switch (this.status()) {
case 'online': return 'bg-green-500'; case 'online':
case 'away': return 'bg-yellow-500'; return 'bg-green-500';
case 'busy': return 'bg-red-500'; case 'away':
case 'offline': return 'bg-gray-500'; return 'bg-yellow-500';
case 'disconnected': return 'bg-gray-500'; case 'busy':
default: return 'bg-gray-500'; return 'bg-red-500';
case 'offline':
return 'bg-gray-500';
case 'disconnected':
return 'bg-gray-500';
default:
return 'bg-gray-500';
} }
}); });
statusBadgeSizeClass = computed(() => { statusBadgeSizeClass = computed(() => {
switch (this.size()) { switch (this.size()) {
case 'xs': return 'w-2 h-2'; case 'xs':
case 'sm': return 'w-3 h-3'; return 'w-2 h-2';
case 'md': return 'w-3.5 h-3.5'; case 'sm':
case 'lg': return 'w-4 h-4'; return 'w-3 h-3';
case 'xl': return 'w-4.5 h-4.5'; case 'md':
return 'w-3.5 h-3.5';
case 'lg':
return 'w-4 h-4';
case 'xl':
return 'w-4.5 h-4.5';
case '2xl':
return 'w-6 h-6';
} }
}); });
@@ -49,31 +62,52 @@ export class UserAvatarComponent {
sizeClasses(): string { sizeClasses(): string {
switch (this.size()) { switch (this.size()) {
case 'xs': return 'w-7 h-7'; case 'xs':
case 'sm': return 'w-8 h-8'; return 'w-7 h-7';
case 'md': return 'w-10 h-10'; case 'sm':
case 'lg': return 'w-12 h-12'; return 'w-8 h-8';
case 'xl': return 'w-16 h-16'; case 'md':
return 'w-10 h-10';
case 'lg':
return 'w-12 h-12';
case 'xl':
return 'w-16 h-16';
case '2xl':
return 'w-32 h-32';
} }
} }
sizePx(): number { sizePx(): number {
switch (this.size()) { switch (this.size()) {
case 'xs': return 28; case 'xs':
case 'sm': return 32; return 28;
case 'md': return 40; case 'sm':
case 'lg': return 48; return 32;
case 'xl': return 64; case 'md':
return 40;
case 'lg':
return 48;
case 'xl':
return 64;
case '2xl':
return 128;
} }
} }
textClass(): string { textClass(): string {
switch (this.size()) { switch (this.size()) {
case 'xs': return 'text-xs'; case 'xs':
case 'sm': return 'text-sm'; return 'text-xs';
case 'md': return 'text-base font-semibold'; case 'sm':
case 'lg': return 'text-lg font-semibold'; return 'text-sm';
case 'xl': return 'text-xl font-semibold'; case 'md':
return 'text-base font-semibold';
case 'lg':
return 'text-lg font-semibold';
case 'xl':
return 'text-xl font-semibold';
case '2xl':
return 'text-4xl font-semibold';
} }
} }
} }

View File

@@ -95,7 +95,7 @@ describe('dispatchIncomingMessage room-scoped sync', () => {
expect(getMessages).toHaveBeenCalledWith('room-b', expect.any(Number), 0); expect(getMessages).toHaveBeenCalledWith('room-b', expect.any(Number), 0);
expect(sendToPeer).toHaveBeenCalledWith('peer-2', { expect(sendToPeer).toHaveBeenCalledWith('peer-2', {
type: 'chat-sync-full', type: 'chat-sync-batch',
roomId: 'room-b', roomId: 'room-b',
messages: roomBMessages messages: roomBMessages
}); });

View File

@@ -289,6 +289,12 @@ async function processSyncBatch(
attachments: AttachmentFacade attachments: AttachmentFacade
): Promise<Message[]> { ): Promise<Message[]> {
const toUpsert: Message[] = []; const toUpsert: Message[] = [];
// Yield to the event loop every YIELD_EVERY messages so Angular change
// detection and user input aren't starved while a large sync batch
// (e.g. from a bulk plugin import) drains serial DB writes.
const YIELD_EVERY = 50;
let processed = 0;
for (const incoming of event.messages) { for (const incoming of event.messages) {
attachments.rememberMessageRoom(incoming.id, incoming.roomId); attachments.rememberMessageRoom(incoming.id, incoming.roomId);
@@ -305,6 +311,12 @@ async function processSyncBatch(
if (changed) if (changed)
toUpsert.push(message); toUpsert.push(message);
processed += 1;
if (processed % YIELD_EVERY === 0) {
await new Promise<void>((resolve) => setTimeout(resolve, 0));
}
} }
if (hasAttachmentMetaMap(event.attachments)) { if (hasAttachmentMetaMap(event.attachments)) {
@@ -603,13 +615,20 @@ function handleSyncRequest(
return from( return from(
(async () => { (async () => {
const all = await db.getMessages(targetRoomId, FULL_SYNC_LIMIT, 0); const all = await db.getMessages(targetRoomId, FULL_SYNC_LIMIT, 0);
const syncFullEvent: ChatEvent = {
type: 'chat-sync-full',
roomId: targetRoomId,
messages: all
};
webrtc.sendToPeer(fromPeerId, syncFullEvent); // Ship as chunked chat-sync-batch events instead of a single
// chat-sync-full payload. A monolithic dump of up to FULL_SYNC_LIMIT
// messages can exceed the WebRTC SCTP per-message size ceiling and be
// silently dropped - especially after bulk plugin imports.
for (const chunk of chunkArray(all, CHUNK_SIZE)) {
const syncBatchEvent: ChatEvent = {
type: 'chat-sync-batch',
roomId: targetRoomId,
messages: chunk
};
webrtc.sendToPeer(fromPeerId, syncBatchEvent);
}
})() })()
).pipe(mergeMap(() => EMPTY)); ).pipe(mergeMap(() => EMPTY));
} }

View File

@@ -111,40 +111,47 @@ export class MessagesSyncEffects {
this.actions$.pipe( this.actions$.pipe(
ofType(RoomsActions.joinRoomSuccess, RoomsActions.viewServerSuccess), ofType(RoomsActions.joinRoomSuccess, RoomsActions.viewServerSuccess),
withLatestFrom(this.store.select(selectCurrentRoom)), withLatestFrom(this.store.select(selectCurrentRoom)),
mergeMap(([{ room }, currentRoom]) => { switchMap(([{ room }, currentRoom]) => {
const activeRoom = currentRoom || room; const requestedRoomId = room.id;
if (!activeRoom) return timer(75).pipe(
return EMPTY; withLatestFrom(this.store.select(selectCurrentRoom)),
switchMap(([, latestCurrentRoom]) => {
const activeRoom = latestCurrentRoom ?? currentRoom ?? room;
const peers = this.webrtc.getConnectedPeers();
return from( if (!activeRoom || activeRoom.id !== requestedRoomId || peers.length === 0) {
this.db.getMessages(activeRoom.id, FULL_SYNC_LIMIT, 0) return EMPTY;
).pipe(
tap((messages) => {
const count = messages.length;
const lastUpdated = getLatestTimestamp(messages);
for (const pid of this.webrtc.getConnectedPeers()) {
try {
this.webrtc.sendToPeer(pid, {
type: 'chat-sync-summary',
roomId: activeRoom.id,
count,
lastUpdated
});
this.webrtc.sendToPeer(pid, {
type: 'chat-inventory-request',
roomId: activeRoom.id
});
} catch (error) {
this.debugging.warn('messages', 'Failed to kick off room sync for peer', {
error,
peerId: pid,
roomId: activeRoom.id
});
}
} }
return from(this.db.getMessages(activeRoom.id, FULL_SYNC_LIMIT, 0)).pipe(
tap((messages) => {
const count = messages.length;
const lastUpdated = getLatestTimestamp(messages);
for (const pid of peers) {
try {
this.webrtc.sendToPeer(pid, {
type: 'chat-sync-summary',
roomId: activeRoom.id,
count,
lastUpdated
});
this.webrtc.sendToPeer(pid, {
type: 'chat-inventory-request',
roomId: activeRoom.id
});
} catch (error) {
this.debugging.warn('messages', 'Failed to kick off room sync for peer', {
error,
peerId: pid,
roomId: activeRoom.id
});
}
}
})
);
}) })
); );
}) })

View File

@@ -23,6 +23,24 @@ export const MessagesActions = createActionGroup({
'Load Messages Success': props<{ messages: Message[] }>(), 'Load Messages Success': props<{ messages: Message[] }>(),
'Load Messages Failure': props<{ error: string }>(), 'Load Messages Failure': props<{ error: string }>(),
/**
* Fetches a page of messages strictly older than `beforeTimestamp` for a
* given conversation (room + channel). Used by the chat scroll-up handler
* to backfill history from the local database on demand.
*/
'Load Older Messages': props<{
roomId: string;
channelId: string;
beforeTimestamp: number;
limit: number;
}>(),
'Load Older Messages Success': props<{
conversationKey: string;
messages: Message[];
reachedEnd: boolean;
}>(),
'Load Older Messages Failure': props<{ error: string }>(),
/** Sends a new chat message to the current room and broadcasts to peers. */ /** Sends a new chat message to the current room and broadcasts to peers. */
'Send Message': props<{ content: string; replyToId?: string; channelId?: string }>(), 'Send Message': props<{ content: string; replyToId?: string; channelId?: string }>(),
'Send Message Success': props<{ message: Message }>(), 'Send Message Success': props<{ message: Message }>(),

View File

@@ -43,13 +43,16 @@ import { TimeSyncService } from '../../core/services/time-sync.service';
import { import {
DELETED_MESSAGE_CONTENT, DELETED_MESSAGE_CONTENT,
Message, Message,
Reaction Reaction,
Room
} from '../../shared-kernel'; } from '../../shared-kernel';
import { hydrateMessages } from './messages.helpers'; import { hydrateMessages } from './messages.helpers';
import { canEditMessage } from '../../domains/chat/domain/rules/message.rules'; import { canEditMessage } from '../../domains/chat/domain/rules/message.rules';
import { resolveRoomPermission } from '../../domains/access-control'; import { resolveRoomPermission } from '../../domains/access-control';
import { dispatchIncomingMessage, IncomingMessageContext } from './messages-incoming.handlers'; import { dispatchIncomingMessage, IncomingMessageContext } from './messages-incoming.handlers';
const INITIAL_ROOM_MESSAGE_LIMIT = 30;
@Injectable() @Injectable()
export class MessagesEffects { export class MessagesEffects {
private readonly actions$ = inject(Actions); private readonly actions$ = inject(Actions);
@@ -65,8 +68,9 @@ export class MessagesEffects {
loadMessages$ = createEffect(() => loadMessages$ = createEffect(() =>
this.actions$.pipe( this.actions$.pipe(
ofType(MessagesActions.loadMessages), ofType(MessagesActions.loadMessages),
switchMap(({ roomId }) => withLatestFrom(this.store.select(selectCurrentRoom)),
from(this.db.getMessages(roomId)).pipe( switchMap(([{ roomId }, currentRoom]) =>
from(this.loadInitialMessages(roomId, currentRoom)).pipe(
mergeMap(async (messages) => { mergeMap(async (messages) => {
const hydrated = await hydrateMessages(messages, this.db); const hydrated = await hydrateMessages(messages, this.db);
@@ -86,6 +90,58 @@ export class MessagesEffects {
) )
); );
/** Paginates older messages from the local DB for scroll-up history loading. */
loadOlderMessages$ = createEffect(() =>
this.actions$.pipe(
ofType(MessagesActions.loadOlderMessages),
mergeMap(({ roomId, channelId, beforeTimestamp, limit }) =>
from(
this.db.getMessages(roomId, limit, 0, channelId, beforeTimestamp)
).pipe(
mergeMap(async (messages) => {
const hydrated = await hydrateMessages(messages, this.db);
for (const message of hydrated) {
this.attachments.rememberMessageRoom(message.id, message.roomId);
}
return MessagesActions.loadOlderMessagesSuccess({
conversationKey: `${roomId}:${channelId}`,
messages: hydrated,
reachedEnd: hydrated.length < limit
});
}),
catchError((error) =>
of(MessagesActions.loadOlderMessagesFailure({ error: error.message }))
)
)
)
)
);
private async loadInitialMessages(roomId: string, currentRoom: Room | null): Promise<Message[]> {
const textChannels = currentRoom?.id === roomId
? (currentRoom.channels ?? []).filter((channel) => channel.type === 'text')
: [];
if (textChannels.length <= 1) {
return this.db.getMessages(roomId, INITIAL_ROOM_MESSAGE_LIMIT, 0, textChannels[0]?.id);
}
const channelMessageSets = await Promise.all(
textChannels.map((channel) => this.db.getMessages(roomId, INITIAL_ROOM_MESSAGE_LIMIT, 0, channel.id))
);
const messagesById = new Map<string, Message>();
for (const messages of channelMessageSets) {
for (const message of messages) {
messagesById.set(message.id, message);
}
}
return [...messagesById.values()].sort((first, second) => first.timestamp - second.timestamp);
}
/** Constructs a new message, persists it locally, and broadcasts to all peers. */ /** Constructs a new message, persists it locally, and broadcasts to all peers. */
sendMessage$ = createEffect(() => sendMessage$ = createEffect(() =>
this.actions$.pipe( this.actions$.pipe(

View File

@@ -29,29 +29,33 @@ export type { InventoryItem } from '../../domains/chat/domain/rules/message-sync
/** Hydrates a single message with its reactions from the database. */ /** Hydrates a single message with its reactions from the database. */
export async function hydrateMessage( export async function hydrateMessage(
msg: Message, msg: Message,
db: DatabaseService _db: DatabaseService
): Promise<Message> { ): Promise<Message> {
if (msg.isDeleted) if (msg.isDeleted)
return normaliseDeletedMessage(msg); return normaliseDeletedMessage(msg);
const reactions = await db.getReactionsForMessage(msg.id); return msg;
return reactions.length > 0 ? { ...msg,
reactions } : msg;
} }
/** Hydrates an array of messages with their reactions. */ /** Hydrates an array of messages with their reactions. */
export async function hydrateMessages( export async function hydrateMessages(
messages: Message[], messages: Message[],
db: DatabaseService _db: DatabaseService
): Promise<Message[]> { ): Promise<Message[]> {
return Promise.all(messages.map((msg) => hydrateMessage(msg, db))); return messages.map((msg) => msg.isDeleted ? normaliseDeletedMessage(msg) : msg);
} }
/** Builds a sync inventory item from a message and its reaction count. */ /** Builds a sync inventory item from a message and its reaction count.
*
* Reactions are read from the already-hydrated `msg.reactions` array (the
* persistence layer joins them in via `getMessages`), and attachment counts
* only come from the in-memory override. We deliberately avoid per-message
* DB lookups here so a whole-room inventory stays O(1) DB calls even when
* the room contains tens of thousands of messages.
*/
export async function buildInventoryItem( export async function buildInventoryItem(
msg: Message, msg: Message,
db: DatabaseService, _db: DatabaseService,
attachmentCountOverride?: number attachmentCountOverride?: number
): Promise<InventoryItem> { ): Promise<InventoryItem> {
if (msg.isDeleted) { if (msg.isDeleted) {
@@ -63,50 +67,49 @@ export async function buildInventoryItem(
}; };
} }
const reactions = await db.getReactionsForMessage(msg.id); const item: InventoryItem = {
const attachments = id: msg.id,
attachmentCountOverride === undefined
? await db.getAttachmentsForMessage(msg.id)
: [];
return { id: msg.id,
ts: getMessageTimestamp(msg), ts: getMessageTimestamp(msg),
rc: reactions.length, rc: msg.reactions?.length ?? 0
ac: attachmentCountOverride ?? attachments.length }; };
if (attachmentCountOverride !== undefined) {
item.ac = attachmentCountOverride;
}
return item;
} }
/** Builds a local map of `{timestamp, reactionCount, attachmentCount}` keyed by message ID. */ /** Builds a local map of `{timestamp, reactionCount, attachmentCount}` keyed by message ID.
*
* As with {@link buildInventoryItem}, reactions come from the already-hydrated
* `msg.reactions` array and attachment counts only come from the in-memory
* override map.
*/
export async function buildLocalInventoryMap( export async function buildLocalInventoryMap(
messages: Message[], messages: Message[],
db: DatabaseService, _db: DatabaseService,
attachmentCountOverrides?: ReadonlyMap<string, number> attachmentCountOverrides?: ReadonlyMap<string, number>
): Promise<Map<string, { ts: number; rc: number; ac: number }>> { ): Promise<Map<string, { ts: number; rc: number; ac: number }>> {
const map = new Map<string, { ts: number; rc: number; ac: number }>(); const map = new Map<string, { ts: number; rc: number; ac: number }>();
await Promise.all( for (const msg of messages) {
messages.map(async (msg) => { if (msg.isDeleted) {
if (msg.isDeleted) { map.set(msg.id, {
map.set(msg.id, { ts: getMessageTimestamp(msg),
ts: getMessageTimestamp(msg), rc: 0,
rc: 0, ac: 0
ac: 0 });
});
return; continue;
} }
const reactions = await db.getReactionsForMessage(msg.id); map.set(msg.id, {
const attachmentCountOverride = attachmentCountOverrides?.get(msg.id); ts: getMessageTimestamp(msg),
const attachments = rc: msg.reactions?.length ?? 0,
attachmentCountOverride === undefined ac: attachmentCountOverrides?.get(msg.id) ?? 0
? await db.getAttachmentsForMessage(msg.id) });
: []; }
map.set(msg.id, { ts: getMessageTimestamp(msg),
rc: reactions.length,
ac: attachmentCountOverride ?? attachments.length });
})
);
return map; return map;
} }

View File

@@ -13,10 +13,18 @@ export interface MessagesState extends EntityState<Message> {
loading: boolean; loading: boolean;
/** Whether a peer-to-peer sync cycle is in progress. */ /** Whether a peer-to-peer sync cycle is in progress. */
syncing: boolean; syncing: boolean;
/** Whether a scroll-up older-page fetch is currently in flight. */
loadingOlder: boolean;
/** Most recent error message from message operations. */ /** Most recent error message from message operations. */
error: string | null; error: string | null;
/** ID of the room whose messages are currently loaded. */ /** ID of the room whose messages are currently loaded. */
currentRoomId: string | null; currentRoomId: string | null;
/**
* Conversation keys (`${roomId}:${channelId}`) that have been paginated
* all the way back to the start of the local DB history. Used by the
* scroll-up handler to stop issuing further DB pages.
*/
exhaustedConversations: Record<string, true>;
} }
export const messagesAdapter: EntityAdapter<Message> = createEntityAdapter<Message>({ export const messagesAdapter: EntityAdapter<Message> = createEntityAdapter<Message>({
@@ -27,8 +35,10 @@ export const messagesAdapter: EntityAdapter<Message> = createEntityAdapter<Messa
export const initialState: MessagesState = messagesAdapter.getInitialState({ export const initialState: MessagesState = messagesAdapter.getInitialState({
loading: false, loading: false,
syncing: false, syncing: false,
loadingOlder: false,
error: null, error: null,
currentRoomId: null currentRoomId: null,
exhaustedConversations: {}
}); });
export const messagesReducer = createReducer( export const messagesReducer = createReducer(
@@ -41,7 +51,8 @@ export const messagesReducer = createReducer(
...state, ...state,
loading: true, loading: true,
error: null, error: null,
currentRoomId: roomId currentRoomId: roomId,
exhaustedConversations: {}
}); });
} }
@@ -66,6 +77,30 @@ export const messagesReducer = createReducer(
error error
})), })),
// Load older messages - paginate backwards from the DB on scroll-up.
on(MessagesActions.loadOlderMessages, (state) => ({
...state,
loadingOlder: true,
error: null
})),
on(MessagesActions.loadOlderMessagesSuccess, (state, { conversationKey, messages, reachedEnd }) =>
messagesAdapter.upsertMany(messages, {
...state,
loadingOlder: false,
exhaustedConversations: reachedEnd
? { ...state.exhaustedConversations,
[conversationKey]: true }
: state.exhaustedConversations
})
),
on(MessagesActions.loadOlderMessagesFailure, (state, { error }) => ({
...state,
loadingOlder: false,
error
})),
// Send message // Send message
on(MessagesActions.sendMessage, (state) => ({ on(MessagesActions.sendMessage, (state) => ({
...state, ...state,
@@ -202,7 +237,10 @@ export const messagesReducer = createReducer(
return messagesAdapter.upsertMany(merged, { return messagesAdapter.upsertMany(merged, {
...state, ...state,
syncing: false syncing: false,
// Peer sync may have inserted messages older than our current oldest;
// reopen pagination so the scroll-up handler revisits the DB.
exhaustedConversations: {}
}); });
}), }),
@@ -221,7 +259,8 @@ export const messagesReducer = createReducer(
on(MessagesActions.clearMessages, (state) => on(MessagesActions.clearMessages, (state) =>
messagesAdapter.removeAll({ messagesAdapter.removeAll({
...state, ...state,
currentRoomId: null currentRoomId: null,
exhaustedConversations: {}
}) })
) )
); );

View File

@@ -36,6 +36,21 @@ export const selectMessagesSyncing = createSelector(
(state) => state.syncing (state) => state.syncing
); );
/** Whether a scroll-up older-page DB fetch is currently in flight. */
export const selectMessagesLoadingOlder = createSelector(
selectMessagesState,
(state) => state.loadingOlder
);
/** Whether the given conversation (`${roomId}:${channelId}`) has been
* paginated all the way back to the start of the local DB history.
*/
export const selectConversationExhausted = (conversationKey: string) =>
createSelector(
selectMessagesState,
(state) => state.exhaustedConversations[conversationKey] === true
);
/** Selects the ID of the room whose messages are currently loaded. */ /** Selects the ID of the room whose messages are currently loaded. */
export const selectCurrentRoomId = createSelector( export const selectCurrentRoomId = createSelector(
selectMessagesState, selectMessagesState,

View File

@@ -340,11 +340,12 @@ export class RoomMembersSyncEffects {
const role = room.hostId === currentUser.id const role = room.hostId === currentUser.id
? 'host' ? 'host'
: (isCurrentRoom ? currentUser.role : existingMember?.role ?? 'member'); : (isCurrentRoom ? currentUser.role : existingMember?.role ?? 'member');
const seenAt = existingMember?.lastSeenAt ?? currentUser.joinedAt ?? Date.now();
return { return {
...roomMemberFromUser(currentUser, Date.now(), role), ...roomMemberFromUser(currentUser, seenAt, role),
id: existingMember?.id ?? currentUser.id, id: existingMember?.id ?? currentUser.id,
joinedAt: existingMember?.joinedAt ?? currentUser.joinedAt ?? Date.now(), joinedAt: existingMember?.joinedAt ?? currentUser.joinedAt ?? seenAt,
avatarUrl: currentUser.avatarUrl ?? existingMember?.avatarUrl, avatarUrl: currentUser.avatarUrl ?? existingMember?.avatarUrl,
role role
}; };

View File

@@ -12,7 +12,8 @@ import {
of, of,
from, from,
EMPTY, EMPTY,
merge merge,
timer
} from 'rxjs'; } from 'rxjs';
import { import {
map, map,
@@ -60,6 +61,8 @@ type BlockedRoomAccessAction =
| ReturnType<typeof RoomsActions.forgetRoom> | ReturnType<typeof RoomsActions.forgetRoom>
| ReturnType<typeof RoomsActions.joinRoomFailure>; | ReturnType<typeof RoomsActions.joinRoomFailure>;
const VIEW_SERVER_LOAD_DELAY_MS = 75;
@Injectable() @Injectable()
export class RoomsEffects { export class RoomsEffects {
private actions$ = inject(Actions); private actions$ = inject(Actions);
@@ -608,7 +611,12 @@ export class RoomsEffects {
navigationRequestVersion navigationRequestVersion
}); });
this.router.navigate(['/room', room.id]); window.setTimeout(() => {
if (this.signalingConnection.isCurrentRoomNavigation(room.id, navigationRequestVersion)) {
void this.router.navigate(['/room', room.id]);
}
}, 0);
return of(RoomsActions.viewServerSuccess({ room })); return of(RoomsActions.viewServerSuccess({ room }));
}; };
@@ -634,7 +642,9 @@ export class RoomsEffects {
onViewServerSuccess$ = createEffect(() => onViewServerSuccess$ = createEffect(() =>
this.actions$.pipe( this.actions$.pipe(
ofType(RoomsActions.viewServerSuccess), ofType(RoomsActions.viewServerSuccess),
mergeMap(({ room }) => [MessagesActions.loadMessages({ roomId: room.id }), UsersActions.loadBans()]) switchMap(({ room }) => timer(VIEW_SERVER_LOAD_DELAY_MS).pipe(
mergeMap(() => [MessagesActions.loadMessages({ roomId: room.id }), UsersActions.loadBans()])
))
) )
); );

View File

@@ -42,6 +42,20 @@ function getDefaultTextChannelId(room: Room): string {
return resolveActiveTextChannelId(enrichRoom(room).channels, 'general'); return resolveActiveTextChannelId(enrichRoom(room).channels, 'general');
} }
function activateRoomView(state: RoomsState, room: Room, isConnecting: boolean, updateSavedRooms = true): RoomsState {
const enriched = enrichRoom(room);
return {
...state,
currentRoom: enriched,
savedRooms: updateSavedRooms ? upsertRoom(state.savedRooms, enriched) : state.savedRooms,
isConnecting,
signalServerCompatibilityError: null,
isConnected: true,
activeChannelId: getDefaultTextChannelId(enriched)
};
}
/** Upsert a room into a saved-rooms list (add or replace by id) */ /** Upsert a room into a saved-rooms list (add or replace by id) */
function upsertRoom(savedRooms: Room[], room: Room): Room[] { function upsertRoom(savedRooms: Room[], room: Room): Room[] {
const normalizedRoom = enrichRoom(room); const normalizedRoom = enrichRoom(room);
@@ -220,27 +234,24 @@ export const roomsReducer = createReducer(
})), })),
// View server - just switch the viewed room, stay connected // View server - just switch the viewed room, stay connected
on(RoomsActions.viewServer, (state) => ({ on(RoomsActions.viewServer, (state, { room, skipBanCheck }) => {
...state, if (skipBanCheck) {
isConnecting: true, return {
signalServerCompatibilityError: null, ...activateRoomView(state, room, true, false),
error: null error: null
})), };
}
on(RoomsActions.viewServerSuccess, (state, { room }) => {
const enriched = enrichRoom(room);
return { return {
...state, ...state,
currentRoom: enriched, isConnecting: true,
savedRooms: upsertRoom(state.savedRooms, enriched),
isConnecting: false,
signalServerCompatibilityError: null, signalServerCompatibilityError: null,
isConnected: true, error: null
activeChannelId: getDefaultTextChannelId(enriched)
}; };
}), }),
on(RoomsActions.viewServerSuccess, (state, { room }) => activateRoomView(state, room, false, false)),
// Update room settings // Update room settings
on(RoomsActions.updateRoomSettings, (state) => ({ on(RoomsActions.updateRoomSettings, (state) => ({
...state, ...state,

View File

@@ -10,7 +10,7 @@
/> />
<meta <meta
http-equiv="Content-Security-Policy" http-equiv="Content-Security-Policy"
content="default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: http: https:; script-src-elem 'self' 'unsafe-inline' 'unsafe-eval' data: blob: http: https:; connect-src 'self' blob: ws: wss: http: https:; media-src 'self' blob: file:; img-src 'self' data: blob: http: https:; frame-src https://www.youtube-nocookie.com https://open.spotify.com https://w.soundcloud.com;" content="default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: http: https:; script-src-elem 'self' 'unsafe-inline' 'unsafe-eval' data: blob: http: https:; connect-src 'self' blob: ws: wss: http: https:; media-src 'self' blob: file:; img-src 'self' data: blob: file: http: https:; frame-src https://www.youtube-nocookie.com https://open.spotify.com https://w.soundcloud.com;"
/> />
<link <link
rel="icon" rel="icon"

42
website/CONTEXT.md Normal file
View File

@@ -0,0 +1,42 @@
# Marketing Site (website)
Owns the public-facing Angular 19 marketing site — landing pages, screenshots, feature highlights, and download links pointing to release artifacts. Independent from the product runtime: shares no code or wire schemas with toju-app, electron, or the signaling server.
> **Format reference:**
> - **Vocabulary** — bold term, one-sentence definition, aliases to avoid.
> - **Relationships** — bullets with bold terms and cardinality.
> - **Boundaries / IO** — what this subdomain exposes and consumes.
> - **Invariants** — rules that always hold.
> - **Flagged ambiguities** — terms in dispute with proposed resolutions.
>
> See `agents-docs/AGENTS_CONTEXT.md` for the contract. Update in the same turn a trigger fires (see `agents-docs/AGENT_WORKFLOW.md` § CONTEXT.md upkeep).
## Vocabulary
| Term | Definition | Aliases to avoid |
|------|------------|------------------|
| **Marketing site** | The Angular 19 app under `website/`, served separately from the product client. | "landing page" (it has multiple pages) |
| **Release manifest** | The release-metadata JSON the marketing site links to for download buttons; produced by `tools/generate-release-manifest.js` and published by Gitea Workflows. | "version manifest" |
## Relationships
- The **Marketing site** links to release artifacts produced by the Gitea Workflows under `.gitea/workflows/release-draft.yml` and `publish-draft-release.yml`.
- It does **not** consume the signaling server, the product client, or shared kernel types — independent codebase.
## Boundaries / IO
- **Exposes:** the public website bundle, deployed by `.gitea/workflows/deploy-web-apps.yml`.
- **Consumes:** the release manifest URL and download links; static assets under `website/src/images/`.
## Invariants
- The marketing site has its own `package.json` and its own Angular version — do **not** hoist its dependencies into the root workspace.
- It must remain functional with no backend (static deploy); any dynamic behavior should fail gracefully.
## Flagged ambiguities
- _None recorded yet._
---
*Agent-procedural rules (TDD, lint) live in `/AGENTS.md`. This file is the bounded-context domain artefact for the marketing site.*