Roomnote — Privacy-first multiplayer conversation capture

01 · Decision

The concept is viable if “speaker” is treated as a confidence-bearing claim.

A room can consolidate local transcripts deterministically. Reliable identity depends on the capture topology, not merely the number of phones listening.

Certain

Participant source

The server knows which authenticated device emitted each transcript event. Remote participants with one device per audio channel are directly attributable.

Probabilistic

Acoustic speaker

In one physical room, several phones hear the same voice. Proximity, normalized SNR, timing, and ownership form evidence—not proof.

Deterministic

Transcript consensus

Overlapping hypotheses can be time-clustered, aligned, ranked, and revisioned without a server LLM. Original device versions remain auditable.

Topology	What identifies the speaker	Expected attribution	Primary failure	Recommendation
Remote one participant per channel	Authenticated media/text channel	High	Shared device or account handoff	Use channel identity as authoritative.
Co-located phone near each owner	Owner prior + normalized acoustic evidence	Conditional	Phones move; automatic gain control distorts loudness.	Calibrate, score, and allow “unknown.”
Co-located phones scattered on table	Relative location and signal only	Low–medium	Nearest phone is not necessarily the speaker’s phone.	Do not attach names automatically.
Hybrid room plus remote channels	Remote channel identity + room inference	Mixed	Remote playback is re-captured by room devices.	Use one room renderer and suppress echo copies.
Close-talk headset/lapel per person	Authenticated personal microphone	Highest	Hardware friction and battery	Use for decisions, interviews, or regulated use.

More microphones create redundancy, not automatically more truth.

Published multi-microphone systems improve recognition by synchronizing and processing audio streams, often with diarization and speech enhancement. One study using 11 distributed microphones reduced character error rate from 38.2% for a center-table microphone to 28.7%. That result demonstrates the value of diverse channels, but it does not validate a text-only fusion design because the research pipeline used audio synchronization, separation, and diarization. 10

02 · Problem model

Separate four problems that meeting products often collapse.

The architecture becomes tractable when capture, attribution, consensus, and knowledge are modeled independently.

Capture: Convert microphone input into provisional and finalized text on each device. Apple’s SpeechAnalyzer coordinates live speech analysis; SpeechTranscriber is intended for general conversational transcription. 01
Attribution: Determine whether a text span came from a known remote channel, a likely nearby participant, room playback, or an unresolved speaker.
Consensus: Align competing word sequences and select or combine the best-supported version while retaining every source hypothesis and revision.
Knowledge: Promote transcript spans into notes, decisions, questions, and action items. These are collaborative objects with provenance—not edits to the historical transcript.

Prior constraint preserved

Private in the recognition path

Capture, audio buffering, speech recognition, and incremental audio disposal remain on device. The server receives text and bounded metadata. The system should still work when external AI services are unavailable.

New boundary

Collaborative does not mean local-only

Once transcript events enter a room, text is server-visible unless a client-side coordinator performs fusion. The product must say “audio stays on device,” not imply that all conversation data stays local.

Clarify the phrase “without AI.”

On-device speech recognition is itself model-based. In this architecture, the boundary means no server-side audio model and no per-participant LLM in the live recognition path. A governed room-level model may later summarize stable, consented shared state. This distinction should appear in consent language and product claims.

Operational constraint

Continuous capture is an active audio session

Apple documents background recording when the app declares the audio background mode, but that is not a promise of invisible or unlimited capture. Production behavior still needs explicit permission and recording state, interruption and route-change recovery, incremental finalization, and battery/thermal testing. 21

Platform constraint

Android must be capability-gated

Android exposes an on-device recognizer constructor, while also warning that the general speech-recognition service may use remote servers and is not intended for continuous recognition. Treat Android as a verified adapter per device and language—not as an automatic parity promise. 05

The hardest case is simultaneous speech in a reverberant room.

Text-only server fusion cannot separate two people whom each on-device recognizer merged into one hypothesis. The baseline should mark overlapping or contradictory spans as disputed. Source separation belongs in an optional, explicitly consented capture tier.

03 · Available signals

Use low-risk local evidence, normalized per device.

“Signal strength” should mean acoustic quality relative to each device’s own noise floor—not raw volume and not network RSSI.

