# Questions for specification review

Revision: 0.3. Date: 2026-10-18. Answered questions retain IDs so later references remain valid. The next review can address one group at a time; unresolved choices do not require speculative code.

## Screen sharing from alpha.23 (D-128–D-134)

- **Q-62 — Bitrate authority, selected D-129/D-132–D-134.** A server admin may grant an exact-channel relay exception within the infrastructure ceiling. P2P rates are advisory defaults, not permission bypasses. D-132/D-133 confirm an 8 Mbps normal server relay limit, a 4 Mbps initial client presentation limit with adaptation and audio/overhead headroom, and enabled sharing inherited by channels. D-134 selects the infrastructure/aggregate, presenter/source and scope defaults in SPEC-023. Byte accounting and local enforcement are implemented; deployment load/capacity validation remains outstanding.
- **Q-63 — Audio scope and synchronization priority, selected D-129/D-134.** Microphone plus optional application/system sound; preserve the 200 ms voice residence cap and reduce/pause video when needed. D-134 selects the reviewed 80 ms p95 / 150 ms moving-frame targets and delegates the documented clock/queue profile. Physical and impaired-network validation remain outstanding.
- **Q-64 — Screen-media implementation profile, direction selected by D-131.** SPEC-023 compares five approaches, including two unconventional modes; the human selects encoded video alongside the existing voice transport. The [bounded local test](reviews/2026-10-22-screen-media-prototype.md) exercises encoding, encrypted fragmented data-channel delivery, drawing and the existing Opus worklet. It does not select the final wire/codec profile or establish real platform capture, native relay capacity or cross-device synchronization. D-134 delegates the final technical profile, now recorded in SPEC-023 and integrated locally; physical capture/audio, impaired networks and deployment capacity remain separate validation gates.
- **Q-65 — All-screen view, answered D-130.** The human selects one combined desktop view. Do not substitute separate viewer-selected screens. Capture adapter support, mixed-DPI geometry and composite resource bounds still require technical completion.
- **Q-66 — PTT and presentation sound, answered D-130.** PTT gates only microphone voice; optional game/application sound continues between presses. The human also requires listener-configurable half-volume game sound while PTT is held or another user speaks. D-134 selects SPEC-023 local/remote trigger details, ramps and preference scope; moderator mute still silences all audio roles.

## Direct conversations and temporary groups (D-087)

- **Q-58 — Temporary group text, answered by D-088.** Temporary voice ends, but group text remains in configurable history, default four hours and maximum one year. This rejects the initial erase-on-close/no-history-copy recommendation. D-090 approves choosing the duration at creation, measuring each message from host acceptance, and preserving its original expiry in device/recovery copies; SPEC-018 owns the selected writer and timing details.
- **Q-59 — First-contact policy, answered by D-089.** Require acceptance of a first-contact request before ordinary messaging or ringing. The human explicitly answered “Yes” on 2026-10-20. Friends remain one-way saved contacts under D-071; saving a contact or sharing a server does not bypass acceptance. Immediate contact by shared-server members or arbitrary known addresses was not selected. D-090 subsequently approves the reviewed lifecycle, cooldowns and blocking in SPEC-018.

D-087 selects temporary group communication from Q-32's previously open group scope. Persistent group DMs, attachments, read receipts, typing, voicemail, direct video and screen sharing are not implied. The new Server Members directory and scoped conversation hosting are approved under D-090 in SPEC-005/008/018; the existing administrative account endpoint is not a general people directory.

## Answered or partly answered

| ID | Question | Answer |
| --- | --- | --- |
| Q-01 | Can serverless application hosting use separate media infrastructure? | Yes, both managed and self-hosted; D-001. |
| Q-02 | Which communication requires E2EE? | All direct communication; configurable rooms; D-002. |
| Q-03 | Does federation replicate room authority or allow remote identities into one hosted room? | One hosting domain; D-003. |
| Q-04 | Separate KDE and GNOME UIs or one interface? | One cross-platform interface with strong desktop integration; D-004. |
| Q-05 | Existing federation protocol or new protocol? | Evaluate existing protocols first; selection still open; D-005. |
| Q-06 | Which capabilities come first? | Gaming milestone, preceded by one-domain then two-domain voice tests; D-006/D-007. |
| Q-07 | Does moderator gain replace local volume? | Shared baseline plus personal controls; relay-enforced hard mute; D-009. |
| Q-08 | What are room encryption defaults? | Private encrypted, public server-readable; D-008. |
| Q-10 | What scale is needed? | Initial human tests: 3–10 people in one room, one then two domains. Production scale is still open. |

