# Product requirements

Document: SPEC-001. Revision: 0.22. Date: 2026-11-07. Lifecycle: Draft with confirmed requirement register. Supersedes: none.

## Native Linux successor (D-193)

R-124 selects a native Qt Linux implementation and native desktop behavior, replacing D-028's Linux Electron/shared-renderer target. R-125/D-194 subsequently selects the tabbed main window, creation actions on the two tree roots, the combined ordered direct-conversation/pinned-contact tree and removal of the toolbar/right pane. Other specific amendments remain proposed in SPEC-005/P-037 to their stated extent. Existing feature, security, media and server contracts continue to apply. The released alpha.51 Linux client remains Electron-based pending delivery of its successor; no native implementation or resource savings are claimed here.

## Approved video-delivery successor — D-167

D-167/SPEC-024 refines R-120: screen video synchronizes with its presentation sound; microphone alignment is best effort and microphone playback never waits for video. R-032 quality/continuity applies to presentations. R-118 retains administrative bitrate choices but distinguishes native hard policing from managed rate targets. R-043 retains native relay enforcement and adds explicitly reported managed-provider enforcement without a universal partition cutoff. These scoped successors do not change direct-message confidentiality or webcam lip sync. See [SPEC-024](024-presentation-delivery.md).


## Purpose

Provide persistent, low-friction collaboration centred on gaming voice rooms, with text, direct communication, screen sharing, and configurable meetings. Federation and independent operation are core capabilities. Open source and corporate communities use the same protocol with suitable policy and presentation.

The named products are references for useful behaviour, not a promise of complete feature parity, compatible accounts, or wire compatibility. “Disco” and “Ventril” in the initial description are interpreted as Discord and Ventrilo, consistent with the later explicit list.

## Confirmed requirement register

All entries below are CONFIRMED. R-001–R-034 originate in the initial brief, with human edits and later refinements retained; R-016 is refined by D-017. R-035 onward record explicit answers from the question rounds on 2026-10-18; see the decision register for their scope.