Signal	Computed where	What it contributes	Limit	Baseline?
Authenticated participant/device ID	Identity + room service	Provenance and owner prior	Device owner may not be current speaker.	Yes
Audio time range	On-device transcriber	Cross-device temporal alignment	Clocks need offset and uncertainty estimates.	Yes
Transcription confidence	On-device transcriber	Ranks competing hypotheses	Confidence is engine-specific and may be miscalibrated.	Yes
SNR above rolling noise floor	Local DSP	Proximity/clarity evidence	AGC, cases, orientation, and pockets change gain.	Yes
VAD / speech-active range	OS speech detector or local DSP	Segments speech and avoids silence traffic	Overlapping speech remains one active interval.	Yes
Playback-active marker	Local app	Flags likely echo contamination	Cannot identify audio played by another app/device.	Yes
Route / AEC / clipping state	Local audio session	Quality penalties and diagnostics	Availability and effectiveness vary by device.	Yes
Cross-correlation / TDOA	Requires comparable audio features	Spatial delay and source location	Needs tight synchronization and richer audio-derived data.	No
Speaker embedding	Optional on-device model	Voice identity verification	It is biometric ML, needs enrollment and stronger governance.	Later tier

Platform capability

Apple exposes time and confidence attributes.

SpeechTranscriber can provide tentative results plus finalized results, and its result attributes include audio time ranges and transcription confidence. These are exactly the local signals the room protocol needs. 02 03

Calibration requirement

Never compare raw dBFS across phones.

Different microphones, gain control, cases, placement, and audio routes make absolute levels incomparable. Compare speech energy with that device’s rolling noise floor, track clipping, and calibrate scores against recorded test rooms.

Recommended quality vector

Send bounded scalars for each finalized span: normalized SNR, noise floor, clipping ratio, VAD coverage, transcriber confidence, clock uncertainty, route class, AEC state, playback state, and local finalization latency. Do not send spectrograms, embeddings, or audio fingerprints in the default privacy tier.

04 · Reference architecture

Local perception. Shared event log. Deterministic fusion. Governed AI.

The immutable transcript path and the collaborative note path are related by provenance, but they use different consistency models.

System boundary and information flow

Core content does not depend on JavaScript. Zoom buttons progressively enhance this scalable diagram; the viewport remains scrollable without them.

Transcript consistency

Authoritative event log

Transcript hypotheses are append-only events. The fusion service alone emits canonical revisions. This prevents concurrent clients from independently “correcting” history and preserves auditability.

Note consistency

CRDT collaboration

Notes, decisions, and action items are user-editable shared objects. Yjs and Automerge are designed to merge concurrent edits; Yjs providers commonly organize synchronization by room name. 16 17

Recommended transport: Socket.IO for the pilot, with application-level durability.

WebSocket provides a two-way channel over one connection. Socket.IO adds acknowledgements, retries, rooms, and connection recovery, but default delivery is at-most-once and recovery can fail. Persist events, use idempotency keys and offsets, and resynchronize after reconnect. 13 14 15

05 · Input vs output

Make playback a first-class room event.

A device can identify audio that its own app renders. It cannot reliably know that another phone, television, or unrelated app produced a sound.

1 · Declare Choose one room renderer Only one co-located device plays each remote stream aloud.

2 · Reference Emit playback windows Include source participant, media event ID, and server time range.

3 · Cancel Enable local AEC The renderer subtracts its known output from microphone capture where supported.

4 · Penalize Flag room captures Other devices mark overlapping segments as likely playback contamination.

5 · Suppress Keep the source channel The remote participant’s own transcript wins; room echoes become provenance only.

What AEC does

Subtract known rendered audio.

Android describes AEC as removing the remote party’s received signal from captured input. Apple exposes a preference for echo-cancelled input, and browsers expose an echo-cancellation constraint whose exact behavior is user-agent controlled. 04 07 08

What AEC cannot promise

Identify arbitrary environmental audio.

If another device plays sound, the listener lacks the exact playback reference. The server can infer contamination from coordinated playback windows, but external media remains acoustically indistinguishable from a human source without richer local analysis.

Operational control beats a harder signal-processing problem.