## Historical first-version questions

D-024 delegates the remaining V1 choices. D-025–D-031, SPEC-009 and the owning revision 0.4 V1 sections resolve Q-05/Q-09/Q-11/Q-12/Q-13/Q-15/Q-21/Q-22/Q-33/Q-38/Q-39/Q-40 to their stated V1 extent. The original questions below are retained as review history; their OPEN wording does not override those explicit V1 resolutions. Production scale, broader feature scope, later platforms and restore remain open for their affected milestones. D-035 subsequently selects source/specification licensing; Q-30 retains the unresolved extension/revision governance questions.

## Initial first-version questions

- **Q-13 — Tester platforms, partly answered.** KDE Wayland and Windows initially; Wayland-only Linux; macOS later; web client highly desirable initially. D-010. Exact OS/desktop versions and CPU architectures remain open. GNOME timing and browser support matrix also need decisions.
- **Q-14 — First-version content, answered.** D-020 selects an encrypted private room, PTT voice/moderation, unformatted text with reconnect history and one active device per account. Multi-device use, edits/deletion, attachments and richer text follow later. Exact protocols, limits and supported roles still need specification.
- **Q-35 — Web PTT, answered.** Focus-only PTT with transmission stopped on focus loss; use desktop for global PTT. D-012. Browser/version support and detailed lifecycle tests still need specification.
- **Q-15 — Account setup, partly answered.** D-021 selects administrator-issued account invitations and tester-chosen passwords for V1. Invitation purpose/recipient binding, expiry, password-verifier profile, rate limits, MFA policy, reset and initial-admin bootstrap remain open. Do not ask again whether V1 uses open registration or passkeys.
- **Q-11 — Device trust.** What protection is required against a malicious home server substituting encryption keys? Recommended: authenticated device identities, explicit new-device approval/key-change warnings, and an out-of-band verification path; decide whether first-contact trust without verification is acceptable.
- **Q-16 — Lost devices and recovery, answered for V1; successor selected by D-045.** A separate recovery key is now required for the requested successor; Q-43 tracks the mechanism. Historical V1 answer: D-022 accepts unrecoverable old history after the only device/keys are lost. Define a later recovery mechanism separately; administrator login recovery cannot restore plaintext access. Explicit device replacement and first-contact trust still require a V1 contract.
- **Q-09 — Foreign room connections.** Should clients connect directly to a foreign room host after home-domain authentication, or should their home domain proxy room traffic? Direct connections reduce forwarding work; proxies change metadata exposure, outage behaviour, and cost. Protocol selection may constrain this.
- **Q-12 — Media route privacy.** Permit peer-to-peer direct calls, with possible peer IP exposure, or relay all media? Recommended starting point: relay by default; decide whether optional peer-to-peer belongs in scope.
- **Q-21 — PTT details, extended by D-047/D-048.** Press-to-bind keyboard, mouse and joystick input is now required; ProtoArc button 4 is the immediate fixture on KDE/Windows, with joystick tests required before leaving testing. Q-45 owns the remaining input mechanisms. Historical scope question: Required keys/buttons; hold versus toggle; press/release cues; maximum transmit duration; accessibility exemptions; supported full-screen modes; listen-only fallback; treatment of bot audio. Recommended baseline: hold-to-talk, configurable keyboard binding, no silent voice-activation fallback.

## Product and data choices

- **Q-47 — Room-creation release presets, answered.** The human approved the reviewed text-only, voice-only and combined scope on 2026-10-19; meetings remain deferred under Q-25/Q-26. D-055/P-027; see the [room review](reviews/2026-10-19-room-creation.md).
- **Q-48 — Room creation rights, answered.** The human selected owner-only creation on 2026-10-19. Moderators retain existing management powers only in rooms they can access; ordinary members cannot create rooms. This resolves Q-17's creation-authority question for the D-055 increment.
- **Q-49 — Second instance identity domain, answered by D-109.** Deploy alpha.16 with identity `shittyshittybangbang.com` and service base `https://shittyshittybangbang.com/` in the existing Cloudflare account. D-057 preserves existing `@sloppyvoice.com` identities and their storage. `alpha.sloppyvoice.com` remains only an illustration.
- **Q-50 — Discovery profile review, answered by D-058.** SPEC-010 selects URI/SRV hints, identity-origin HTTPS verification, conservative address normalization and path-aware instance routing. Federation remains closed; the next independent domain remains Q-49.