| ID | Requirement |
| --- | --- |
| R-001 | The human owns the specification; the LLM reviews, refines, and subsequently implements it. |
| R-002 | Feature and behavioural changes start with reviewed specification changes or explicitly superseding specifications. |
| R-003 | Bug fixes include specification review; simple fixes may need no amendment, while larger fixes may require amendments. |
| R-004 | Active specifications stay consistent with code; superseded or deprecated material is explicitly marked. |
| R-005 | Gaming is the primary use case; open source and corporate collaboration should also be supported. |
| R-006 | The system federates across domains and permits independent server operation. |
| R-007 | The reference application targets serverless hosting on Cloudflare Workers; other operators can use Workers or comparable platforms. |
| R-008 | Publish source code and a well-documented specification suitable for independent operators and implementers. |
| R-009 | Support text rooms, voice rooms, combined rooms, and meetings. |
| R-010 | Room participants can share an entire display or an individual window, subject to permissions. |
| R-011 | Meetings support collaborative whiteboards. |
| R-012 | Default room interaction feels like persistent Discord rooms; meeting behaviour is configurable. |
| R-013 | Support direct messaging between users. |
| R-014 | Support direct voice calls between users. |
| R-015 | Direct messages and direct calls use client-side end-to-end encryption so transport and hosting servers cannot read their contents. |
| R-016 | Preserve automation through ordinary accounts on their own domains. A bot classification is not required for account actions; whether an optional classification is profile metadata or a distinct identity class remains OPEN under D-017. |
| R-017 | Detailed bot implementation may wait; preserve the ability to authorise administrative bots on the reference service. |
| R-018 | Provide a KDE Plasma client. |
| R-019 | Provide a GNOME client; the original GTK wording is refined by R-038/D-004, so a separate GTK implementation is not required. |
| R-020 | Provide a Windows client. |
| R-021 | Provide a macOS client. |
| R-022 | Global push-to-talk hotkeys are critical client functionality. |
| R-023 | Voice activation may be supported as an alternative to PTT where policy permits. |
| R-024 | Server and room policy can require PTT. |
| R-025 | Each listener can adjust individual users' playback volume locally. |
| R-026 | Each listener can mute individual users for themselves. |
| R-027 | Authorised room administrators can mute a participant for everyone. |
| R-028 | Authorised room administrators can adjust a participant's shared volume setting for everyone. |
| R-029 | Interfaces clearly distinguish personal listening changes from changes affecting everyone. |
| R-030 | Servers determine authorisation; the protocol supports ordinary and administrative actions and exposes effective rights to clients. |
| R-031 | Keep conversational voice delay low while permitting bounded receiver buffering for intelligible, continuous speech across distant regions (D-062). Ordinary video retains its latency priority. |
| R-032 | Screen streams and meeting presentations prioritise visual quality over latency; concurrent voice retains the bounded conversational-delay policy in R-031. |
| R-033 | Webcam functionality is secondary, restricted to meetings, and synchronised with the corresponding voice. |
| R-034 | Reference-server media policy and quality/latency settings are configurable by authorised admins through the client. |
| R-035 | Support a separate managed media service and a self-hosted media option. |
| R-036 | End-to-end encryption is mandatory for direct communication and configurable for shared rooms. |
| R-037 | Each room has one hosting domain; users from other domains join using their existing identity. |
| R-038 | Use one cross-platform interface with strong KDE and GNOME integration; separate Qt/GTK UIs are not required. |
| R-039 | Evaluate existing protocols first and select the foundation based on requirements fit. |
| R-040 | Prioritise a usable gaming milestone with federated rooms, PTT voice, text, E2EE DMs/calls, and screen sharing. |
| R-041 | Initial test version: one domain, 3–10 human testers in one voice room, with no screen-sharing requirement. The second test version adds a second domain promptly. |
| R-042 | Private rooms default to E2EE; public rooms default to server-readable content. |
| R-043 | Moderator shared volume establishes a baseline while listeners retain personal adjustment and mute; native-relay moderator mutes retain hard enforcement; private E2EE direct paths use D-086/SPEC-017 conforming-receiver enforcement, and managed presentations use D-167/SPEC-024 provider closure with explicitly unbounded control-partition completion. |
| R-044 | Initial tester platforms are KDE Plasma and Windows; macOS is for a future release. Exact OS/desktop versions remain unspecified. |
| R-045 | Linux sessions and app windows target Wayland only. D-053 permits an optional XWayland/XInput2 mouse-input helper; a full X11 client/session remains out of scope. |
| R-046 | A web client is highly desirable in the first version. This is a confirmed priority, not yet an unconditional release gate. |
| R-047 | Include basic room text chat alongside voice in the first test version. |
| R-048 | The web client supports PTT while focused and stops transmission on focus loss; desktop clients provide global PTT. This explicitly refines R-022 for the web client. |
| R-049 | Every specification includes a Configuration section describing relevant code configuration properties and their default values. |
| R-050 | Every specification includes a Testing section specifying unit-test coverage for the code it describes. |
| R-051 | Every specification includes an Acceptance criteria section with a bullet list of specific testable conditions for correct and complete implementation. |
| R-052 | Maintain separate specification documents for the clients and the server. |
| R-053 | Use fixed public/private access bundles: public rooms are listed and joinable by authenticated users permitted by federation policy; private rooms are unlisted and require an invitation. |
| R-054 | In V1, newcomers see room text from their admission onward, with no pre-admission history entitlement. |
| R-055 | Room creators may explicitly choose encryption at creation; public defaults to server-readable and private to E2EE. The chosen mode remains fixed for that room. |
| R-056 | Moderator “Mute for everyone” stops all audio from the participant, including screen-share audio, across their devices; video may continue. |
| R-057 | V1 uses an encrypted private room, PTT voice/moderation and plain-text messages with reconnect history, with one active device per account. Multi-device use, message editing/deletion, attachments and richer text follow later. |
| R-058 | V1 account creation uses administrator-issued invitations; testers choose their own passwords. |
| R-059 | V1 accepts unrecoverable encrypted history after loss of the only device or its content keys; specify content recovery for a later release. Login recovery does not supply old content keys. |
| R-060 | After re-admission, returning members may fetch retained messages from their earlier membership periods and the current period, excluding messages from their absences. |
| R-061 | License original project code, specifications, documentation and examples under Apache 2.0, retaining explicit existing file licences and third-party licences/notices. D-035; SPEC-000 owns the licensing policy. |
| R-062 | Permit independent clients, servers and other protocol implementations under any licence, including proprietary licences; protocol implementation alone does not require adopting the project's code licence. D-035; reuse of project material remains subject to its applicable licence. |
| R-063 | Sign in to the same account with the same credentials on KDE, Windows and web clients. Individually approving a new device from an existing device is acceptable for key privacy. D-044. |
| R-064 | Account permissions are the same across that account's approved clients and remain server-authoritative. D-044. |
| R-065 | Aim to make the same eligible conversation history readable on approved clients, with explicit limits where keys, retained messages or encrypted transfers are unavailable. This is the human's desired outcome, conditional on feasibility; it does not authorise indefinite retention. D-044. |
| R-066 | Provide a separate recovery key to restore access and available encrypted history after every approved device is lost. Detailed recovery mechanisms require review. D-045. |
| R-067 | Permit one active voice client per account and provide an explicit move to another client while other clients retain text/account access. D-046. |
| R-068 | Configure PTT by pressing the desired keyboard key on the configuration page; also support mouse buttons and joystick buttons. Desktop global PTT and the web focus boundary remain applicable. D-047. |
| R-070 | After server registration, an administrator can grant or revoke lobby access; permitted members click to join without a room invitation code. D-052. |
| R-071 | Normal sign-in is for existing accounts. Initial owner creation is available only at `/setup`, which closes after an owner is created. D-052. |
| R-072 | Invitation-key input accepts a raw key or a complete invitation URL for the connected server, including in KDE. D-052. |
| R-073 | The owner can create chat rooms and define the applicable details described by the specification; moderators manage rooms they can access. D-055/Q-47/Q-48 select text, voice and combined rooms for the next increment, with meetings deferred. |
| R-074 | User-facing account names use `username@domain`; omission of `@domain` selects the local account service's canonical identity domain. D-056. |
| R-075 | Use DNS for service discovery and specify federation discovery properties independently of the service hostname, supporting a full service URL with a path prefix. D-056; SPEC-010 defines the protocol under D-058 and records the current DNS deployment. |
| R-077 | Use a compact server/channel tree with voice participants as child rows; remove the separate member sidebar, combine personal and permitted moderator actions in the participant context menu, and present settings/management in the main workspace. D-065. |
| R-079 | Select a channel to view chat; activate that displayed chat again to join/move voice, without toggling an existing call off (D-067, SPEC-013). |
| R-080 | Group consecutive same-account messages, distinguish own text and add small timestamps for gaps strictly greater than two minutes (D-067). |
| R-081 | Persistent text conversation replies expand beneath the original message, retaining existing history/privacy boundaries (D-068, SPEC-013). |
| R-083 | Workspace Back controls are at the top-left, including user settings (D-070). |
| R-084 | Restore a right sidebar with personal saved contacts under Friends and recent people below (D-071). |
| R-085 | Connect to multiple servers through the server menu; join with a home account or log in/register locally, subject to host policy (D-072). |
| R-087 | Restore a subdued green PTT bar while transmitting, retaining explicit non-colour status (D-073). |
| R-088 | Allow authorized channel managers to rename a channel in settings without replacing its identity or history (D-074). |
| R-089 | Keep sender identities subdued and regular-weight in chat, with message contents slightly indented underneath (D-075). |
| R-086 | Resolve server shortcut links through a coordination service; support opening a link or pasting it into Join a server in the client, followed by one explicit Join action with the selected existing account (D-072). |
| R-082 | Each text conversation can have an isolated voice call, inheriting parent policy and the existing one-call/PTT movement rules (D-069, SPEC-013). |
| R-078 | Use softer application-defined light and dark palettes, selected by system appearance with live updates; forced-colour accessibility takes precedence. D-066 supersedes D-065 exact system-colour inheritance; SPEC-005 defines mode selection. |
| R-076 | Keep existing accounts at `@sloppyvoice.com`; the future independent server uses another identity domain. D-057. Endpoint/DNS changes must not rename existing accounts or reset IDs, credentials, keys, permissions or history. |
| R-069 | Validate keyboard/mouse/joystick PTT on KDE and Windows, using the current ProtoArc mouse button 4 as an immediate fixture; complete real joystick tests before leaving the testing phase. D-048. |
| R-090 | Attempt peer-to-peer delivery for encrypted voice wherever practical, with the public-channel exception in R-091. D-085 requests this successor behavior; D-086 resolves Q-56 and the scoped amendment to R-043. |
| R-091 | Continue routing public-channel voice through the relay, including public channels explicitly configured for E2EE. D-085; access and encryption remain independent under R-055. |
| R-092 | Send only one client upload of each voice frame to the relay for fan-out; assess and specify a reasonable mechanism for encrypted traffic. D-085; D-086 selects P-030/Q-57; SPEC-017 defines the signed sender-key mechanism. |
| R-093 | Add direct text messaging and one-to-one call entry points using the right-sidebar Friends and Recent lists. D-087; existing mandatory E2EE and local/cross-domain requirements remain. |
| R-094 | Add Server Members to the right sidebar so users can find people outside their usual contacts and start direct interaction. D-087; this expands R-077/R-084 with a server directory, not a duplicate selected-channel roster. Detailed visibility remains under review. |
| R-095 | Provide a convenient way to add people for ad hoc non-persistent channels. D-087; lifecycle, invitation and private-history boundaries are reviewed in SPEC-018. |
| R-096 | Retain temporary-group text after voice ends for a configurable duration, default four hours and maximum one year. D-088; SPEC-018 records proposed expiry/control details. Ordinary channel and one-to-one DM retention are unchanged. |
| R-097 | Require the recipient to accept first contact before ordinary direct messages or ringing; saved Friends, Recent encounters and shared-server membership do not bypass this requirement. D-089. |
| R-098 | Keep right-sidebar people actions compact: phone and message icons plus a red/grey Friends heart, with no Group or Channel buttons. Offer Add people from an established call. D-092; contact acceptance and explicit voice movement remain required. |
| R-099 | Show channel Public/Private access labels with rounded red/green borders respectively and softer fills. Preserve readable text and distinguish access from encryption. D-094. |
| R-100 | Hide saved friends from Recent while retaining them in Server Members; order each people row as username, action icons, then last-seen channel context. D-094; Recent history and account isolation remain unchanged. |
| R-101 | Raise the default and maximum continuous PTT limit to 600 seconds, configurable at server and channel scope, with a configured channel value overriding its server. Migrate existing 60-second channels to inheritance and preserve other limits. D-095, amended by D-222: upgrade existing shorter limits to 600 seconds once, preserving inheritance. |
| R-102 | Provide server-stored profile pictures, with upload, crop, preview and removal. Display pictures as circles at 56 CSS pixels at default UI scale in right-sidebar people rows. D-096; D-100 supersedes the original approximately 72-pixel display target. |
| R-103 | Provide audio cues for joins/departures in the active voice channel and subtle local PTT start/stop sounds, configurable through account-wide profile settings. Four enabled switches and a shared volume control; initial roster/reconnection remains silent. D-097. |
| R-104 | Show a persistent, accessible notice for an unexpected voice disconnect with channel, time, available reason and manual rejoin guidance; ordinary Leave remains quiet. D-098. |
| R-105 | Provide bounded exportable client voice diagnostics and structured server lifecycle/failure logs to investigate disconnects without recording content or credentials. D-099; SPEC-021. |
| R-106 | Provide device-local whole-interface scaling in user settings, from 75% to 200% with a 100% default, throughout the shared client. D-100. |
| R-107 | Use subtle status colours on the bottom voice connection strip and a distinct message-entry surface, retaining readable labels, system appearance and accessible boundaries. D-100. |
| R-108 | Make account login expiry configurable by its server, default 30 days, with unlimited sessions supported. Preserve existing expiry dates until the next successful sign-in/renewal. Provide a subtle warning in the final 24 hours, capped at the final 10% of shorter sessions, and early password reauthentication that preserves workspace and voice. D-102/D-103; use signed credentials and the bounded secure handover in SPEC-003/SPEC-009. |
| R-109 | Servers are roots in the left tree, with a visible Add server action and contextual server settings/channel creation; channels may contain channels to eight levels beneath a server, requiring parent access by default unless explicitly overridden for independent organization (D-104). |
| R-110 | Replace the top-bar Messages control with a bottom-left unread-summary icon beside the user; remove the top-bar Channel members control and show slowly blinking red unread indicators on the right-sidebar DM icons (D-104). |
| R-111 | Server/channel settings select mandatory or optional PTT, with channel inheritance/explicit override. A user's enabled PTT preference always wins; administrators cannot disable personal PTT. When both personal and effective channel requirements are off, use voice activation (D-105). |
| R-112 | Use the selected Quiet Stack: separate compact connection, microphone and identity bars beneath the channel tree, with connection context/diagnostics opening above them, explicit call controls and persistent unexpected-disconnect notification. Preserve input safety, active-call context independent of text navigation, unread messages, UI scaling and accessible responsive layouts (D-107/D-108). |
| R-113 | Allow multiple expanded server roots, with visibly contained channel branches; automatically size sidebars to their content within the available window, permit manual resizing of either sidebar, and suppress automatic growth after manual resizing. Remember each manual width on this device and offer reset to automatic. Preserve the conversation area on small windows. D-110. |
| R-114 | Copy public server/channel links from their menus; Add server joins and opens permitted text, retains denied server roots without inaccessible channels, and leaves voice unchanged. D-115. |
| R-115 | Quiet identity: one verified server root with its selected qualified account as the subdued subtitle and no separate account-selector row (D-120); server-menu sign-in with local account history, and a channel Join as dropdown. Preserve separate credentials, permissions and drafts, refresh visible channels for the chosen identity, and keep voice on its original account until explicit movement. D-126 makes a channel-dropdown change immediately join text and switch voice only when already connected to that exact server/channel. D-117/D-118/D-126. |
| R-116 | Invite an existing account to a specific channel with restricted server admission, without granting other channels. Uniform optional channel inheritance, explicit permits/denials, denial precedence and propagation controls apply at every depth. All new channels inherit by default; preserve existing access during migration. D-122–D-125, SPEC-022. |
| R-117 | Add screen sharing to ordinary channels and direct/ad hoc channels between users, with channel allow/deny and bitrate properties. Starting baseline is alpha.23. D-128, SPEC-023/024; reference native delivery is implemented, with managed integration and physical-platform acceptance reported separately. |
| R-118 | The host sets the normal maximum relayed presentation bitrate; a channel rate above it requires server-admin authority. Permit an exact-channel server-admin exception below the infrastructure safety ceiling. On eligible P2P paths, server/channel bitrate settings are defaults the presenter may exceed for their priorities; publication permissions still apply. Native relays independently police rates; D-167/SPEC-024 managed rates are cooperative targets unless provider policing is verified. D-128/D-129. |
| R-119 | Present a sharing popup offering all screens, one screen or one window, source selection where needed, productivity versus games/videos, quality versus speed, and a presenter bitrate limit with route-aware constraints. All screens produces one combined desktop view. D-128/D-130. |
| R-120 | Synchronize shared video with its optional application/system sound; align microphone speech best effort without pausing video solely for speech skew. Keep microphone voice responsive and independent. D-167/SPEC-024 supersedes microphone lockstep. PTT controls microphone voice only; optional presentation audio may continue between presses. D-128–D-130. |
| R-121 | By default, halve received game-sound volume while PTT is held or another participant speaks; make this behavior configurable in the receiver/listener's settings. This is local presentation-audio attenuation, not a change to the transmitted stream or everyone else's volume. D-130. |
| R-122 | Provide an installable Android client with calls continuing in the background from its first build, and instructions for installation and testing without a physical phone using an Android emulator. D-152; native input/security/lifecycle scope and validation are owned by SPEC-005. |
| R-123 | Provide an iOS client based on the Android design, built with Codemagic and installed for testing through TestFlight. Calls must continue while backgrounded or locked in the first build. D-163; SPEC-005 owns client responsibilities, configuration decisions and physical-device acceptance. |
| R-124 | Rewrite the Linux app as a native application in C/C++ or Rust using Qt, with the smallest practical processor and memory footprint and low disk requirements. Make it behave like a native desktop application; review proposed adjustments to earlier custom UI requirements before adopting their specific replacements. D-193; SPEC-005 owns the migration and presentation review. |
| R-125 | Use the selected tabbed native Linux layout without a toolbar/ribbon or right pane. Servers and Direct Messages are the roots of separate navigation trees; their context menus offer Add server and New conversation respectively. Always include pinned contacts in Direct Messages; order by last sent/received message newest first, then pin date newest first, then alphabetically. D-194; SPEC-005 owns presentation, while SPEC-014 retains address-book scope and the pin-chronology data dependency. |