For hybrid rooms, route remote audio to headsets or a single designated speaker. Avoid several phones playing the same remote audio. The best echo-removal strategy is to prevent duplicate acoustic output before attempting to classify it.

06 · Fusion pipeline

Consolidate in stages so every decision remains explainable.

The server should never concatenate every local transcript. It forms temporal clusters, compares hypotheses, computes attribution, and emits a single revisioned canonical span.

Stage 1 Normalize time Estimate server offset, round-trip uncertainty, and drift for each device.
Stage 2 Cluster spans Group events by temporal overlap, language, and lexical similarity.
Stage 3 Classify source Direct remote, likely nearby owner, room playback, or ambiguous.
Stage 4 Build consensus Align tokens; weight quality and agreement; preserve alternatives.
Stage 5 Publish revision Emit text, speaker claim, confidence, sources, and superseded version.

Illustrative example · not a benchmark

Three devices hear the same utterance

Source	Local result	Normalized SNR	STT confidence	Owner prior
Alice’s phone	“Ship it Friday after legal review.”	+18 dB	0.91	Yes
Bob’s phone	“Ship it Friday after the legal review.”	+10 dB	0.94	No
Cara’s phone	“Ship Friday after legal review.”	+7 dB	0.82	No
Canonical revision	Alice · “Ship it Friday after legal review.”	Text agreement: high · speaker claim: inferred · source count: 3

Text confidence

Consensus is not a vote count.

Several devices running the same recognizer in the same room produce correlated errors. De-duplicate engine/environment correlation before calculating support. Rank by calibrated quality and token agreement, then retain dissenting alternatives.

Speaker confidence

Calibrate, do not invent weights.

Begin with a transparent scoring model using ownership, normalized SNR, clock uncertainty, AEC/playback state, clipping, and consistency. Learn thresholds from labeled pilot rooms. Show “unknown” below the release threshold.

Research precedent

Output voting and distributed microphones are established patterns.

ROVER aligns multiple recognition outputs and votes over competing word hypotheses. Newer meeting-output fusion work combines timing and speaker labels, while asynchronous microphone research explicitly includes synchronization, diarization, recognition, and duplicate reduction. These sources support the decomposition, but the proposed metadata-only baseline remains an engineering hypothesis that must be validated. 12 11 09

07 · Event contracts

Make provenance, revision, and uncertainty impossible to omit.

The protocol should carry finalized text as durable events. Provisional text is ephemeral UI state unless product requirements demand replay.

type ConfidenceBand = "high" | "medium" | "low" | "unknown";
type SpeakerBasis =
  | "remote-channel"
  | "near-device-inference"
  | "human-confirmed"
  | "unresolved";

interface TranscriptObservationV1 {
  schema: "roomnote.observation.v1";
  eventId: string;             // UUIDv7; idempotency key
  roomId: string;
  participantId: string;       // authenticated contributor
  deviceId: string;            // registered device, rotated by policy
  segmentId: string;           // stable across provisional revisions
  revision: number;

  localMonotonicStartMs: number;
  localMonotonicEndMs: number;
  estimatedServerStartMs: number;
  estimatedServerEndMs: number;
  clockUncertaintyMs: number;

  text: string;
  locale: string;
  isFinal: boolean;
  sttConfidence?: number;      // engine-specific; calibrate before mixing

  quality: {
    snrAboveNoiseFloorDb?: number;
    clippingRatio?: number;
    vadCoverage?: number;
    audioRoute: "built-in" | "headset" | "bluetooth" | "unknown";
    aecActive: boolean | "unknown";
    playbackActive: boolean;
    playbackEventIds?: string[];
  };

  privacy: {
    rawAudioUploaded: false;
    consentEpoch: string;      // ties capture to active consent
  };
}

interface CanonicalTranscriptRevisionV1 {
  schema: "roomnote.canonical.v1";
  canonicalId: string;
  revision: number;
  supersedes?: number;
  text: string;
  sourceEventIds: string[];
  speaker?: {
    participantId?: string;
    label: string;             // may be "Unknown speaker"
    basis: SpeakerBasis;
    confidence: number;
    band: ConfidenceBand;
  };
  textConfidence: number;
  disputed: boolean;
  createdAt: string;
  algorithmVersion: string;
}