- **Q-17 — Membership and discovery, partly answered.** D-015 fixes public rooms as listed/joinable by authenticated users permitted by federation policy, and private rooms as unlisted/invitation-only. These are fixed access bundles. Q-48 resolves room creation as owner-only for D-055. Directory audience, broader invitation controls, community creation rights and anonymous guests remain open; anonymous reading is not implied by listing.
- **Q-18 — History and retention, partly answered.** D-016 starts first-time V1 history at admission. D-023 permits returning members to fetch earlier membership periods plus the new period, excluding absences; keys and retention still constrain readability. Retention durations, access during an absence, later edit/redaction rules and recovery remain to be detailed. D-018 fixes a room's encryption mode; only a separate room can have a different mode, with migration UX/history still proposed.
- **Q-19 — Community hierarchy, partially resolved by D-104.** Eight levels of nested channels beneath each server are selected, with parent access required unless explicitly overridden. Separate communities/workspaces and their role boundaries remain open.
- **Q-20 — Simultaneous voice.** One active transmitting room, multiple listening rooms, or multiple transmitting rooms? Need TeamSpeak/Ventrilo-style whispers, command channels, priorities, or emergency broadcasts? These affect routing, PTT bindings, and privacy.
- **Q-32 — Text and direct conversations.** Are group DMs, threads, reactions, pins, mentions, markdown/code blocks, attachments, read receipts, typing indicators, and search required for the gaming milestone? Which can wait? What are edit/delete and unsolicited-message rules?
- **Q-33 — Moderation boundaries.** Who can remove, ban, move, or silence whom? Do users have a global personal block list? Should a domain block affect existing room sessions immediately? What is disclosed in a report from an encrypted room?

## Media and meetings

- **Q-22 — Performance.** Accept or revise the candidate latency/sync targets in SPEC-007. How much extra voice delay is acceptable for webcam lip sync? What should happen when that bound cannot be met? Define a hard revocation bound as well as a percentile target.
- **Q-23 — Media policy and budget, partly answered.** D-039 selects a US$5 account usage alert, not a spending cap. D-040 preferred Canada → EU → US where supported; D-216 supersedes that order with latency-led placement and permits North American (`us`) hosting. D-041 identifies Brisbane for Australian tests, and D-042 requires an eventual service that accommodates geographic disparity while permitting one relay path for initial testing. Production bandwidth/CPU limits, enforceable usage budgets, and the remaining tester network fixtures are OPEN.
- **Q-24 — Screen sharing, selected D-128–D-134; delivery validation ongoing.** SPEC-023 defines channels/direct calls, combined desktop capture, intent controls, route-specific budgets, optional sound and listener ducking. D-134 selects presenter/source limits and delegates the codec/clock profile. Exact platform capture/audio support, HDR, physical quality and capacity are validation questions, not unanswered configuration approvals.
- **Q-25 — Meeting behaviour.** Scheduled versus ad hoc meetings; lobby; host/presenter roles; raise hand; external guests; camera count; breakout rooms; calendar integration? Confirm that any future direct camera call must explicitly enter meeting mode.
- **Q-26 — Whiteboard scope.** Freehand, text, shapes, images, multiple pages, export, persistence, late joiners, and offline editing? Should participants be able to modify each other's objects?
- **Q-27 — Recording and transcription.** Are either required? Who controls them, what must participants see, and where are results stored? An E2EE recording/transcription bot would be a disclosed endpoint with content access.

## Protocol, deployment and project policy