D-044–D-048 are confirmed requests for the next feature work, not implemented capabilities. R-057/R-059 continue to describe shipped V1; R-063/R-066 replace their device/recovery restrictions only for the successor. Proposed mechanisms and migration gates are in the [linked-device review](reviews/2026-10-18-linked-devices.md) and [PTT input review](reviews/2026-10-18-ptt-input.md). The feature requests do not cancel the second-domain milestone.

## Proposed terminology

| Term | Meaning |
| --- | --- |
| Domain | An independently operated identity and service authority, such as `example.org` |
| Home domain | The domain responsible for a user's account and authentication |
| Community | A membership and administration boundary containing rooms; “workspace” can be a presentation label |
| Room | A persistent collaboration object with one hosting domain and an access policy |
| Room host | The domain authoritative for that room's membership, policy, and accepted events |
| Session | A live voice/video participation instance in a room or direct conversation |
| Meeting | A room/session profile with meeting controls and optional webcams |
| Direct conversation | A private conversation between explicitly addressed accounts; one-to-one is required, group DMs remain open |
| Device | An independently authenticated client installation with its own encryption identity |
| Media service | The relay/SFU and connectivity services that carry real-time streams |

“Server” in administrative controls must identify whether it means an operator's domain or a community. Proposed default: one domain can host several communities, with domain policy constraining each community and room.