Delivery contract

At-least-once ingest, idempotent apply.

Persist locally before emit. Retry until acknowledged. The server commits by event ID and returns the durable offset. A duplicate event is success, not an error.

Revision contract

Never mutate an observation.

On-device finalization creates a higher revision. Canonical fusion creates its own revision stream. Human corrections attach separate patches and attribution.

Why UUIDv7, monotonic time, and server time all appear

UUIDv7 provides sortable uniqueness. Monotonic time protects local duration from wall-clock changes. Estimated server time aligns devices, while clockUncertaintyMs prevents the fusion engine from pretending that alignment is exact. For audio-level spatial processing, device sampling clocks drift and require substantially more sophisticated synchronization than ordinary socket timestamps. Distributed-array research treats this as a first-class problem. 18

08 · Atomic notes and AI budget

The transcript is evidence. Notes are claims derived from evidence.

Do not let a summary overwrite what people actually said. Build small collaborative objects that cite transcript ranges and expose who or what created them.

Note

Observation

A concise fact or context statement. May be created manually, deterministically, or by AI.

Decision

Chosen state

Decision text, owner, effective time, status, and supporting transcript citations.

Action

Commitment

Verb, owner, due date, status, confidence, source spans, and confirmation state.

Question

Unresolved item

Open issue, accountable party, next checkpoint, and links to contradictory evidence.

Before AI

Use deterministic reducers.

De-duplicate transcript spans, detect explicit “I will”/“we decided” phrases, resolve mentioned participants from room identity, group topic windows, and invite human confirmation. Rules can create candidates without presenting them as settled facts.

With AI

Summarize stable deltas.

Send only newly stabilized canonical spans plus current open-note state. Hash the input window, cache outputs, and skip unchanged windows. Run at end-of-room or explicit checkpoints, not once per device or partial token.

Local Provisional text Never summarized. It may change.

Room Canonical stable span Eligible only after fusion and a stability window.

Rules Candidate atoms Cheap extraction and participant confirmation.

AI Delta synthesis One governed call for changed evidence.

Human Accept or revise Authorship and provenance remain visible.

Cost scales with changed conversation, not connected participants.

Ten people should not trigger ten summaries. The room owns one canonical transcript and one atomic knowledge state. AI operates over deltas to those shared artifacts.

09 · Alternatives

Choose the privacy–accuracy tier explicitly.

The text-only baseline is the best first implementation. It is not the highest-accuracy technical option.

Option	Server receives	Speaker accuracy	Privacy	Complexity	Verdict
A · Text + scalar metadata	Text, time, confidence, normalized quality	Conditional	Strongest practical	Medium	Recommended V1
B · On-device speaker verification	Text + local identity claim	Potentially high	Biometric model/enrollment	High	Optional, governed tier
C · Ephemeral encrypted audio snippets	Selected audio windows	Higher ceiling	Breaks no-audio boundary	Very high	Reject for baseline
D · Client-elected fusion coordinator	Encrypted relay only	Same as client model	Server-blind possible	Very high	Future confidential rooms
E · One close-talk mic per person	Text + known channel	Highest without server audio	Strong	Hardware/ops	Accuracy tier for serious use

Reversible V1 choices

Socket.IO vs raw WebSocket, Yjs vs Automerge, fusion thresholds, Postgres schema details, UI confidence bands, and checkpoint frequency can change behind versioned contracts.

Durable decisions

Whether raw audio crosses the boundary, whether voice identity is treated as biometric data, whether the server can read room text, and whether historical observations can be mutated define the trust model. Decide these first.

Why not full end-to-end encryption in the recommended baseline?

Messaging Layer Security provides group keying with forward secrecy and post-compromise security, but a server that must read text to fuse hypotheses is intentionally inside the trust boundary. An E2EE room requires fusion on an elected client or trusted execution environment, with coordinator failover and deterministic replay. MLS is relevant for the confidential-room alternative, not a magic layer that leaves server computation unchanged. 19

10 · Privacy, consent, and security

Opt-in is a live room state, not a one-time permission dialog.

The product must continuously communicate what is captured, what leaves each device, who can see it, and how to stop or delete it.

Before capture

Explicit room consent