- **Q-28 — Corporate scope.** Is ordinary collaboration sufficient initially, or are SSO, provisioning, domain-only federation, retention administration, regional controls, and e-discovery necessary? Which are compatible with non-optional E2EE direct communication?
- **Q-29 — Bot operations, partly answered.** D-017 preserves ordinary-account automation while leaving optional bot classification open; neither profile metadata nor a distinct identity class is selected. Need noninteractive provisioning, scoped credentials, SDKs, webhooks, or only a documented ordinary account API first? How should audio-publishing service accounts interact with PTT policy, and in which stage is its credential flow delivered?
- **Q-30 — Licensing and governance, partly answered.** D-035 selects Apache 2.0 for original source, specifications, documentation and examples, retaining explicit file exceptions and third-party licences. Independent protocol implementations may use any licence, including proprietary licences. Standard Apache contribution and patent terms apply; no separate protocol-wide patent commitment is selected. Governance of compatible third-party extensions and protocol revisions remains OPEN.
- **Q-31 — Alternative hosting.** Which second serverless platform or self-hosted control deployment matters first? Must every component be independently runnable without a commercial service? When must both managed and self-hosted media be demonstrated?
- **Q-34 — Name and release support.** Project name, initial UI language, minimum platform versions, package formats, update policy, and whether mobile clients are future requirements? Browser support is already a first-version priority under D-010.

Protocol evaluation should produce a concrete recommendation with transport, hosting, encryption, and permission implications. No need to choose a technology from its name alone.

## Review follow-ups

- **Q-36 — Room encryption choice, answered.** D-018 permits an explicit creation-time choice with the accepted public/private defaults; the selected mode stays fixed. No in-place mode migration is in scope.
- **Q-37 — Moderator mute scope, answered.** D-019 stops every audio role across the target's devices; video may continue. Active-path revocation states and a hard bound remain technical prerequisites under Q-22.
- **Q-38 — Foreign-user policy jurisdiction.** The room host owns room authority. Should an account's home domain be able to assert additional restrictions on its users in foreign rooms, or is that outside the initial protocol? If supported, define authenticated assertions, restrictive combination, renewal and outage behaviour; foreign roles still cannot grant host privileges.
- **Q-39 — Device and membership lifecycle.** V1 allows one active device. Define what makes it active, second-device rejection, explicit logout/replacement, attendance expiry, trusted key changes, epoch coordination and lost-device re-admission. These mechanisms must implement D-020/D-022 without resurrecting old authority.
- **Q-40 — Restore and command validity.** Select a storage/queue protocol supporting recoverable state plus external work, command validity/uniqueness and timeout reconciliation. Before restore support, select rollback-resistant authority fencing, a revocation source and recovery objectives. These are design recommendations to prepare after protocol/provider evaluation, not product options requiring arbitrary guesses now.

- **Q-41 — Regional media routing.** D-042 confirms the need for geographic flexibility. Specify relay-selection signals, precedence between operator location preferences and latency, room/session placement, participant arrival/departure, handover, capacity and failure behavior. Preserve one authoritative room policy and bounded forwarding leases across every route. The initial one-relay test does not select automatic migration or cross-region forwarding.

## Linked devices and configurable input follow-ups

- **Q-42 — Device trust and history crypto, selected by SPEC-011 under D-059.** D-044 permits approval by an existing device. Specify authenticated linking/roster evidence, challenge/replay protections, key changes and revocation ordering; select the successor message envelope and legacy-transfer provenance. Recommendation P-024 uses separate device keys without cloning vaults. Preserve declared TOFU/browser-origin limits until stronger protection is established.
- **Q-43 — Recovery details, answered by D-060 and completed in SPEC-011.** Both password and recovery key are required; forgotten-password reset is excluded. SPEC-011 selects the signed recovery transition, explicit saved-key confirmation, original retention, bounded per-message copies and post-recovery fresh-key setup. Rotation of a still-active key remains future scope.
- **Q-44 — Successor migration and limits, selected by SPEC-011/012 under D-058/D-059.** Define version/capability negotiation, migration of existing owner/accounts/devices/history and explicit legacy-client refusal. Resolve device cap, envelope growth, account-wide rates, transfer limits and handover state machine/timeout. D-046 already selects one active voice client with explicit movement; do not ask that policy question again. The selected contracts define the implementation bounds and preserve the original root identity.
- **Q-45 — PTT adapter and binding schema, implemented profile; physical acceptance pending.** SPEC-005’s D-049 input profile and the alpha.2 implementation resolve schema, timings and the initial Linux/Windows/browser adapters. Read-only permission for the selected Linux mouse and real hardware support remain to validate. The following original prerequisites are retained as review context: D-047 already selects keyboard, mouse and joystick button capture in configuration. Resolve KDE Wayland global mouse/joystick integration and permissions, Windows/controller backend, canonical key/button identifiers, device identification on reconnect, reserved controls, recording timeout and polling/watchdog bounds. D-048 supplies ProtoArc button 4 and both desktop targets; the joystick model is pending, but real joystick validation is mandatory before leaving testing. Keep focus-only web capability explicit; missing platform support is a gap, not permission to drop a required input class.