## Proposed room model

Represent room capabilities separately from presentation presets. A room advertises whether it allows text, microphone audio, screen/window sharing, whiteboards, and webcams. Meeting configuration does not create a separate identity or permission system.

| Preset | Default behaviour |
| --- | --- |
| Text | Persistent messages; no microphone session until explicitly enabled |
| Voice | Join/leave a persistent audio space; associated text is an optional room capability |
| Combined | Persistent text with an independently joined voice session |
| Meeting | Explicit join flow, participant roles, screen sharing, whiteboard, and optional webcams |

Screen sharing is available in ordinary rooms when enabled; it is not tied to enabling webcams or meeting presentation. Audio, screen audio, and camera publishing are separately authorised. A voice-only room may remain voice-only if its host disables other capabilities.

Proposed defaults: creating a general room uses the combined preset; reading text does not start microphone capture; joining voice does not publish a camera or screen; leaving a live session does not remove persistent room membership. Membership, live attendance, and permission to read history are separate concepts.

SPEC-022/D-125 supersedes the access calculation below: both public and private channels use explicit/inherited permits and denials, and an inherited permit satisfies private admission. Labels retain their routing/share-link/encryption-default meanings.

CONFIRMED D-015: the public/private access type is separate from the media preset. Access is a fixed bundle, not independently configurable discovery, join and history switches:

| Access type | Discovery and admission | V1 text history |
| --- | --- | --- |
| Public | Listed; authenticated users permitted by federation policy may join | From the member's admission onward |
| Private | Unlisted; a valid invitation is required | From the member's admission onward |

An invitation does not bypass federation restrictions, a ban or capacity. Listing a public room does not grant anonymous reading or membership. Directory audience and invitation issuance, recipient binding, expiry and revocation need an approved protocol contract. Encryption defaults and the fixed creation-time choice are owned by SPEC-003. Access-type conversion is not specified; proposed V1 behaviour rejects conversion and independent changes to the access bundle. A later conversion contract must preserve the room's fixed encryption mode and define membership/history effects.

The host commits admission/removal positions in its ordered room stream; these positions determine history eligibility, not the user's clock. CONFIRMED D-023: returning members may fetch retained messages from earlier membership periods as well as the new period, excluding the absence. This refines the table's first-admission rule. Detailed interval retrieval and encryption-key limitations belong to SPEC-006. Persistent membership, live attendance, device trust and encryption-group transitions follow SPEC-003. Text navigation and the active voice-session target are independent client state under SPEC-005.

Persistent room existence does not require a permanent media session or an idle media charge. Empty rooms can retain history and settings without a running conference.

Meeting candidates for review: host/presenter/attendee roles, lobby, raise hand, participant list, scheduled start/end metadata, presenter handoff, and persistent meeting text. Webcam publication is disabled outside the meeting profile. Cameras remain off until the participant enables one.