Show participants, purpose, data types, retention, AI policy, and whether speaker inference is enabled. Joining does not silently start capture.

During capture

Persistent visible state

Use system microphone indicators plus an in-app “Recording locally · sharing text” state. Each person can pause their contribution without leaving the room.

After capture

Review and control

Expose contributors, source spans, retention deadline, export, correction, and deletion controls. Record consent withdrawal as an event.

Threat	Control	Evidence / audit
Unauthorized room join	Short-lived identity-bound room token; membership rechecked on connect and every privileged event.	Join/leave/deny events without transcript contents.
Cross-room data leak	Tenant + room authorization in storage keys, subscriptions, queries, and background jobs.	Isolation tests and policy decision logs.
Replay or duplicate event	Signed session, schema version, UUID event ID, monotonic revision, idempotent commit.	Duplicate count and original durable offset.
Socket abuse	WSS, origin allowlist, message schema validation, size limits, rate limits, heartbeat, backpressure.	Security events; never log full transcript payloads. 20
AI over-sharing	Room AI policy, stable-delta minimization, approved model gateway, purpose-bound prompt, output provenance.	Input hash, model/version, policy decision, output link.
False speaker attribution	Confidence threshold, unknown state, participant correction, disputed label, no biometric claim in V1.	Algorithm version, evidence vector, correction history.

Platform alignment

On-device processing and transparency are established privacy principles.

Apple’s privacy guidance explicitly frames data minimization, on-device processing, transparency and control, and security protections as design pillars. 06

Jurisdictional constraint

Recording and transcription rules vary.

This architecture is not legal advice. Enterprise deployment needs a jurisdiction-aware consent policy, purpose/retention rules, labor and works-council review where applicable, and an explicit prohibition on covert capture.

11 · Pilot and evaluation

Prove the attribution envelope before building the note product around it.

The first deliverable should be a measurement harness, not a polished meeting assistant.

Pilot scope

Three to six iPhones, one physical room

iOS 26+, Swift 6, SpeechAnalyzer/SpeechTranscriber.
Each phone remains near its authenticated owner.
Sequential speech, overlap, movement, remote playback, music/TV, interruption, and offline/reconnect scenarios.
No audio egress. Local consented audio may be retained only in the research build to create ground truth, then deleted.

Ground truth

Independent human annotation

Reference text and speaker time ranges.
Device positions and route state.
Room noise, reverberation proxy, movement, and overlap.
Separate scores for wording, speaker attribution, duplicate suppression, and latency.

Gate	Proposed target	Why it matters	Release response
Raw audio egress	0 bytes in packet capture	Validates the central privacy claim.	Hard stop on any failure.
Duplicate suppression	≥ 98% on non-overlap speech	Prevents multi-device transcript inflation.	Tune clustering before UX pilot.
Speaker precision	≥ 95% when a name is auto-shown	Precision matters more than labeling every span.	Raise threshold; emit more “unknown.”
Speaker coverage	Measure, do not pre-commit	Reveals how often the system can be confidently useful.	Choose hardware or local-model tier from evidence.
Wording improvement	≥ 10% relative WER reduction vs median single device	Tests whether text consensus adds value.	Otherwise select best channel instead of fusing.
Reconnect integrity	0 lost finalized events in 30-second outage	Conversation data cannot silently disappear.	Fix durable local spool/offset replay.
Canonical latency	p95 ≤ 2.5 s after local finalization	Keeps shared notes conversational.	Profile transport, clustering window, and storage.

Targets above are proposed product gates, not published performance claims. They must be adjusted after the first labeled dataset.

320 / 390 px

Mobile room state

Consent, capture, pause, speaker uncertainty, transcript, and recovery must remain understandable with one thumb and enlarged text.

Device stress

Long-session integrity

Test model installation, airplane mode, hours-long capture, thermal pressure, memory bounds, screen lock, interruptions, route changes, and finalization.

Adversarial room

False-attribution pressure

Swap phones, put devices in pockets, move speakers, play recorded voices, interrupt consent, join late, and speak simultaneously.

12 · Execution roadmap

Build the evidence path first, then the knowledge experience.

Each phase has a distinct learning goal and a stop condition.

Phase 0 · 2–3 weeks