The historical V1 review order above is resolved to the scope recorded under D-024–D-031. D-034's hosted UDP/TLS transport candidate passed. D-043 selects the bounded production lifecycle; its implementation validation and activation are now tracked in the alpha policy review. Q-41 and the broader meeting/operation questions remain tracked for their affected milestones.

- **Q-46 — XWayland mouse compatibility exception, answered D-053.** The installed Discord uses an XInput2 path with KDE’s existing side-button forwarding policy. The human explicitly permits introducing the X11 dependency. Implement the optional helper while retaining the native Wayland window; SPEC-005 defines its selected scope. P-026 and the [diagnostic review](reviews/2026-10-19-linux-mouse-input.md) describe the scope. No permissions or desktop policy have been changed.

## Key lifetime follow-ups (D-081/D-082)

- **Q-54 — Voice lifetime, answered by D-082.** Five minutes maximum, new keys on membership changes, at most two seconds of receive overlap, and pause on failed renewal. No repeated duration question is needed. SPEC-016 records the engineering profile.
- **Q-55 — Text ratchet and archive integration.** Evaluate MLS/OpenMLS first under the [protocol review](reviews/2026-10-20-key-lifetimes.md). Preserve current history and recovery; choose the implementation, atomic state persistence, archive protection and migration before changing text encryption. Expiry of retained history or recovery codes has not been selected.

## Peer-to-peer voice follow-ups (D-085)

- **Q-56 — Direct-path privacy and moderation, answered by D-086.** Accept peer network-address exposure and conforming-receiver enforcement for private encrypted P2P paths, with a relay-only preference? The [review](reviews/2026-10-20-peer-voice.md) proposes this scope. D-009/R-043 currently require relay-enforced hard mute; a server cannot independently terminate a direct connection between two modified clients. Public calls and fallback paths retain relay enforcement. D-086 accepts the reviewed exception; SPEC-017 defines its scope.
- **Q-57 — One-copy encrypted fan-out, answered by D-086.** Select the proposed temporary per-speaker key, distributed through current ephemeral pairwise channels, with per-frame sender signatures? The [review](reviews/2026-10-20-peer-voice.md) preserves D-082 deadlines and describes the remaining wire/transition prerequisites. D-086 explicitly selects this profile; SPEC-017 completes its wire and transition rules.

## Multiple-server follow-ups (D-072)

- **Q-50 — Initial visitor scope, answered by D-076.** Include foreign E2EE channels in the first multi-server release; do not ship a server-readable-only visitor scope as completion. Existing local E2EE remains.
- **Q-51 — Public local registration, answered by D-076.** Public visitors and local registration have independent controls. Local registration stays invitation-only unless the owner explicitly enables public registration.
- **Q-52 — Closing public admission, answered by D-077.** Existing visitor memberships remain; disable only new public joins. Remove or ban existing visitors separately.
- **Q-53 — Foreign home outage, answered by D-078.** Pause affected E2EE posting until device approval can be verified again; preserve readable history. Server-readable posting by other members remains available.

The human selected personal saved contacts, account-wide Friends, client-local Recent, one explicit Join confirmation with the existing account, and pasted join links inside the client. Those choices are resolved; do not ask them again. SPEC-015 records the architecture under review and technical wire/revocation prerequisites.

## Tree and optional PTT follow-ups (D-104/D-105)

- **Q-60 — Nested channel access, answered D-104.** Require parent access by default; explicit channel permission override permits independent organizational nesting. Eight channel levels beneath a server is already delegated and selected.
- **Q-61 — Non-PTT microphone behavior, answered D-105.** The human selects voice activation. Defaults preserve mandatory server PTT and enabled personal PTT, with new channels inheriting. Personal PTT always takes precedence under D-105; a channel's explicit setting overrides the server requirement.

## Mobile adaptation of selected B (2026-11-06)

- **Mobile call context — answered D-219:** the human selects retaining ⋮ navigation and showing the actual connected call destination and account in the persistent bottom bar. Keep it distinct from the viewed account.
- **Mobile enabled statistics — answered D-219:** the human selects continuously visible enabled statistics beneath main content, independently of ⋮. The existing protected preference and false default remain unchanged.