## Proposed messaging baseline

Persistent messages, replies, edit/delete semantics, unread state, mentions, attachments, basic formatting, and reconnect history are proposed for the usable product. Threads, reactions, pins, bookmarks, server-side search of unencrypted rooms, and client-side search of encrypted content are candidates requiring scope decisions.

CONFIRMED D-020 narrows V1 to sending/receiving plain-text room messages and reconnect history. “Plain-text” describes formatting; the private test room's content is still end-to-end encrypted. Message editing/deletion, attachments and richer text follow later; their eventual feature scope remains subject to the corresponding specifications. Unread state, replies, mentions, receipts and typing indicators are not implied by the phrase “basic text.” Reconnect/history recovery is required; composing an offline send queue remains a separate proposal.

Receipts distinguish accepted by a server, delivered to a device, decrypted, and read. Read receipts and typing indicators need privacy policy decisions. A green connection indicator must not imply that a remote recipient received a message.

One-to-one direct messages and voice calls are required across domains as well as locally. D-087 selects ad hoc temporary groups with text and call entry points; D-088 retains their text under a configurable four-hour default/one-year ceiling. SPEC-018 owns this successor. Direct screen sharing is now requested under D-128–D-130 and reviewed in SPEC-023; it remains unimplemented. Persistent group DMs, call transfer, voicemail and direct-call webcams remain open; direct webcams would require an explicit interpretation of the meetings-only requirement.