Local capture and measurement harness

Implement bounded AVAudioEngine capture, SpeechAnalyzer results, local DSP vector, incremental persistence, consent epoch, route/interruption handling, and exportable labeled test sessions. Exit: raw audio egress is zero and on-device events are replayable.

Phase 1 · 3–5 weeks

Room ingest and transcript fusion

Add identity-bound Socket.IO rooms, durable offsets, time synchronization, event log, clustering, best-channel selection, consensus, confidence bands, and human speaker correction. Exit: pilot gates for duplicate suppression and named-speaker precision pass.

Phase 2 · 3–4 weeks

Atomic collaborative knowledge

Add note/decision/action/question entities, CRDT synchronization, transcript citations, authorship, conflict UI, offline edits, and export. Exit: users can reconstruct why every important atom exists.

Phase 3 · controlled rollout

Governed summarization

Introduce stable-delta AI calls through a policy gateway, evaluation datasets, prompt/version lineage, participant review, and cost telemetry. Exit: summaries improve task completion without changing source evidence or exceeding the room AI budget.

Decision checkpoint

Choose the accuracy tier from measured coverage.

If high-precision attribution labels too little of the conversation, do not quietly lower the threshold. Choose close-talk hardware, optional on-device speaker verification, client-side audio fusion, or an explicitly less ambitious “speaker unknown” product.

Recommended next action

Build Phase 0 as a research instrument. Capture a small, diverse, consented dataset in three room types. Use it to answer one question: When each phone stays near its owner, how often can normalized local evidence label a speaker at ≥95% precision? That result determines whether Roomnote is primarily a collaborative transcript, an attributed meeting system, or a hardware-assisted capture product.

13 · Sources and method

Evidence is adjacent to claims; the registry stays available without dominating the reading flow.

Research was refreshed on 21 July 2026. Primary platform documentation, standards, and original research were preferred. Recommendations and proposed pilot targets are explicitly labeled.

Research brief used for this artifact

Realistic user prompt: “Create a deeply researched, self-contained architecture guide for a privacy-first ‘multiplayer notes’ system. Multiple opted-in participants join a room. Every device performs continuous speech-to-text locally and sends only attributed text plus minimal acoustic metadata to a shared service. Determine how the service can align overlapping captures, distinguish live input from device output, infer which person spoke, consolidate a canonical transcript, and maintain atomic shared notes, decisions, and action items. Minimize server AI use; reserve AI for governed summarization of stable shared state. Compare text-only fusion, on-device speaker verification, server audio processing, close-talk microphones, and client-coordinated alternatives. Include data contracts, socket/recovery design, privacy boundaries, failure modes, pilot metrics, implementation phases, evidence quality, limitations, and direct sources. Deliver one mobile-first, accessible, offline-readable HTML file whose core content works without JavaScript.”

Working contract and methodology

Purpose and audience

Support an architecture decision and feasibility pilot. Primary audiences are a solution architect, mobile engineers, collaboration/backend engineers, privacy/security reviewers, and product owners.

Scope and exclusions

Focus: on-device recognition, multi-user rooms, metadata-only fusion, speaker confidence, collaborative notes, AI minimization. Excluded: covert capture, production legal advice, biometric speaker recognition implementation, and server-side raw-audio processing in the baseline.

Provisional thesis tested

A text-plus-metadata room can improve transcript quality and infer speakers conditionally, but it must not claim robust diarization. Evidence that would change the recommendation: high-precision attribution failing even with near-owner phones, or text consensus failing to outperform best-channel selection.

Evidence treatment

Facts are sourced. Architecture choices are recommendations. Cross-source extrapolations are inferences. Numeric product gates are proposals. Research using raw audio is not treated as proof for metadata-only fusion.

Platform and privacy sources · S01–S08 + S21