## Scope that remains open

Mobile clients, federation-wide room directories, invitations for anonymous guests, multiple simultaneous voice rooms, whisper/command channels, overlays, game audio ducking, spatial audio, streaming audio capture, recording, transcription, calendar integrations, bridges, SSO, legal hold, and external compliance features have not been approved or rejected. Public-room listing is required by R-053, but its directory audience and distribution remain open. A web client is a first-version priority under R-046; desktop-global PTT and the browser capability boundary require distinct acceptance criteria.

These candidates must not displace the confirmed PTT, federation, encryption, platform, and media requirements. Delivery order is separate from inclusion in the complete project.

## V1 invitation workflow amendment (D-052)

R-070 refines the private-room admission bundle for the single V1 lobby: a direct administrative access grant to a registered account is an invitation to join. It does not list the room publicly, make server registration grant membership, or expose history before admission. Legacy room invitation keys remain compatible under SPEC-009. This replaces the requirement to exchange a separate room code for each invited server member.

R-114 — CONFIRMED: Copy public server/channel links from their menus; paste into Add server to join/open permitted text. Retain denied servers without inaccessible channels. Voice joins separately (D-115, SPEC-015).

## Configuration

D-055/Q-47/Q-48 confirm owner-only creation and text/voice/combined release presets beyond the singleton V1 fixture, with meetings deferred. D-058 selects the reviewed P-027 creation schema below. It supersedes the older draft default/override inventory for this increment; SPEC-012 defines its migration and wire formats.

| Creation property | Type, default, validation and effect | Ownership and persistence |
| --- | --- | --- |
| `name` | Required string, no default; trim surrounding whitespace; 1–80 Unicode code points; reject controls. Duplicate display names allowed; identity is the stable room ID. | Owner supplies at creation; stored with the room. |
| `description` | Optional plain-text string; omitted becomes empty; maximum 500 Unicode code points; null/nonstring invalid. | Owner supplies at creation; visible only with authorised room metadata. |
| `preset` | Required `text`, `voice` or `combined`; no API default; UI starts unselected. `meeting` and unknown values rejected. | Owner supplies at creation; persisted. |
| `access` | Required `public` or `private`; no implicit default. Fixed D-015 bundle; no independent discovery/history overrides or in-place conversion in this increment. | Owner supplies at creation; persisted. |
| Text/voice capabilities | Fixed derivation from preset: text only, voice only, or both. Not independent configuration switches. | Derived/advertised by server; unsupported operations rejected. |

All supplied creation fields are validated before a single transactional commit. No partial room/grants survive failure; repeated accepted creation returns the original room. IDs, revisions, grants and owner admission are state. Initial access targets and creation authority belong to SPEC-008; the per-room limit and migration belong to SPEC-006. Encryption is immutable and access-defaulted under SPEC-003; voice settings belong to SPEC-004. Unsupported screen/camera/board/meeting controls are absent. Later editing of name/description or preset conversion needs a separate contract.

The following logical property names are PROPOSED; no code/configuration schema exists yet. Accepted default behaviour is identified independently of the proposed name. Detailed validation and external names must be resolved before implementation.

| Property | Scope and type | Default and status | Behaviour |
| --- | --- | --- | --- |
| `room.creation_preset` | Community; enum `text`, `voice`, `combined`, `meeting` | `combined` — PROPOSED | Initial presentation/capability preset for a general room. |
| `room.access_type` | Room creator; enum `public`, `private` | Required — no implicit type, PROPOSED; V1 fixture explicitly uses private under D-020 | Selects the confirmed fixed access bundle. Replaces draft `room.visibility`; independent discovery/join/history overrides are not V1 settings. |
| `room.capabilities.text` | Room; boolean | Preset-derived — PROPOSED: true for text/combined/meeting; false for voice | Enables persistent room text; can be enabled for a voice room. |
| `room.capabilities.voice` | Room; boolean | Preset-derived — PROPOSED: false for text; true for voice/combined/meeting | Enables a separately joined voice session. |
| `room.capabilities.screen` | Room; boolean | OPEN — not selected | Enables screen/window publishing subject to permission; not required in the first test version. |
| `room.capabilities.whiteboard` | Room; boolean | OPEN — not selected | Enables collaborative boards; required meeting capability does not imply every board starts automatically. |
| `room.capabilities.camera` | Room; boolean | False outside meetings — CONFIRMED restriction; meeting default OPEN | Permits participant-initiated webcam publishing only in meeting mode. |
| `meeting.lobby_enabled` | Meeting; boolean | OPEN — not selected | Determines whether admission requires a lobby; feature still proposed. |
| `meeting.scheduled_start`, `meeting.scheduled_end` | Meeting; optional timestamps | Unset — PROPOSED | Allows ad hoc meetings; scheduled meeting scope and time validation remain open. |

Encryption properties/defaults are owned by [SPEC-003 Configuration](003-identity-security.md#configuration); media policy by [SPEC-004](004-media.md#configuration); client preferences by [SPEC-005](005-clients.md#configuration); server roles/administration by [SPEC-008](008-server.md#configuration); messaging/retention by [SPEC-006](006-operations-data.md#configuration). Joining, reading, and starting capture are actions, not interchangeable configuration switches. No preset may bypass explicit capture consent or enable webcams outside meetings.

## Testing

Unit tests for room/preset and conversation-state code should cover:

- For D-055, rejecting an omitted preset/access and applying the selected preset's fixed capabilities; rejecting unsupported overrides, meeting/unknown presets and invalid field types. Future profiles may use a default only after approval.
- Valid capability overrides and rejection of combinations that would enable webcams outside meetings; disabled capabilities must not dispatch publish/create actions.
- Independent room membership, text viewing, and live-session state: reading text does not start capture; joining voice does not start screen/camera publication; leaving voice preserves room membership.
- Public/private bundle validation, required access type, invitation and federation checks, rejection of unsupported conversion/independent overrides, and committed admission boundaries independent of sender timestamps.
- One-to-one conversation routing distinguishes local and foreign account identities; identical local names on different domains do not select the same recipient.
- Message status transitions do not confuse local pending state, host acceptance, delivery, decryption, and read state.
- Meeting entry/exit and capability changes preserve room identity and invalidate operations no longer permitted.

Use fake capture and routing adapters for these units. Real multi-client interaction and media capture belong to acceptance/integration testing, not these mocks.

## Acceptance criteria

- R-123: the SPEC-005 iOS acceptance checks pass on the recorded physical-device matrix; account setup, successful signing or simulator launch alone does not establish background-call acceptance.

- R-113: A-46 verifies independent server expansion, visible hierarchy and device-local responsive sidebar sizing.

- R-112: A-45 verifies the compact bottom-left controls and preserved voice behavior.

- D-104/D-105: A-43 and A-44 demonstrate server-root navigation, eight nested channel levels with default parent access, unread messaging controls, and personal/server/channel PTT precedence with optional voice activation.

- A-39 passes for owner-created text, voice and combined rooms with the reviewed fields/defaults after their approval, immutable encryption and code-free access grants; legacy lobby identity/history are preserved and unsupported meeting controls remain absent.
- R-074–R-076 are covered by A-40 without renaming existing `@sloppyvoice.com` accounts; SPEC-010 distinguishes implemented HTTPS discovery and published DNS hints from the unimplemented federation protocol.

- Source and specification licensing identify Apache-2.0 and the independent-implementation policy under R-061/R-062, with explicit file exceptions and third-party notices preserved. Publication and operational validation remain separate requirements under A-19.
- Create each supported room preset and verify that enabled capabilities can be used while disabled ones cannot; a rejected request cannot bypass the UI through the protocol. See A-04.
- Create each supported access type: public listing does not expose history to nonmembers; private rooms are absent from unauthorised discovery and reject uninvited admission. A new member receives only eligible post-admission text. See A-27.
- In V1, exchange unformatted text inside the encrypted private test room, reconnect to eligible history, and enforce the one-active-device limit; unsupported editing/deletion, attachment and rich-text operations are unavailable. See A-23/A-32.
- Open text, join voice, and leave voice while observing capture state: neither text navigation nor voice join starts a screen/camera, and leaving voice preserves persistent membership/history access according to policy.
- Complete one-to-one messaging and voice calls both within a domain and across two domains without creating a second user login; verify direct-content encryption under A-05.
- With three participants, verify the local/shared mute and volume distinctions and permissions under A-09/A-10.
- On the declared release platform matrix, complete the supported desktop/browser workflows under A-20/A-23/A-24; required future platforms are tracked as incomplete until demonstrated.
- Demonstrate screen/window sharing, collaborative meeting whiteboards, and meeting-only webcams under A-12/A-13/A-14 before claiming complete product implementation; early test builds may explicitly omit later-stage features.
- Inspect every numbered specification and verify its three required sections and testable acceptance bullets under A-25.