S01
Apple — SpeechAnalyzerPrimary platform documentation. Establishes the analysis-session and speech-module capability. Current access: 2026-07-21. Confidence: high; implementation behavior still requires device testing.
S02
Apple — SpeechTranscriber volatile resultsPrimary API documentation. Supports tentative results in addition to finalized results. Confidence: high.
S03
Apple — SpeechTranscriber result attributesPrimary API documentation for audio time range; related transcription-confidence attribute is cross-referenced by Apple. Confidence: high.
S04
Apple — Prefer echo-cancelled inputPrimary API documentation. Establishes an echo-cancelled-input preference, not a universal quality guarantee. Confidence: high for capability; medium for device-specific results.
S05
Android — SpeechRecognizerPrimary platform documentation. Exposes createOnDeviceSpeechRecognizer but warns the general service may use remote servers and is not intended for continuous recognition. Confidence: high; vendor behavior varies.
S06
Apple — Privacy pillars in focusPrimary design guidance. Frames data minimization, on-device processing, transparency/control, and security protections. Confidence: high as design guidance.
S07
Android — AcousticEchoCancelerPrimary API documentation. AEC removes the known remote signal from captured audio; availability is device-dependent. Updated 2025-02-10. Confidence: high.
S08
W3C — Media Capture and StreamsWeb standard defining echo-cancellation constraints and user-agent discretion. Snapshot dated 2025-10-09. Confidence: high for web semantics.
S21
Apple — AVAudioSession record categoryPrimary platform documentation. States that recording can continue in the background when the app includes the audio background mode. Confidence: high for capability; long-session reliability and policy fit still require device testing.

Speech fusion and distributed microphone research · S09–S12

S09
Yoshioka et al. — Meeting Transcription Using Asynchronous Distant MicrophonesOriginal research on speaker-annotated meeting transcription using asynchronous microphones. Strong evidence for decomposition; uses audio processing beyond this baseline.
S10
Horiguchi et al. — Utterance-Wise Meeting Transcription Using Asynchronous Distributed MicrophonesPeer-reviewed Interspeech 2020 paper. Reports synchronization, diarization, enhancement, recognition, and duplicate reduction with 11 distributed microphones. High relevance; not text-only.
S11
Kamo et al. — MOVER: Combining Multiple Meeting Recognition Systems2025 preprint on combining outputs that differ in timing and speaker labels. Relevant modern precedent; not treated as independently replicated production evidence.
S12
NIST-hosted OpenASR system description citing Fiscus ROVERAuthoritative host and trace to the foundational 1997 Recognizer Output Voting Error Reduction method. Used as historical support for aligned hypothesis voting.

Collaboration, transport, synchronization, and security · S13–S20

S13
IETF RFC 6455 — The WebSocket ProtocolStandards-track definition of two-way client/server communication and framing over TCP. Confidence: high.
S14
Socket.IO — Delivery guaranteesOfficial documentation. Ordering is guaranteed, arrival is at-most-once by default, stronger semantics are application responsibilities. Updated 2026-06-09.
S15
Socket.IO — Connection state recoveryOfficial documentation. Recovery can restore missed packets but is not guaranteed; full state synchronization remains necessary. Current access: 2026-07-21.
S16
Yjs documentationOfficial project documentation for shared CRDT data types and automatic merging. Useful for the editable note layer, not canonical transcript authority.
S17
Automerge documentationOfficial project documentation for local-first collaborative data. Credible alternative to Yjs; implementation selection remains reversible.
S18
Liu et al. — Clock synchronization errors in distributed microphone arraysOriginal research showing separate capture clocks create synchronization error and drift. Supports the boundary between event alignment and audio-array processing.
S19
IETF RFC 9420 — Messaging Layer SecurityStandards-track asynchronous group keying with forward secrecy and post-compromise security. Relevant to a client-coordinated E2EE alternative.
S20
OWASP — WebSocket Security Cheat SheetApplication-security guidance for handshake authorization, message validation, origin controls, rate limits, safe logging, and operational monitoring.

Limitations and open questions

No source directly validates the proposed text-plus-scalar-metadata attribution algorithm. That is the central pilot hypothesis.
Apple and Android on-device model availability, language coverage, confidence calibration, long-session behavior, and AEC quality require real-device validation.
Speaker precision will depend strongly on device placement and human behavior. Coverage may be low at the precision threshold.
Server-visible text is not end-to-end encrypted in the recommended architecture. Confidential rooms require a different computation boundary.
Legal requirements for recording, transcription, employment monitoring, biometrics, and retention vary by context and jurisdiction.
Proposed latency, WER, and attribution gates are product targets, not guarantees.