Sloppy Voice DevelopersSloppy Voice ↗

Server

Document: SPEC-008. Revision: 0.33. Date: 2026-11-07. Lifecycle: Partially approved under delegated decision D-024; V1 resolution sections are active, later scope remains Draft. Supersedes: server-authorisation and administrative-processing sections formerly contained in SPEC-005 revision 0.1; client responsibilities remain in SPEC-005. D-172–D-180 scope is accepted only as specified below; SPEC-013 records the approved one-message history exception.

Developer API and logical servers (D-227/D-228)

Implement SPEC-028 using existing instance authentication and independent logical ownership/membership. Logical channel state must never appear in the deployment server’s normal room listing. Reuse the shared permission resolver and message-validation/storage implementation. Default history/sync filters non-visible messages after bounded eligibility pagination; explicit API retrieval preserves original membership intervals and encryption. Prevent pins/thread references to controls. Schema 10 fences incompatible rollback without replacing prior records. Publication is a separate static-assets Worker with no application authority bindings.

Bug report posting (D-209)

D-209 (human request, 2026-11-03): the control service can create issues in the human's GitHub repository from in-application reports. SPEC-026 owns the wire contract, limits, Markdown and redaction rules, and configuration. Server responsibilities (PROPOSED mechanisms):

  • Advertise bug-reports/1 only when the deployment holds a valid BUG_REPORT_GITHUB_TOKEN; otherwise refuse POST /api/bug-reports with 503 bug_reports_unavailable and make no outbound request. An invalid token, repository or label disables posting with one fixed-field log line and never prevents the chat service from starting.
  • Accept the route only for an authenticated, enabled Home account (not a visitor or conversation-only connection), inside the existing authenticated API budget. Validate the body before any limit is consumed.
  • Within one storage transaction: replay or reject a reused identifier, check and consume the per-account hourly and per-server daily units, and reserve the identifier as pending. Then call POST https://api.github.com/repos/{repository}/issues with the bearer token, GitHub JSON media type, a fixed user agent, API version header, redirect refusal and a ten-second timeout. Record the created number/URL for replay; on any failure release the reservation and map the outcome to the SPEC-026 error codes.
  • Build the title and body with the shared SPEC-026 functions, adding the server domain and, only on opt-in, the authenticated account's qualified address. Re-apply diagnostics redaction regardless of client behaviour.
  • Never place the token, report text or account in responses, errors or logs. Logs are {"type":"bug-report","event":"created"|"failed"|"disabled"} with only an issue number, upstream status or fixed reason.
  • Records bug-report (replay/pending) and bug-report-rate (counters) carry expires and are removed by ordinary pruning.

The Node and Worker adapters use the same Service code. Workers deployments already use global_fetch_strictly_public; api.github.com is a fixed public HTTPS host and no client-supplied URL is fetched.

Event hints (D-221)

D-221 (human selection, 2026-11-07): WebSocket change hints with authenticated canonical synchronization and polling fallback. SPEC-027 owns the wire profile and privacy rules. Server responsibilities (engineering selections under D-024):

  • Adapters. Worker and Node call Service.enableEvents() once and advertise event-hints/1. Each wraps its Sql with observeSql(…); the store schema is unchanged. The Worker Domain routes the mounted /api/events upgrade before Service.handle, uses the WebSocket Hibernation API (acceptWebSocket, ≤2 KiB serialized attachment without the ticket, setWebSocketAutoResponse for the exact ping/pong pair) and rebuilds the hub from getWebSockets() at the end of open() before any event runs. The Node adapter validates before ws handleUpgrade (maxPayload 512, no compression, echo only sloppy-events.1) and closes sockets with 1012 on shutdown.
  • Tickets. POST /api/events/ticket after ordinary authentication and the api: charge; exact {} body; event-ticket:<account> 20/min; four outstanding per session (oldest deleted); record event-ticket keyed by the ticket digest with session digest, account, device, visitor flag, grant digest and expiry; expired rows pruned on issue and in the maintenance sweep.
  • Accept. The ticket is deleted in its own transaction before further checks. Session currency mirrors LoginSessions.read without a bearer (expiry, retirement, pending, trusted signing key); identity currency mirrors sessionIdentity and the visitor grant. Socket lifetime is the lesser of the session deadline and 300 s. At most 4 sockets per session (oldest closed 4429) and 256 per host (503).
  • Committed change capture. observeSql interprets only the exact Store.put/Store.delete statements for room, room-member, direct, direct-inbox, channel-permissions, session and user, reading old values (room counters, direct members) by point lookup before the write. Changes are staged only after the write succeeds and published only after the outermost transaction commits (or immediately for an autocommit write); each transaction keeps a staged-length savepoint, so a failed inner transaction drops its own changes even when an outer one commits. Other statements that write a relevant kind are *uncertain*: they never produce a hint, except that uncertain session/user writes revalidate every socket. A write the adapter proves changed no row is not staged at all, exact or uncertain: Sql.run returns the changed-row count where the adapter can report it (Node node:sqlite changes; Durable Object cursor rowsWritten after draining, which also counts index entries, so only zero versus nonzero is relied on), and a reported zero for a single statement is a proven no-op. An adapter that returns no count, or text with more than one statement, stays conservative (treated as a change). Consequently the per-request no-op Service.prune() session deletes recheck no socket; a prune that actually deletes a session still revalidates every socket. Deleting a channel tree captures, inside the command transaction and before any room, membership or voice row changes, the connected accounts that can read one of the deleted rooms or hold their own membership in one (EventHub.captureReaders, one batched readable call and point membership lookups per connected account); this staged reader set follows the same commit/rollback rule and yields a structural sync, so a formerly readable but unwatched room's deletion is hinted although the room no longer exists at flush. Thread retirement needs no capture: a retired thread is unoccupied and has no live root, so no account can read it at retirement. This is independent of request completion, drain() lanes, blocked SFU work and the maintenance alarm. No frame is written inside a transaction.
  • Evaluation. One trailing 100 ms coalescing window; per changed room and connected account one batched readable(account, rooms) call (the existing admission, permission, thread and conversation predicates), never a global history scan. Revocation is evaluated first. Every recipient is revalidated in batch before sending. Frames are spaced ≥250 ms per socket with kinds merged; pending kinds older than 2 s are dropped (polling covers them). A journal above 512 entries drops hints rather than broadcasting. A socket with more than 2 KiB unsent waits; above 16 KiB it is closed 1013.
  • Pacing. The hub reads the existing api:<account> fixed window and sends hint frames only while count + cost ≤ 20 + 180 × elapsed/60 s (cost = hinted kinds per device), prioritizing watched-view sockets. It sends none while the previous window projects at or above 180. This bounds hint-started reads under the unchanged 240/min account limit; it adds no new limit and does not change existing request charging.
  • Sweep. The Domain alarm and the Node timer close sockets past lifetime (4001) or idle for over 90 s (4408, using the runtime auto-response timestamp when hibernated), revalidate authority (4401) and prune tickets. Hibernated sockets past their deadline receive no hint because every send rechecks the deadline.

Approved video-delivery successor — D-167

D-167/SPEC-024 owns distinct native and managed presentation contracts. Continue native per-packet leases, hard rate policing and existing screen authorization. Future managed presentation operations require authenticated role checks, bounded owned provider resources, closure/reconciliation and truthful pending/effective reporting; they do not advertise a native four-second partition cutoff or independent byte policing without evidence. Do not place provider calls on the microphone renewal critical path. See SPEC-024.

D-166: advertise and validate SPEC-023 video-adaptation feedback in existing authenticated screen leases, filter to permitted watched publications, and project only bounded advisory feedback within current scoped voice authority. Omission/unwatch/policy withdrawal clears it; no feedback grants media authority.

Cross-home direct-conversation transport correction

The public-only network adapters must carry the already authorized SPEC-018 delegated authority POSTs at exact api/direct/policy, capability/inspect, notification, invalidation, invalidate and notify paths, including configured service-base prefixes. These endpoints authenticate purpose-bound grants/tokens in their existing bodies; the transport adds no login authorization, cookies or ambient credentials. Reject query strings, trailing-path variants, arbitrary direct commands and bodies above 16 KiB. Existing federation inspection/presentation requests retain their 4 KiB limit. HTTPS public-address validation, manual redirect handling, cancellation and bounded deadlines remain unchanged. This restores cross-home contact/call behavior; it does not waive blocks, acceptance, current home approval, revocations or one-device call ownership.

Testing: pass the actual production Worker adapter into the two-server service fixture; accept a foreign caller's contact request, start/deliver/answer the incoming call, then apply a remote block and verify denial. Boundary tests cover all six permitted paths, unsupported mutations, credentials, oversized bodies, queries and method variants.

Acceptance criteria:

  • Two users attending the same foreign server can accept an incoming private call hosted by their canonical home authority through the deployed public transport.
  • The current remote block and all existing contact acceptance checks remain enforced.
  • Only explicitly listed delegated endpoints pass; direct account commands and ambient login/cookie headers remain rejected.

Screen sharing authority (D-128/D-129)

The host advertises and validates SPEC-023’s additive video-sequence capability/optional publication marker, retaining it through publication state projection and renewals. Omission retains legacy publication compatibility; unknown markers fail. This does not change native relay grants, authorization or media policy.

R-117–R-120/D-128–D-130 request the screen-sharing extension in SPEC-023. The server owns authenticated allow/deny and bitrate settings, channel-admin versus server-admin authority, exact-channel relay exceptions, effective-policy projection, presentation grants and bounded relay enforcement. Channel-only rights do not confer server administration; foreign home roles and temporary-group creation cannot grant a host exception. All channel depths retain the same available controls under SPEC-022.

Keep ordinary-channel access and direct/group consent boundaries unchanged. D-129 permits server-admin relay exceptions below a separate infrastructure ceiling; relayed paths must enforce the effective rate independently of a client's encoder hint. Authorize and account for video and optional sound separately from microphone voice, retain participant-wide audio mute, and preserve E2EE opacity. Direct bitrate exemptions never waive media permission/revocation. SPEC-023 owns accounting, route classification, numeric defaults and wire/migration prerequisites, under the completed D-134 profile. Local alpha.24 implements persisted host/channel settings, publication/subscription grants and native relay enforcement; physical and deployment capacity acceptance remain separate.

Persist authoritative policy atomically with its revision and audit/enforcement work; reject stale/unauthorized changes and expose pending versus effective enforcement. Rate reduction, permission withdrawal, group closure and account/device movement must invalidate affected grants without creating new membership or reviving old authority. Listener ducking is local client behavior under SPEC-005/023, not a host-adjustable shared gain.

CONFIRMED D-014: clients and server have separate specifications. Confirmed server outcomes include domain federation, authoritative room hosting, Workers-based reference hosting with alternative deployment support, configurable room encryption, server-controlled permissions, and managed/self-hosted media. Detailed mechanisms below remain PROPOSED unless an accepted requirement/decision identifies otherwise.

Direct voice and relay fan-out (D-086)

Implement SPEC-017: require the new capability, validate signed per-attendance exchange snapshots and target membership, expose only addressed envelopes to the authorized live device, and project fresh bounded source authority on lease responses. Persist only bounded encrypted key boxes/SDP with attendance, pruning them on revision/expiry. The native relay validates one signed common frame then checks each target lease/backpressure independently. New grants bind mode, signing identity, domain and destination UUID. Direct-path enforcement status describes conforming-client rejection by deadline, not independently verified peer disconnection. Configuration and protocol constants remain owned by SPEC-002/003/004/017. Tests and acceptance follow SPEC-017.

Conversation extension — 2026-10-19

D-068/D-069 add the SPEC-013 authenticated reply and derived thread-call contracts. The server validates references against eligible retained history, resolves one internal call per thread, filters call visibility, derives permissions from the parent and propagates moderation/removal enforcement. Internal voice rooms cannot be independently administered.

Saved contacts (D-071)

Implement the authenticated, account-private contacts endpoints and synchronized projection in SPEC-014. Only the owning account may read or change its list; saved contacts confer no roles, membership, presence or delivery rights. Recent history is never uploaded.

D-194/D-195: enforce the additive pinnedAt contract in SPEC-014 on both contact-save input forms. Generate the date only for a genuinely new pin, retain stored dates on snapshot updates regardless of older-client omissions, and preserve undated legacy records. Contact dates remain account-private metadata; no new presence or consent follows from a pin.

D-194/D-195: SPEC-018 conversation summaries add lastMessageAt using the same retained, viewer-eligible membership intervals as lastMessageSeq. Use the host acceptance timestamp of the greatest eligible message sequence, or zero when none exists. Never substitute creation, activity, call, read or open time. Existing clients may ignore the field; native clients receiving an older response without it treat recency as unknown/zero. No configuration is added.

Current people profiles (D-185)

Saved-contact reads/sync project current nickname and picture from a matching stored account (domain, UUID and username), preserving the saved destination/context. Disabled accounts do not expose a current picture. Foreign labels remain verified snapshots until the server receives an authenticated profile update; never poll private membership or join foreign services to refresh a label.

Advertise people-profiles/1. Authenticated POST /api/direct/profiles accepts exactly {people: [{id, domain, username}]} and returns {people: [...]} containing only matching current directory-visible identities with nickname and optional picture. Use the same caller/target eligibility as Server Members; conversation-only visitors cannot read it. Omit unavailable, disabled, hidden or identity-mismatched entries without returning account, device, role, membership or activity fields. It is a read with no account/contact mutations. Existing direct-directory behavior remains compatible.

Configuration: fixed maximum 100 requested identities per batch; empty/non-array/oversize/invalid identity bodies fail with a normal validation error. Reuse authenticated API quotas, origin/session enforcement and bounded body limits. No deployment setting. SPEC-005 owns refresh timings.

Testing: exercise authenticated current nickname/picture reads after profile changes, clear/removal, saved context preservation, foreign snapshot behavior, minimal fields, malformed/oversize requests, mismatched identities, disabled/hidden targets and conversation-only denial.

Acceptance criteria:

  • Current names replace stale saved-contact presentation without changing identity/context or permissions.
  • Batch reads disclose no more than the existing authorized directory and cannot create federation admissions or presence information.

Direct conversation authority (D-087/D-090)

SPEC-018 defines the approved shared direct/temporary contract and D-088 history policy under D-090. Its implementation shipped in alpha.11 and remains active in alpha.12. This component owns its authenticated directory, request/invitation admission, block enforcement, canonical conversation resolution and lifecycle. Numeric retention/lifetime settings remain in the shared owner, not independently selectable server defaults.

Provide a separate authenticated Server Members projection to enabled local members and currently admitted visitors of that selected server. The directory audience is all enabled server members, including admitted visitors, regardless of shared channel. Return only qualified account ID, username, domain and nickname; exclude invitations, disabled accounts, device/recovery material, administrative access fields, private channel membership and live activity. Search/paginate within that authorized projection, rechecking caller membership and quotas. Public descriptors and conversation-only admissions cannot enumerate it. D-090 approves this directory audience; the existing moderator-only api/accounts contract stays restricted.

Implement a purpose-bound first-contact/call/group inbox and scoped conversation admission with strict participant/device proofs. Neither a contact snapshot nor a claimed common server grants delivery authority. D-089/SPEC-018 require recipient acceptance before ordinary messaging or ringing; every endpoint must enforce the gate independently of client UI. The accepted-pair/block transitions, caller cancellation and answer races serialize durably. A successful answer uses the existing home voice authority and cannot create a second active call. Foreign conversation invitations cannot become public server joins, ordinary-channel grants, account administration or directory access. Current home-device verification remains required.

Ordinary members may create the hidden conversation types under their own quotas; ordinary channel creation remains owner-only. Reject new-type objects through legacy channel CRUD, listings, thread derivation and permission inheritance. Direct membership is the immutable pair; temporary-group admission follows recipient-bound invitations and current block/capacity checks. The group creator's scoped removal/end rights do not grant server roles. Host account disablement/domain policy may deny service but never grant the operator decryption keys or participant membership.

At temporary closure, revoke live/media state and reject new messages/invites, retaining eligible read-only text under D-088. Persist original expiry and membership evidence for history/device/recovery operations, use immediate expiry filtering and retryable physical cleanup, and do not reset deadlines on restart or retries. No global change to seven-day channel/DM retention is allowed. Storage/schema/capability completion must reject old readers that could expose a hidden group or extend retention. SPEC-018 owns required server unit/integration coverage and completion conditions.

Scope and responsibility

D-081/D-082: SPEC-016 adds capability-checked encrypted voice and bounded public key publication during lease renewal. Validate the active device signature, current attendance, room revision, monotonic generation and fixed deadlines before publishing offers. Store only public offers and expiration state; preserve existing federation approval and relay authority. No history, recovery-secret or content-key ownership moves to the server.

This specification owns the server application and its orchestration of deployment/media adapters. The client specification owns UI, local controls, endpoint keys, capture/playback, and OS/browser integration. A media relay is a separate service behind the server's adapter contract; its capabilities must support the same externally observable enforcement rules.

ResponsibilityServer behaviourOwning shared contract
Accounts and authenticationAuthenticate local users/devices, validate foreign identity claims, revoke sessions, and bootstrap the operatorSPEC-003
Domains and room authorityDiscover peers, enforce federation policy, route to the correct room host, and reject unauthorised authority claimsSPEC-002
Authorisation and administrationEvaluate rights, expose effective capabilities, apply settings/moderation, and produce audit recordsThis specification
Room and event processingValidate commands, serialize host-authoritative changes, durably accept events, and expose permitted historySPEC-001, SPEC-006
Direct communicationRoute/queue opaque encrypted content and coordinate authenticated direct calls without holding participant content keysSPEC-003, SPEC-006
Media controlIssue scoped grants, configure adapters, track media ownership, and enforce active publication/subscription revocationSPEC-002, SPEC-004
Storage and operationsApply retention/quotas, run retryable work, recover durable state, and report permitted diagnosticsSPEC-006

This responsibility map is an implementation boundary, not a second definition of protocol/security/media defaults. A server cannot read E2EE content by virtue of being its host, and cannot prove a physical PTT key press on an arbitrary client. Those limits remain as specified in SPEC-003/SPEC-004.

Request and event processing

Proposed command flow: identify the selected protocol/version; validate the request envelope and caller; resolve resource authority; evaluate current permission and constraints; apply the operation through the relevant durable/adapter contract; then return the actual acceptance/outcome state. Do not let a successful client-side check bypass any of those steps.

Room mutations use the host's authoritative order and approved revision/idempotency semantics. A foreign user's home-domain administrator role does not grant room authority. An explicitly appointed foreign room administrator receives the supported actions allowed by the host's policy, like any other member.

Use the SPEC-006 recoverable-commit contract: commit authoritative state, operation result and required external work together or through an equivalent specified recovery protocol. Acknowledge acceptance only at that boundary. Expose an authenticated operation-result query/retry contract; a timeout cannot imply rollback. Bind command identity to actor, scope and payload fingerprint, reject changed-payload reuse, and never repeat an expired command merely because its result cache was removed. Rechecking current authority for a new command and reconciling an existing committed command are distinct operations.

Direct-message delivery and room history obey SPEC-006. Encrypted message/board payloads remain opaque; the server enforces only what authenticated outer metadata and authorised operations make available. Validation of decrypted board operations remains a client responsibility under the shared board contract.

Authorisation and capability contract

The server MUST authorise every action. It exposes effective rights so clients can adapt; capability responses are not a substitute for action-time checks.

Proposed capability response fields: action identifier, resource scope, effective allow/deny, applicable constraints, policy revision, maximum cache age, and a safe reason where disclosure is permitted. Emit permission-change events and revoke affected live grants. Unknown/unsupported actions receive an explicit denial/error, not an implicit grant.

Suggested action vocabulary, not final wire names:

ScopeActions
Room reading/writingDiscover, join, read history, send, edit own message, delete own message, moderate messages
MediaListen, publish microphone, publish screen, publish screen audio, publish camera, change own mode
WhiteboardRead, draw, edit own objects, edit others, clear, export
Membership/moderationInvite, admit from lobby, remove, ban, move, mute participant, change shared gain
ConfigurationChange room settings, change media profile, manage roles, view audit events
DomainManage federation, accounts, quotas, media adapters, and domain policy

Reference-server role-based permissions with scoped overrides are proposed. Resolve exact precedence, explicit denies, inherited settings, delegation, privilege escalation prevention, and protection of the last owner before implementing the evaluator. Other server implementations may use a different internal model if they expose conforming behaviour.

The hierarchy is the hosting domain's hierarchy, including any community layer selected under Q-19. An inherited setting must have an explicit inherit/omitted representation distinct from false; a descendant cannot weaken a fixed requirement or an ancestor restriction defined as restrict-only. Return the effective value and policy source where disclosure is permitted. Whether home domains may impose additional restrictions on their foreign users remains Q-38; foreign assertions do not create host grants.

For encrypted objects, issue authenticated authorisation evidence tied to actor, scope, action/constraints, operation identity and the accepted position/policy revision. This evidence is distinct from a short-lived UI capability hint: it supports deterministic client verification of historical encrypted operations under SPEC-006. Specify canonical binding, retention, revocation ordering and snapshot/replay rules in the protocol profile. The server does not claim to validate content it cannot decrypt; clients verify the evidence and the shared object rules without replacing server role authority.

Bots use the same authorised-account action paths; optional bot classification does not confer administrative or decryption privileges. Noninteractive access must have a scoped, revocable authentication path when implemented.

Administrative processing

Expose supported domain/community/room settings through authenticated APIs usable by the clients: permissions, federation, media, PTT, retention, quotas, moderation, and authorised audit access.

For a settings mutation, validate the current caller, target scope, expected revision, allowed range and inherited constraints. Persist the accepted mutation and produce the new revision, effective value, and propagation state. A stale revision returns a conflict without overwriting the accepted value. Define live-session transitions for capability disablement, PTT-policy changes, hard mute, and media-profile changes.

Media enforcement outcomes

Proposed action contract: acceptance and external enforcement are separate dimensions. Each response/event binds an operation ID, actor/target scope, accepted policy revision, current enforcement state and safe failure detail. Include acceptance and observed completion times where applicable; they are not interchangeable timestamps.

StateMeaning and permitted transition
Rejected commandNo authoritative mutation was accepted; no enforcement-complete result is implied
Accepted / pending enforcementMutation and retry/reconciliation work are durable; new grants obey the new revision, but existing paths have not all been confirmed stopped
EffectiveEvery affected active forwarding path has stopped or been terminated, with evidence from the approved adapter contract or proven lease expiry; record completion for this revision
Failed enforcementA required effect failed or its deadline elapsed without sufficient evidence; retain the deny policy, disclose incomplete enforcement and run the specified reconciliation/termination procedure
SupersededA later authoritative action replaced this policy revision; retain its audit/outcome history but do not let late adapter callbacks overwrite the newer state

Retry can move failed enforcement back to pending and then effective. A superseding unmute is a separately authorised mutation, never an automatic response to a failed mute. Pending jobs/outcomes survive restart. Effective is a claim about the corresponding revision, not permission for a newly arriving device to bypass its policy. Shared-gain propagation is a conforming-client behaviour and must not be reported as cryptographically enforced playback gain.

For D-019 mute, atomically establish the participant-wide audio deny policy and durable revocation work; deny new audio grants and revoke all existing audio paths for every supported device, while preserving video permission. The adapter contract must identify any setup credentials that could be replayed and prevent them from creating an unmuted path. Completion requires all target paths, not one successful request. During a partition, the independently enforced active forwarding lease provides the maximum continuation interval. Admission-token expiry alone does not count. Hard bounds and retry/termination timings remain OPEN under Q-22 and must be chosen before conformance.

Reject in-place room security-mode changes under D-018. Public/private admission and historical retrieval use the fixed bundles and membership intervals in SPEC-001/SPEC-006; a settings API cannot bypass them through independent visibility/history switches. Account invitations follow SPEC-003. SPEC-011 supersedes the original V1 single-device restriction and key-loss-only recovery: approved devices share account authority, one device holds voice, and password-plus-key recovery covers eligible retained copies. Administrative replacement still does not restore lost content keys.

Record administrative actor, scope, target, prior/new state where safe, and outcome according to the audit contract. Never log provider secrets or encrypted user content to explain an administrative action. Required hard mute acts on existing media paths and prevents re-publication until permitted; lifting a mute cannot start a user's capture.

Provider credentials and initial admin bootstrap remain protected deployment concerns. Ordinary media-policy changes must not require the operator to use the provider console after setup. Bootstrap must not expose a shared/default administrator password.

Deployment and lifecycle

Implement the control application for the Workers reference deployment and keep provider-specific dependencies behind the approved adapters. Reconstruct authoritative state after invocation loss/restart; transient process memory alone cannot hold an acknowledged durable mutation.

Support managed and self-hosted media through the same required contract. Reject adapters that cannot satisfy encrypted forwarding and timely active-stream revocation. Alternative control deployment and independent-operator documentation follow SPEC-002/SPEC-006; no mandatory reference-domain dependency is assumed.

An outage must have bounded media-authority continuation through active forwarding-lease expiry/revocation semantics. Queue acceptance, authoritative acceptance, effective enforcement, failure, expiry and supersession remain distinct; an external action is not complete merely because its request was queued. Restoring an older backup follows SPEC-006's fenced authority-recovery contract, not ordinary restart behaviour.

Linked-device authority (D-044–D-046/D-059/D-060; SPEC-011)

QR linking (D-171): implement the SPEC-011 password-free restricted QR request, signed/bounded anonymous rendezvous, approved-device claim and new-key-only polling/cancellation. All claim/admission/cancellation changes are transactional; recheck current approver/roster and exact target. Scan/poll/create alone grants no account authority. Preserve legacy manual linking and existing completion/revocation/history contracts. SPEC-011 owns fixed bounds and wire formats; no new deployment configuration or secrets. Unit tests cover races, unauthorized callers, bounds and restart/retry/expiry behavior.

The successor stores one account authority and an independently revocable device roster. Evaluate roles, membership, bans and participant mute from current account/room state for every approved client, while sessions and link/voice operations remain bound to their device. Same permissions does not mean a pending/unapproved device has full access. A login on an approved device must not reset passwords, revoke another approved device or move voice.

Implement the SPEC-003 linking/recovery checks transactionally with revisions, durable command results and audit metadata. Recheck authority after asynchronous work. Expose the device list and explicit approval/revocation outcomes through the client; never expose private key material. Account role changes and bans apply to every device, including direct API attempts with cached permissions. A recovered owner retains only the role currently held by that account; ownership is not reconstructed from a backup.

Enforce one active voice device per account and the SPEC-004 explicit handover sequence. Serialize competing moves, cancel stale preparations and stop renewing the source before granting the target after the proven forwarding cutoff. Bind completion to the current source/target devices, generation and authority revision; retries cannot create two sessions or undo a newer move. Revoking the source/target during handover must keep denied paths closed.

Persist encrypted history/recovery objects and coverage metadata under SPEC-006 without plaintext or content keys. Recovery uses current authority, not a database rollback; it cannot create another owner or bypass admission. Crypto/wire details are selected in SPEC-011 with ownership referenced from SPEC-003/006; this section adds no duplicate defaults. PTT input selection remains local to clients and grants no new server privilege.

Lobby grants and setup closure (D-052)

Implement SPEC-009's access commands under the current session, expected revision and idempotency checks. An admitted owner can grant/revoke access for any non-owner account; an admitted moderator can act only on ordinary members, never another moderator or the owner. Reject grants to disabled accounts. Revocation/removal closes current membership and voice and invalidates outstanding target room invitations atomically, including when the target is not currently admitted. Grants and revocations advance room revision through the existing enforcement machinery. Existing invitation admission must also respect the same target-role hierarchy at issuance.

/setup and /setup/ are server-gated in both local and Worker adapters, including HEAD: before bootstrap serve the application shell; after bootstrap return an uncached 404 with a sign-in link. The authoritative bootstrap API retains its transaction check, so concurrent or stale setup pages cannot create another owner. Existing owner IDs, keys and sessions survive deployment. D-052 introduces no new operator setting or recovery endpoint; the later SPEC-011 protocol defines the separate recovery endpoints.

PTT duration inheritance (D-095)

Resolve the optional channel override before the server policy under SPEC-004/012; thread calls use their parent's resolved duration and direct/temporary calls inherit the host. Only the owner updates the server setting through its existing expected-revision API. Persist a server change and revision/enforcement updates for affected inheriting voice scopes atomically, including descendant thread calls; leave explicitly overridden scopes unchanged. Existing room-settings authorization remains authoritative. Schema-6 conversion is owned by SPEC-012.

Channel hierarchy and PTT requirements (D-104/D-105)

SPEC-022/D-125 supersedes the schema-8 parent-access prerequisite in the following paragraph. Schema 9 uses uniform optional permission inheritance and propagating entries; hierarchy depth and PTT behavior remain unchanged.

Implement SPEC-012's schema-8 hierarchy validation, access projection and descendant revocation atomically with the permission-changing command. Every affected membership/history/media path checks the same effective ancestor access. Independent branches preserve their own scope. Parent access is necessary by default but does not grant private-child membership; grants and invitations cannot bypass it. Server and channel settings persist SPEC-004's PTT requirement/override and propagate effective changes through revision enforcement; the server cannot control the client's personal PTT preference or attest a physical input.

Unit coverage and acceptance include all SPEC-012 hierarchy boundaries and SPEC-004 mode truth tables, authority failures, permission loss during voice and stale/unauthorized settings. Existing thread, direct, device-history and public/private routing regressions remain required.

Profile pictures (D-096)

SPEC-019/D-096 owns profile-picture formats, limits and read capabilities. Extend the home-account self-only profile command under its ticket/revision checks, store current picture bytes separately, validate bounded PNG structure and atomically invalidate replaced/removed references. Project only the optional reference through authorized identities/directory/contact snapshots. Picture resources expose no account directory or arbitrary URL retrieval; they reject inactive owners and deleted references.

Voice audio cues

D-097/R-103: persist revision-checked sound preferences at the home account and project them only to authenticated self responses. SPEC-020 owns the wire schema, defaults and privacy contract. Public identities and visitor attestations exclude preferences.

Public links (D-115) use existing discovery and admission APIs. The server remains authoritative for admission and permission-filtered room enumeration under SPEC-015/012; a locator grants no access.

D-138: enforce SPEC-012’s owner-only recursive deletion transaction, confirmed scope and bounded media revocation. Keep server context functional without a Lobby and never recreate deleted channels on restart. Channel deletion does not delete server accounts or independent conversations. No new configurable permission or retention default applies.

Public usability authority (D-172–D-180)

The server owns transactional admin/moderator pin changes, retention/eligibility-preserving pin projection, bounded expiring disruption announcements, transient numeric connection reports with admin-only aggregates, and verified owner-opt-in public directory metadata. It retains all admission, account, channel and encryption permission checks in low-friction public mode. Listing and convenience preferences grant no authority. SPEC-013/021 and the increment review identify the affected contracts and validation; these requested responsibilities do not claim completed delivery.

Pinned channel comments (D-172)

The channel-pins/1 capability owns one independent pin pointer per ordinary text-capable channel. Owner/moderator commands bind retained original, exact expiry and host/channel; authenticated copy/rejection endpoints enforce current membership and approved device rosters on every call. Persist only encrypted deliveries and historical moderator identity; prune on clear, original expiry and channel deletion. Pin changes do not increment the voice membership revision. SPEC-013 is authoritative for the one-message pre-join exception, copy limits and wire profile.

D-222: continuous-transmission duration values and the one-time saved-policy upgrade are owned by SPEC-004/012. Clients accept and expose the ten-minute ceiling; the server upgrades saved shorter limits transactionally before serving current state. Existing authorization and fresh-input rules still apply.

Server user invitations (D-226)

D-226: support owner-only server-context invitation/account-list commands under server-invitations/1, with strict payloads, current server revisions, idempotent replay and atomic propagating membership on verified redemption. SPEC-022 owns the full invitation, inheritance and compatibility contract; retain existing ban, authority, history and voice boundaries. No new configuration is introduced.

Configuration

D-221 event hints (SPEC-027) add no operator, administrator or user setting and no kill switch. Fixed server values (EVENT_SERVER in shared/event-hints.ts, engineering selections under D-024): ticket lifetime 30000 ms, single use; 20 tickets per account per minute; 4 outstanding tickets per session; socket lifetime min(session deadline, 300000 ms); 4 sockets per session; 256 per host; coalescing 100 ms; per-socket frame spacing 250 ms; pending-kind lifetime 2000 ms; announced heartbeat 30000 ms; idle close 90000 ms; 60 watch frames per socket per minute; journal 512 entries; buffered hold 2048 bytes and close 16384 bytes; hint pacing burst 20 and reserve 60 under the existing 240/min api: limit. The 240/min limit itself remains the existing SPEC-008 value.

The council performance increment adds no configuration. The one-second pending-enforcement and 60-second idle maintenance cadences remain existing fixed values (CADENCE in server/maintenance.ts); the redundant indexes are fixed storage engineering, not settings.

D-220 native media gateway policy: public POST /lease obtains its existing placed media-v1 Durable Object using retry: { timeoutMs: 2000 }. This is a fixed per-stub runtime policy in milliseconds, applied on deployment, with no environment, administrative or user override. Omit maxRetries to retain Cloudflare’s default four retries (five attempts total); non-lease stubs retain both runtime defaults (four retries, 10000 ms). The two-second budget prevents later retry starts and cancels a running retry at the deadline; it never cancels the initial attempt. Keep default request-identity duplicate suppression: do not mark mutation handlers retryable() and do not add an application retry loop. String JSON bodies remain replayable; grant validation inside the object retains the original signed expiry and never extends authority on retry. Control API and Container request timeouts are unchanged. Tooling requires Wrangler >=4.158.0 and matching retry-option types. See Cloudflare automatic retries. Any efficiency benefit is inferred from these bounds; latency and billing savings are unmeasured.

D-209 bug-report settings BUG_REPORT_GITHUB_TOKEN (secret; absent disables), BUG_REPORT_REPOSITORY and BUG_REPORT_LABEL are defined with their types, validation and defaults in SPEC-026. Supply the token with wrangler secret put for Workers or the process environment/ignored .dev.vars for Node; changes apply on deployment/restart.

D-172 disruption announcements are owner-only server state: kind outage or update, 1–240 characters of plain text, and duration 1–1440 minutes. The client editor initially selects 15 minutes; no announcement exists by default. Expiry is computed from server acceptance time; clearing removes the announcement immediately. D-173 reports contain only finite nonnegative allowlisted metrics (rttMS, voiceRttMS, sendKbps, receiveKbps, jitterMS, lossPercent). Upper bounds are 1000000 ms, 1000000000 kbps and 100 percent respectively. Accept at most one report per device per second; replace its previous record, expire it after 30 seconds, prune expired records on report/query, and retain at most 1000 active device reports. Aggregate current devices per account first (sum bandwidth, average latency/jitter/loss), then return count/average/minimum/maximum across accounts. Only the server owner may read server-wide aggregates; ordinary users may submit their own report but cannot read other reports. Never return account/device identifiers, addresses or raw reports through the aggregate endpoint. These are fixed protocol bounds, not admin-editable defaults.

Managed presentation trial (D-169, SPEC-025): SCREEN_SFU_ENABLED is an operator deployment boolean, default false; accept environment boolean or literal true/false for local process environments. If true, SCREEN_SFU_APP_ID is required (32 lowercase hexadecimal characters) and SCREEN_SFU_APP_SECRET is required (40–128 URL-safe alphanumeric/underscore/hyphen characters). They have no fallback values. The secret belongs only in backend secret storage and ignored owner-readable local credentials; never expose it in state, logs or client assets. Omitted enablement disables the adapter even when credentials are pre-provisioned. Invalid enablement or missing/invalid enabled credentials fail startup. Configuration changes take effect on deployment/restart, without persisted user overrides. The testing deployment enables the adapter for all sloppyvoice.com channels, preserving ordinary sharing/admission policy; other hosts remain disabled. SPEC-025 owns capability spelling, authority/operation ownership, cooperative rate disclosure and provider cleanup. SPEC-024 owns managed global routing and the absence of a universal provider partition cutoff.

SPEC-023 owns the approved screen administrative/deployment inventory, runtime names, persistence and revision contracts. The control and native media services enforce that inventory; do not duplicate its authoritative defaults here.

D-124/D-125: SPEC-022 owns the successor ACL, server propagation and targeted invitation contracts. Enforce these in the server independently of UI filtering, using the same decision for listing, state, history/device copies and media. Named-account admission must use a freshly verified home identity, current host bans and issuer authority, with pending authorization consumed transactionally. The 24-hour pending lifetime and shared invitation capacity reuse existing limits. Schema 9 activates the successor capability after transactional migration under SPEC-022/D-125. Unknown or missing ACL state fails closed; older backends cannot read this schema.

D-102/D-103 implements the home-account login policy owned by SPEC-003 through existing owner-only, revision-checked server settings. Capture policy at successful local issuance/renewal; preserve all prior deadlines. Enforce signature, profile, registry, account and device checks on every request, including Unlimited. SPEC-009 defines public verification material and the restricted prepare/activate endpoints. Recheck authority after asynchronous password hashing, signing/key work and before atomic state changes. Renewal changes login credentials without ending voice or advancing room revision.

Schema 7 adds the default policy to legacy server settings without rewriting session deadlines, account/device keys or history. Old schema readers fail closed. The dedicated login-key ring is generated once in private durable metadata; public responses omit private material. Rotation retains public verification keys, and owner revocation removes matching live session families. Expired pending and retiring entries are pruned; unlimited active entries are retained until revocation. Existing visitor/delegation/media authority remains independent.

D-084 adds no operator settings: codec compatibility is a fixed protocol requirement owned by SPEC-009, and media bounds remain owned by SPEC-004.

The SPEC-015 public-server policy component is selected under D-049/D-072/D-076/D-077 for implementation before federation activation. Store server-policy as one revisioned record: name defaults to the canonical identity domain; publicVisitors and localRegistration are independent booleans defaulting to false; blockedDomains is an initially empty list of at most 100 unique canonical foreign identity domains; landingChannel is null initially or an existing ordinary public channel ID. Only the persisted server owner may update it. Omitted fields retain their values; null is valid only for landingChannel; explicit false disables its own control. Reject unknown fields, unknown policy values, duplicate/invalid/self domains, non-public/thread landing channels and stale policy revision. A server label is trimmed, 1–80 Unicode code points with control and bidi formatting characters rejected. Changes commit atomically and persist across restart. Closing public visitor admission leaves existing visitor records, channel memberships, history and grants unchanged under D-077; bans/blocking remain a separate check. This policy cannot enable an unimplemented federation runtime. It owns no environment variable or permissive fallback.

Initialize server-id once as a random UUID in the same persistent authority. It is operational identity, not an editable label or default environment override. No existing account ID, home domain or room ID changes. SPEC-015 owns public descriptor projection and authenticated discovery. The module's presence alone does not advertise public visitor support; activation remains gated by the foreign E2EE and cross-host voice acceptance checks.

The selected SPEC-015 runtime uses explicitly injected safe public network transports in Node and Workers. FEDERATION_ENABLED controls activation, with the closed runtime retained by default. Visitor rows have no password and retain host-owned roles and membership intervals. Registration, login, device linking, recovery and account invitations match the local identity domain as well as the username/account. Public local registration follows SPEC-015's one-use challenge and the independently persisted control above. First visitor admission raises storage schema to 4; older backends must refuse it. Thread creation must never lower that schema. Every foreign action checks a device-bound request proof, current home approval and current host blocks; refreshes cannot replace host roles or undo removals. Fresh recipient verification gates new E2EE posts under D-078, with state reporting the reason while eligible retained history remains available. Local and foreign voice share home-authoritative movement fences; media leases never outlive the original inspection's bounded authority. The wire and fixed lifetimes are owned by SPEC-015 and SPEC-004/011.

An owner-only visitor ban is an explicit, idempotent {target,blocked} operation. Blocking closes that visitor's admitted channel intervals at each channel's new host position, revokes destination sessions/preparation/voice and retains the disabled server membership for future ban checks. Preserve explicit channel grants so an owner-approved unblock can permit rejoining; unblocking does not itself reopen intervals, restore sessions or admit voice. Home ownership, a fresh grant, public admission and reconnect cannot override the destination's block. Account replacement remains local-only; a destination cannot reset a foreign password or replace its devices. The client presents this server-level action separately from channel removal and never labels it as home-account recovery.

D-064 adds account user preference nickname, written only by that authenticated account through SPEC-009. It is an optional, non-unique public label, stored in the existing account JSON record and shared by its approved devices. Default/legacy omission is "" (no nickname); explicitly saving "" clears it. Normalize supplied strings to NFC and trim surrounding whitespace, then permit at most 64 Unicode code points. Reject null/non-string values, control/surrogate/line-separator characters and bidi formatting controls; do not strip or silently truncate invalid input. Inner spaces, Unicode names and emoji are allowed. No role, device or room override. Changes apply on acceptance and propagate through existing authorized state/account reads; no new unauthenticated directory is added. This completion limit/normalization is an engineering selection under D-024/D-049 for D-064, not a new human-stated numeric preference.

profileRevision is nonnegative safe-integer account state, initially zero for legacy records, incremented on each accepted profile update. It is not configuration. Compare the supplied revision transactionally; stale writes return conflict and do not overwrite the profile. Nickname changes must not touch room revisions, membership intervals, key rosters, permissions, live voice or media enforcement. Existing command audit/result retention applies. Read projections expose nickname/revision through the same authorization as the existing identity; retained message author snapshots are not rewritten.

Room creation authority (D-055/Q-48)

D-058/P-027 selects initial member access as an optional list of distinct existing, enabled account UUIDs; omission means no additional grants, explicit null/duplicates/invalid targets fail the entire creation. The owner supplies it at creation; persist grants for that room without silently admitting the selected members or opening history/capture. The owner is admitted to the room it creates. Later access changes use the existing authorised workflow scoped to the selected room. This is access state, not a separate permission hierarchy.

CONFIRMED: only the domain owner may create rooms. Moderators retain management powers in rooms they can access; their role alone does not grant discovery, membership or content access to other private rooms. Ordinary members cannot create rooms. Enforce creation authority at the server, including direct API requests and retries, and expose the matching client capability. Existing owner/device protections and current-membership requirements remain applicable.

The room creation review records the accepted creation transaction, room-scoped processing and migration requirements. Q-47 selects text, voice and combined rooms; meetings are deferred. Creation authority is a fixed permission rule for this increment, not a new editable role or deployment setting; SPEC-012 defines the alpha.6 endpoint. The server must atomically create the room, owner admission, validated initial access grants and retry result, enforce SPEC-006's selected room limit and preserve existing lobby state. SPEC-012 supersedes the singleton parts of SPEC-009 with the additive wire/storage contract.

Domain discovery responsibilities (D-058/P-028)

SPEC-010 owns the descriptor and full-base-URL contract; SPEC-003 owns account parsing. Publish only implemented profiles and closed federation, validate identity/base configuration at startup, and route to the correct isolated instance before authentication. An identity-origin website must serve the descriptor without redirecting it to www or returning SPA HTML. API origin permissions remain separate from the public descriptor's CORS policy. Recheck the canonical local account domain at authentication/invitation boundaries; no suffix or DNS change grants foreign privileges. The service must not mutate its initialized identity domain or bootstrap again when the endpoint changes. No arbitrary server-side discovery proxy is introduced.

Logical names/defaults below are PROPOSED. This section owns permission/bootstrap and server-interface settings; the linked inventories own the other server settings. The selected V1 and SPEC-010/011/012 profiles supersede this draft inventory for implemented features; remaining OPEN defaults must be resolved before their code is added.

PropertyScope and typeDefault and statusBehaviour
permissions.rolesDomain/community/room; role definitionsOPEN — initial roles not selectedDefines permitted actions and constraints; the evaluator cannot infer a permissive role from missing configuration.
permissions.assignmentsDomain/community/room; account-to-role grantsOPEN — bootstrap/member assignments not selectedGrants rights to canonical account identities, including authorised foreign accounts.
permissions.overridesDomain/community/room; scoped action overridesOPEN — initial value and precedence not selectedDefines inherited/explicit exceptions; may not relax fixed product/security requirements.
permissions.capability_cache_max_age_secondsServer policy; bounded secondsOPEN — not selectedLimits capability display caching; does not exempt any action from current authorisation checks.
admin.bootstrap_identityDeployment bootstrap; initial owner identityRequired — no default, PROPOSEDBootstrap authentication/generation method must be selected; no default admin credentials.
server.enabled_protocol_versionsDeployment/profile; supported protocol versionsOPEN — protocol not selectedControls explicit version negotiation; no silent incompatible downgrade.
server.allowed_web_originsDeployment; set of canonical approved origins, if the chosen web profile uses a listRequired — no implicit origins, PROPOSED; route/origin profile still OPENCovers API and realtime channels under SPEC-002. Must accommodate the approved independent-client federation model; no arbitrary credentialed-origin fallback or replacement for account authorisation. Remove/refine this row if another origin-policy mechanism is selected.
server.request_timeout_msServer/adapter profile; positive millisecondsOPEN — not selectedBounds request handling; timeout does not imply a committed operation was rolled back.

Additional server-owned settings are documented at their canonical locations:

  • SPEC-002 Configuration: domain/endpoint identity, delegation, adapters, provider credential references, placement and federation mode/lists.
  • SPEC-003 Configuration: room encryption defaults, registration/authentication, session/token/grant lifetimes, trust/recovery, signing keys and security policy.
  • SPEC-004 Configuration: domain/room PTT constraints, shared gain/limiter policy, media profiles, capacities, codec/quality bounds and connectivity.
  • SPEC-006 Configuration: durable/transient retention, queues/retries, history, quotas, attachment/whiteboard limits, backups and telemetry.

The client displays permitted server settings but does not own their persisted defaults. Client hotkeys, device selection, local mute/gain, and endpoint encryption keys are not server-configurable substitutes for the user's controls.

Operation IDs, applied policy revisions, enforcement states, completion times, historical authorisation evidence and authority generations are server/protocol state. They are not administrative settings. Complete omitted/explicit-deny/inherit semantics, source precedence, live-update timing and schema compatibility for the actual configuration schema before implementation. The exact role algorithm, initial roles and delegation limits remain OPEN; the state contracts above do not silently select them.

Multiple-server deployment settings (D-049/D-072)

FEDERATION_ENABLED is a deployment boolean, initially false on omitted configuration. It accepts a JSON boolean or literal environment text true/false; null and other values fail startup. The operator supplies it to control and media processes; changes take effect at restart/deploy. True enables the compatible federation wire, independently hosted credentialless client origins and server-bound media. It does not alter the persisted public visitor/registration policy. No user or channel override exists. A bound-media relay must be deployed before enabling this profile. Worker control/coordinator deployments require global_fetch_strictly_public with the default public network; SPEC-015 defines the transport boundary and no permissive fallback.

The reference shortcut service uses a separate SQLite Durable Object under the existing SPEC-002 jurisdiction rule. COORDINATOR_BASE_URL and JOIN_CLIENT_BASE_URL are required canonical public HTTPS base URLs without defaults; operator configuration is read at start/deploy, without request-host inference or user override. The reference deployment selects https://sloppyvoice.com/ and https://chat.sloppyvoice.com/. The coordinator never receives account tokens. SPEC-015 owns registration consent, immutable records, rate/capacity bounds, retirement and direct-link fallback. Existing identity discovery on the apex obtains its persistent server UUID from the configured control service binding; failure returns unavailable instead of inventing identity or redirecting account credentials.

Selected V1 server contract (D-024/D-031)

D-137 applies SPEC-006's longer fixed attendance lifetime to voice admission/renewal and home-server foreign-call reservations. Preserve existing persisted deadlines until a successful authorized renewal; prune expired records and never revive them through renewal. This does not extend SPEC-003 forwarding grants, moderation/revocation bounds, explicit leave/movement fences or Cloudflare generation deadlines. Server units cover delayed renewal and the expiry boundary for both local and Cloudflare adapters and independent home reservations.

SPEC-009 and the owning shared V1 sections supersede OPEN/proposed server mechanisms only within V1. One initial owner, moderators and members are the selected roles. The owner may issue account/room invitations, admit/remove members, reset non-owner accounts, assign/revoke moderator status, set PTT duration and apply participant mute/shared gain. Moderators may issue invitations, admit/remove ordinary members, mute ordinary members and change their shared gain or room PTT duration; they cannot change roles, reset accounts or act on the owner/other moderators. Members may send/read eligible room text, join/leave voice and change only their personal controls. Everyone needs current membership for room content. No role or bot label bypasses device trust or E2EE.

The owner cannot be removed/demoted/reset through these V1 APIs. Unknown actions are denied. Foreign identity/role assertions are rejected in V1; V2 direct routing will need authenticated foreign claims and explicit host grants. There are no inherited community roles or ad-hoc allow/deny overrides in this profile. All mutations recheck current role, membership, device and expected revision, including direct API calls from modified clients.

Membership, device replacement, moderation and settings update the durable room revision. Revocation work is committed with that change; the relay advances a minimum accepted revision so pre-change leases cannot reopen publication. New leases include the current effective mute state. Store accepted time, deadline, operation ID, revision and enforcement state. Report pending until the relay acknowledges or the verified lease cutoff is reached; stale callbacks cannot overwrite newer policy. The implementation must preserve denied publication when external work fails.

Bootstrap and signing secrets are owned by SPEC-002; authentication by SPEC-003; media policy by SPEC-004; limits/history/transactions by SPEC-006. V1 adds no duplicated default table here. Capability responses expose actions actually permitted to the current role and current revision, without exposing secrets. Their UI cache has no authority. The service never accepts ciphertext as proof that a caller may send to a room.

Selected Cloudflare alpha behavior (D-043)

D-043 separates asynchronous preparation from live admission. Persist one UUID preparation per account/device, its absolute expiry and ready result; deduplicate identical polls, reject conflicting concurrent IDs, and apply the SPEC-002 new-attempt limits transactionally. Recheck the request's session, device, membership and matching uncancelled preparation after provider work. Store ready credentials only in protected server state until expiry/consumption; remove them after join/cancellation/pruning. A ready preparation must still refer to a running, current generation outside its closing-admission margin at join. Voice records bind the selected generation/deadline; no lease is issued after that deadline or while media is disabled. The gateway alone starts/stops the singleton through the private service binding; public token-bearing requests cannot start a stopped generation. Native enforcement remains independent.

Public release distribution (D-051/D-061/D-170)

D-170 includes the exact SPEC-002 Android APK manifest in that allowlist, serving it as application/vnd.android.package-archive with the existing attachment, length, SHA-256, conditional/range and fail-closed storage semantics. Other package MIME behavior remains unchanged.

The website Worker serves only manifest-listed versioned files under /releases/. It streams R2 bodies without buffering a release archive in Worker memory. Select the exact Windows installer, Windows portable ZIP, Linux archive or Linux Flatpak manifest by its versioned path before deriving metadata or reading storage; never accept an arbitrary bucket key from the URL. GET returns a downloadable attachment with exact length, content type, stable manifest-derived ETag and SHA-256 header. HEAD returns equivalent metadata without a body. A single valid byte range returns 206 with a correct Content-Range; suffix/open-ended ranges are supported. Invalid, multi-range or unsatisfiable requests return 416. If-Range mismatch ignores the range; If-None-Match returns 304 only for an existing, size-matching object. Unsupported methods return 405; unknown keys return 404 before R2 access; missing/storage-error/size-mismatched release objects return an uncached 503 without exposing storage internals.

There is no bucket listing, authenticated application API, public upload or dynamic proxy on this Worker. Static-page responses retain a restrictive CSP allowing only same-origin styles/images and no scripts, plus nosniff, no-referrer and disabled microphone/camera permissions. The download worker consumes the canonical deployment/release declarations in SPEC-002 and does not alter application authority.

Audit-boundary engineering completion retains existing permission and limit owners. Validate join/move/foreign-claim eligibility before requesting owned SFU closure, then reauthenticate and resolve current session/device/membership/ACL/call/preparation/movement authority after asynchronous reconciliation for every adapter. A stale closure result cannot remove a newer Home fence or bypass another call’s surviving fence; final local admission checks the complete current account fence set inside its transaction. SFU setup rechecks its initiating login registry/device/delegation after provider/Home waits and cleans up only its exact late unauthorized resource, preserving ambiguous ownership. Malformed recovery/link identifiers consume only bounded peer counters; validate account/local-name shape before identifier counters. Rate keys above 512 UTF-8 bytes use a fixed digest representation. Generic API and visitor-request budgets are account-wide under SPEC-006, with current-minute legacy device usage carried forward on first account-bucket use. Per-device statistics sampling remains separate.

Anonymous GET info/server/login-key metadata coalesces global maintenance for at most 1000 ms after a successful pass, using process-local state shared across scopes; restart or clock rollback forces a pass. Route to the actual scope before pruning to avoid duplicate passes. Protected requests, explicit maintenance, local timers and Worker alarms retain unconditional immediate expiry/authority checks. This is a bounded reduction in redundant metadata work, not completion of global due-work scheduling or a new configurable maintenance interval.

Council performance increment (2026-11-07, engineering only; no behaviour, schedule, configuration or diagnostic field changes). Protected-request maintenance stays per request. SPEC-013 thread liveness reads voice once per pass and checks each unoccupied thread with a (room,seq) original lookup plus an indexed reply-root fallback, never a retained-history scan; rooms retired in one pass delete their enforcement records in one batched statement. Thread eligibility uses the same two lookups, each applying unexpired retention and the member's admission intervals. Retained-quota usage sums SQLite octet_length(envelope) (UTF-8 bytes of the stored canonical text) from a covering index; the incoming envelope is canonicalized once for size, digest, charge and storage, and identical replay still precedes charging. Store creates the redundant indexes messages_reply_root (malformed-JSON-tolerant reply-root expression) and messages_bytes idempotently after all migrations; persisted rows, columns and the schema marker are unchanged, older readers ignore them and a D-217 copy reproduces or rebuilds them. Records receive no room index (it would add writes to hot rate/session upserts). Enforcement, direct-conversation delivery and managed-SFU reconciliation are separate single-flight lanes shared by same-store scopes; a drain during an enforcement pass reruns once for jobs that arrived after its snapshot, never repeating an attempted job. Adapter triggers (Node timer/post-response, Worker request and alarm) call the lanes without a whole-drain guard. A Worker alarm awaits delivery for at most the one-second pending-enforcement interval, reschedules from its own start time, and leaves unfinished lanes running. On a warm media object, caller TURN issuance starts alongside warming; a cold start issues only after warming succeeds, and the final physical health/boot verification always follows issuance.

Testing

D-227/D-228: apply the library, logical-server isolation and control-projection tests in SPEC-028; official-client compatibility is established by default-history filtering, separately from API opt-in.

tests/history-share-quota.test.ts exercises the real linked-device history-transfer endpoint under SPEC-011: stored UTF-8 byte accounting for signed Unicode-bearing shares, below/exact/one-byte-over capacity, atomic rejection of an over-capacity batch, identical replay at full capacity without extra charging or version changes, conflicting retries, and exact expiry release. Synthetic retained-storage filler is explicitly distinguished from normally accepted shares. The retained usage aggregate uses octet_length(value) and still visits every matching history-share row; it introduces no counter, schema change or new limit.

D-221: tests/event-hints-server.test.ts (real SQLite Store through observeSql, fake clock/sockets/authority) covers ticket single use, 30 s boundary, hashed storage, exact body, rate and outstanding caps; upgrade refusals for query, offer shape, Origin and every revoked identity case; lifetime/session caps and host capacity; watched-room versus unrelated messages; zero frames for private, hidden, unjoined and non-participant activity; conversation, direct-record and notice targeting; membership loss, deletion (including captured prior readers of an unwatched deleted room, rollback discarding them and revocation before flush) and ACL changes; proven no-op writes staging nothing and adapters without a count or with multi-statement text staying conservative; logout/disable revocation, lifetime, idle; visitor freshness; coalescing and spacing; pacing priority; backpressure (including preserving the original pending age across retries, expiry after the two-second bound, stopping the retry timer, no stale hint on buffer recovery and a fresh eligible change still sending); frame policy; hibernation restore without spurious hints; uncertain writes; overflow; flush cost proportional to changed rooms and accounts; failed autocommit writes and caught inner rollbacks. tests/event-hints-node.test.ts runs the real ws adapter on an isolated loopback port (echo, ready, ping, hint, JSON refusals, binary/oversize closes, Node's browser-compatible WebSocket, revocation) and records the observed Origin/Cookie/Authorization headers. tests/event-hints-service.test.ts uses the real Service (capability, ticket route, visitor proofs, content-free hints, private-room silence, stale visitor suppression, logout and leave; an anonymous protected request's no-op prune with six distinct socket identities rechecks and hints nothing while an actual expired-session delete still closes its socket 4401 with no later frame; real channel deletion hints a formerly readable unwatched member but not an unrelated account, a rolled-back deletion or a reader revoked before the flush; thread retirement is silent and spares occupied threads). tests/event-hints-sql-count-workerd.test.ts checks the production Durable Object adapter (server/durable-sql.ts) in actual workerd and the Node adapter: zero for no-op deletes and updates, nonzero for real inserts, updates and deletes, and a no-op Service.prune() that schedules no flush. tests/event-hints-worker.mjs (in test:worker) uses real workerd: upgrade and echo, runtime auto-pong, replay 401, watch through webSocketMessage, committed-message hint, binary 1008, oversized ASCII and multibyte text 1009, query 400, logout 4401. The separate explicit node tests/worker-event-hibernation.mjs qualification installs pinned private tools without changing the application lock, runs the production Domain in actual local workerd and uses cloudflare:test forced eviction: original socket survival across new object instances, auto-pong without wake, no duplicate READY, restored watch/committed hints and canonical reads, revoked/expired sessions failing closed, invalid attachments closing 1012, and close-mode eviction followed by fresh-ticket recovery. It records source hashes and runtime integrity; --mutants checks test sensitivity with in-memory transforms. These are local helper results; actual hosted eviction and deployment recovery require separate hosted observations.

D-220: isolated tests verify lease-only stub selection, unchanged placement/name/body and omitted retry count; exact retry-budget boundaries, retry-count exhaustion, duplicate request suppression and an initial attempt lasting beyond two seconds; expired signed grants must be rejected inside the relay without forwarding. Distinguish a deterministic transport-contract model from actual workerd runtime checks and hosted networking evidence; a model alone does not establish provider retry timing. Normal preparation/renewal and revoked/restarted generation regressions remain required.

D-209: tests/bug-reports.test.ts exercises the endpoint with a mocked GitHub transport as listed in SPEC-026; no test contacts GitHub.

Visitor rate regression (2026-11-04): tests/visitor-rate-workerd.test.ts seeds a fixture host into the real SQLite-backed Domain under workerd, whose LIKE/GLOB pattern limit (50 bytes) matches Cloudflare and differs from Node SQLite. A visitor's first request in a minute with no current visitor bucket returns its normal result (permitted channel state 200; missing device proof 401 visitor_proof; GET api/session 403 home_account), never 500. Older device-specific buckets from the same minute still count toward the account-wide limit in SPEC-006. Rate-bucket SQL must not depend on LIKE patterns longer than 50 bytes.

Council performance increment: tests/thread-maintenance.test.ts checks 1/128/1000-thread liveness (indexed plans, one lookup per unoccupied thread, one voice read, original/reply-only/wrong-parent/expiry/occupied-call cases, batched mass enforcement cleanup) and both eligibility branches. tests/message-quota.test.ts sends real signed readable-Unicode and encrypted envelopes below, exactly at and one byte above 67108864 stored UTF-8 bytes, with identical replay and conflicting reuse at full quota, rollback after a later rate failure, expiry release and the 10000-message bound. tests/sql-access-workerd.test.ts runs the real Store/Service in workerd: covering-index plans, octet_length units, Service.prune() cursor rowsRead at legal 10000-row/64 MiB fixtures (supra-limit stress labelled separately), legacy upgrade, restart and D-217 copy/rebuild of the indexes. tests/delivery-isolation.test.ts blocks a managed-SFU provider request and requires a newer revoke to dispatch before release through Service.drain(), the Node trigger and the alarm callback (advancing clock; one-second cadence), plus single-delivery of late enforcement. tests/cloudflare-media.test.ts orders warm/cold issuance and final health, and rejects preparation when only the Container boot changes, on shutdown or at the closing margin during issuance.

tests/audit-server-boundaries.test.ts covers revoked/expired/device/access/call authority during waits, valid preparation and movement fences, rejected-action preservation, bounded invalid auth state, account-wide cross-device/minute/rollout limits, metadata-only maintenance coalescing and truthful audio-moderation enforcement. SFU tests use exact role/source ownership, partial/unknown cleanup, restart/late results, native acknowledgement with managed pending work and post-cleanup authority rejection.

D-172: service/crypto tests and real SQLite workerd checks cover pin authority, persistence, original retention, context/signature verification, future-member access without surrounding history and invalid-copy recovery. Actual application browser checks verify Pin/Unpin, placement and automatic redistribution by an ordinary member with moderator copying blocked.

D-172/D-173 unit fixtures verify owner-only notice publication and aggregate reads, foreign-owner rejection, numeric allowlists and bounds, per-device rate limits, per-account aggregation, logical expiry and pruning, capacity bounds and absence of returned account/device identifiers. D-179 fixtures exercise verified owner opt-in, search, withdrawal and unreachable/private-listing exclusion.

D-171 service/SQLite/workerd coverage exercises password-free restricted QR submission, signed anonymous registration, bounded storage/rates, exact claim retries, unauthorized polling, competing/stale claims, clock-skew clamping, cancellation/restart/replay and existing roster/revocation completion. Live tests use immediately cancelled anonymous records and never approve or replace production account devices.

SFU configuration/ownership/provider behavior follows SPEC-025. Validate default disabled admission, enabled credential validation, atomic target-budget reservations and cleanup while disabled with retained backend credentials. Test owner/call/device binding, replay-safe finite renewal, serialized subscriber answer, partial and late allocations, per-mid close/expired-session confirmation, unknown outcomes and blocked conflicting moves. Provider waits cannot hold the microphone renewal queue or SQLite transaction.

Public GET /info exposes only configured screenDelivery capability (native profile, or managed profile/frame profile/cooperative rate/global placement), never provider credentials. It does not prove actual media delivery or bypass per-channel policy. Pending owned resources still block conflicting local moves when cleanup credentials are unavailable; disabling admission cannot manufacture closure.

Screen-sharing units and integration must cover owner/moderator/member authority, exact-channel exceptions and hard ceilings, stale revisions, policy reductions, combined-source/rendition accounting, malicious over-rate clients, actual relay egress, direct-to-relay fallback and source/device revocation. SPEC-023 records passing shared-policy unit tests and isolated browser experiments; these do not establish authenticated host authority or native-relay enforcement. A-49 remains an integration/release gate; client hints alone do not establish enforcement.

D-103 units/service fixtures validate owner-only policy and key changes, stale revisions, strict JWT and registry rejection, finite/unlimited capture, unchanged legacy deadlines, restart, pruning, bounded candidates/overlap, password/device rechecks and revocation. Real workerd integration verifies WebCrypto Ed25519 issuance, activation and persistence through the SQLite Durable Object.

Validate the component responsibilities and failure paths for PTT inheritance (SPEC-004/012), profile pictures (SPEC-019) and voice sound settings (SPEC-020).

D-084 tests reject missing/old voice capabilities in both encryption modes and validate the signed readable Opus envelope while retaining all relay authority/race tests.

Two independently stored service fixtures exercise real grant/join/request handlers, a foreign home owner becoming only a destination member, destination-local namesake login, password absence, nonce replay and context substitution, retained membership when public admission closes, home-domain blocking, offline-member E2EE pausing with readable-history/readable-channel continuity, current-roster revocation, home-to-foreign and foreign-to-home voice fencing, and independent local registration. These fixtures do not substitute for the remaining desktop/web multi-server and deployed-network acceptance.

The SPEC-015 policy/directory foundations have focused units for independent closed defaults, persisted server UUIDs, owner-only policy writes, optimistic conflicts, invalid/null/unknown values, unavailable federation runtime, public E2EE landing eligibility, block/ban precedence and preservation of existing visitor records when admission closes. Delegation tests cover audience isolation, neutral roles, fresh approved-device rosters, account/grant revocation, expiry, restart, asynchronous account rechecks and signature substitution. Public-network tests execute the real HTTPS lookup path against rejected DNS answers; discovery fixtures cover changed authorities, response bounds and slow-body aborts. Directory caches reject stale, changed-root and rollback data and never use expired results during outages. Cross-host/API/media integration additionally tests two independent stores, shortcut consent, bans, foreign encrypted history copies, home outages and actual relay forwarding. Browser fixtures exercise pasted links, target-local login/registration, expired sessions and home/foreign call moves. Hosted release and physical platform acceptance remain separate evidence.

D-065 server unit tests cover navigation projection scope, cross-room privacy, admission/revocation, voice expiry/movement, disabled accounts, exact public fields and legacy/invalid query handling under SPEC-012.

D-064 server units cover legacy defaults, Unicode normalization/length/control validation, clear, nonmember self-service, attempts to target another account or inject fields, unauthenticated/revoked requests, concurrent revision conflict, idempotent replay, restart persistence, other-room visibility and unchanged media/permission/key authority.

P-028 server tests cover descriptor schema/info agreement, unchanged account authority after hostname discovery, invalid configuration, startup-domain mismatch, route-prefix boundaries and isolated stores/secrets for two instances. Public metadata cannot contain secrets or private membership/policy lists. A-40 includes the website route and wrong-domain credential cases.

The Cloudflare gateway applies the SPEC-002 inactivity timeout once after Container start and restores it when a Durable Object instance resumes an already-running Container. Concurrent setup shares one pending operation; a failed setup is retryable. Ordinary authenticated requests count as Durable Object activity and do not reconfigure the platform timeout on every lease. This keeps management-plane latency outside established voice renewal while preserving the inactivity and absolute-generation bounds. Unit coverage checks startup, restart restoration, concurrent deduplication and setup failure, plus unchanged forwarding and expiry behavior.

For D-052, unit-test grant/deny/revoke, administrator hierarchy, disabled targets, token invalidation, stale revisions and idempotent retries. Adapter integration verifies setup closure for GET/HEAD before and after bootstrap. Existing sessions and device identities survive restart. See A-38; SPEC-005 owns invitation parsing and UI tests.

Website unit tests cover independent Android APK/Windows installer/portable ZIP/Linux archive/Flatpak manifest selection and metadata, full/HEAD/conditional/ranged downloads, all range boundaries, unknown keys/methods, missing/mismatched objects, storage failures, header handling, apex redirects and static security headers. Integration tests run against local Workers/R2, then verify the live release SHA-256 and length and a ranged HTTP response. D-061 additionally exercises an actual Portage fetch of the Linux object from an empty cache. A page deployment alone does not establish that the installer is publicly downloadable.

For the successor, unit-test identical account permissions from three device sessions, stale capability rejection, per-device versus account-wide revocation, pending-device denial, link/recovery races, simultaneous voice moves and crash/retry recovery. An unavailable relay must never let an ambiguous source cutoff produce a target grant. Ensure backups cannot restore old roles, memberships or revoked devices. These are planned feature tests.

Cloudflare adapter units cover preparation deduplication, attempt limits, expiry and cancellation races; current membership/device rechecks after provider work; consumed-ID replay; current-generation validation; declared RPC error preservation and unexpected-error redaction; failed issuance, redirect rejection, absolute closure and stop-during-startup. Use fake clocks/providers for exact boundaries. Hosted application tests separately exercise real Workers RPC and Container networking.

For D-040/D-216, test Cloudflare control namespace selection for omitted, EU and US settings, media placement for EU and US only, and the D-217 SPEC-002 control migration; reject empty, null and unsupported settings before object access. Verify the hosted request reports the selected object's jurisdiction; the local Miniflare/workerd fixture uses unrestricted storage and cannot establish restricted placement. A mismatched object must reject requests and stop recurring alarms without deleting stored data. Placement configuration is owned by SPEC-002 and is not an administrative client permission.

D-034's separate Cloudflare probe imports the V1 relay permission boundary and adds only the test routing, credential validation and lifetime controls specified in the media review. It does not create accounts or grant production room authority. Test invalid configuration and unauthenticated startup, absolute shutdown, explicit stop, relay-only ICE negotiation and unchanged per-packet lease/revision enforcement. Provider connectivity requires the separate hosted run.

Unit tests for server command handlers, permission evaluation, capability projection, administration and orchestration should cover:

  • Request authentication/version/schema failure occurs before mutation; foreign identity claims are scoped to their issuing authority and target resource.
  • Each approved role/override/inheritance rule, explicit denial, foreign account grant, last-owner protection, and privilege-escalation attempt produces the specified effective result.
  • Capability responses match the evaluator's current outcome and revision without exposing hidden resources or secret policy; a stale cached grant never authorises a now-forbidden action.
  • Settings mutations handle valid changes, invalid types/ranges, inherited restrictions, revision conflicts, duplicate requests and persistence failure; outcomes reflect actual commit/propagation state.
  • Administrative actions select the correct room/participant/devices and generate safe audit entries; any future optional bot classification never changes authorisation by itself.
  • Hard-mute/removal orchestration revokes existing grants and prevents re-publication, handles adapter failure/retry, and does not falsely report enforcement before the approved completion condition.
  • Post-commit timeout/restart and duplicate delivery preserve idempotent effects and authoritative state; read caches do not become a room host.
  • Missing/invalid configuration and secrets cause explicit errors with redaction; no fallback to a public reference account, endpoint, default password or plaintext direct communication occurs.
  • Encrypted payload routing does not require plaintext access, and retention/permission checks use the approved outer metadata contract.
  • Accepted/pending/effective/failed/superseded transitions, partial revocation, duplicate or late callbacks, expiry of established paths, and newer unmute revisions; stale responses cannot roll back policy or manufacture completion.
  • Durable work survives crashes between commit/dispatch/adapter response; result-query authorisation, altered-payload retries and expired commands cannot produce a second effect.
  • Historical evidence is bound to the correct actor, operation and revision; evidence projection does not reveal encrypted object data or require client role evaluation.
  • Fixed room modes/access bundles, membership-interval history filters, administrator-only account invitations, second-active-device rejection and restored-authority closure.

Use fake clocks, persistence/media adapters and caller identities for these units. Reuse the shared-spec tests for their owned algorithms. Real federation, persistent storage, Workers execution, media relay enforcement, restore and deployment independence require integration/acceptance runs.

Acceptance criteria

  • D-227/D-228: the applicable SPEC-028 library, logical ownership, default projection and publication acceptance conditions pass; no logical-server media/client-navigation capability is claimed.
  • D-226: server-context invitation commands work on an empty host, enforce owner authority and current revisions, preserve exact retries/cancellation, and grant only the SPEC-022 inherited server access after account creation or verified named admission.
  • D-221: every SPEC-027 acceptance criterion passes on the Node and workerd adapters; hints are published only for committed changes (a failed write or rolled-back transaction publishes nothing) and are dispatched independently of drain lanes and blocked background work.
  • D-221: hint evaluation reads only the changed records and per-account readability for changed rooms; it performs no per-request scan of history or of all rooms.
  • D-221: with N connected socket identities, a protected request whose Service.prune() deletes nothing causes zero socket authority rechecks, zero flushes and zero frames on Node and workerd adapters; a prune that deletes a session still closes that session's socket with 4401 before any further frame.
  • D-221: deleting a channel the account could read (watched or not) produces one structural sync for that account after commit; an unrelated, private-nonmember or unjoined account receives no frame, and a rolled-back deletion or a recipient whose session is revoked before the flush receives none.
  • D-221: hosted acceptance: both testing services report the target version for configured allocation and observed tagged invocations and pass a live upgrade, auto-pong and hint check through the Durable Object with disposable fixture accounts; live socket survival or recovery across eviction and deployment is observed rather than inferred from local reconstruction.
  • D-220: only native media POST /lease stubs specify retry.timeoutMs=2000; maxRetries stays omitted, other operations retain runtime defaults, and no mutation is marked safe for repeated execution.
  • D-220: validation records retry deadlines, duplicate suppression and rejection of expired grants without Container forwarding; the initial attempt may exceed two seconds. The human’s 2026-11-07 follow-up explicitly authorizes the testing rollout with distributed pre-dispatch timing unverified; retain that limitation as open evidence. Deployment reports distinguish configured allocation, observed traffic and live object checks; no measured latency/cost improvement is claimed.
  • Council performance increment: at legal retained size, protected-request maintenance row work is independent of unrelated history (workerd rowsRead), thread liveness and eligibility plans contain no SCAN messages, and mass thread retirement deletes enforcement in one statement.
  • Council performance increment: a send that would exceed 67108864 stored UTF-8 bytes returns storage_full and stores nothing, including with multibyte readable history; exact-limit sends are accepted; identical replay at full quota returns its original sequence.
  • Council performance increment: a blocked managed-SFU provider request never delays dispatch of a newer revocation from any trigger, and the pending-enforcement alarm interval stays one second from alarm start; no concurrent duplicate enforcement pass occurs.
  • Council performance increment: preparation never returns caller credentials unless the final physical health/boot check after issuance succeeds; join-time generation validation is unchanged.
  • D-209: an unconfigured service omits bug-reports/1 and refuses posting without outbound requests; a configured service creates exactly one GitHub issue per report identifier, enforces 5/account/hour and 20/server/day before contacting GitHub, and never exposes the token, as specified in SPEC-026.
  • D-172: current and future admitted channel members receive the moderator-approved pin; encrypted copying is automatic, independently authenticated and bounded by original retention/current membership, with explicit offline-holder waiting. Surrounding history and thread eligibility remain unchanged.
  • Only the local server owner can publish/clear a bounded availability/update notice or read server-wide connection aggregates.
  • Numeric reports replace the same device record, enforce the one-second minimum, expire after thirty seconds, and never expose raw reports through aggregate reads.
  • Public listings require owner opt-in, public visitors and current verified discovery; withdrawn/unreachable listings do not appear in search.
  • D-171: both QR initiation paths enforce SPEC-011’s exact target/request/roster checks and bounds; no scan or anonymous rendezvous grants account authority, cancellation is not revived by retries, and the authoritative deadline never exceeds five minutes despite client clock skew.
  • D-170: the exact public APK route streams manifest-matching content with APK MIME type, attachment, length/SHA-256 and working HEAD/conditional/range behavior; unknown/missing/mismatched objects retain fail-closed handling.
  • D-138: recursive deletion rejects non-owners and stale confirmations, removes the selected channel data transactionally, preserves independent accounts/channels and bounds media revocation. The Lobby stays deleted after restart and owner creation works on an empty server.
  • Screen-sharing delivery enforces R-117/R-118/R-120 under SPEC-023/A-49, with no channel-admin escalation, P2P permission bypass, over-limit relay fallback, cross-conversation disclosure or audio-role mute bypass. Proposed limits/wire/migration choices must be resolved and tested before advertising capability.
  • D-103/A-42 passes for local and real workerd fixtures; schema migration preserves existing session deadlines, and early renewal does not change live attendance or room revision.
  • Complete the applicable PTT inheritance, profile picture and audio cue acceptance criteria in SPEC-004/012/019/020.
  • D-084: old media clients receive upgrade-required responses, updated Opus calls pass in both encryption modes, and relay mode/room/revision/lease enforcement remains intact.
  • The D-065 navigation projection passes SPEC-012 privacy/expiry cases without granting admission or exposing keys, hidden rooms or unjoined-room rosters.
  • An authenticated account can update only its own nickname; an old approved client reads compatible identities and omitted profile fields retain legacy defaults.
  • Duplicate profile commands apply once; stale profile revisions cannot overwrite newer names; profile changes preserve room revisions, permissions, membership history, devices and active voice.
  • A-38 passes for the D-052 workflow without changing existing owner credentials or sessions.
  • D-051 serves the exact manifest-listed alpha.3 installer over public HTTPS, with a matching SHA-256, correct attachment/HEAD/range responses and no public upload or bucket-listing route. The website uses a separate Worker without application authority bindings.
  • The successor passes A-33/A-35/A-36 with direct API clients as well as official UI clients: common account rights, distinct device sessions, bounded revocation and a single active voice client survive races, failures and retries.
  • Run the server on Workers with the selected managed media adapter and demonstrate one-domain room text/voice for the initial cohort without relying on process-local state for acknowledged events.
  • Run the second domain with independent identities/configuration; users participate in either host's rooms without duplicate login accounts, while forged foreign administrator claims are rejected. See A-02.
  • Exercise permitted and denied ordinary/admin operations directly through the protocol; bypassing client controls grants no additional access, and effective capability responses match the server's decisions. See A-11.
  • Submit two administrative updates against the same revision and observe one accepted state plus a stale-revision conflict; inspect the authorised audit record and applied/propagation result.
  • Hard-mute a participant already publishing from every supported device and verify all audio forwarding stops within the approved bound, video may continue, audio re-publication stays denied, and lifting mute does not start capture. V1 runs the single-device case; D-046 adds account-wide mute during handover and rejection of simultaneous publishing from signed-in devices. Two authorised publishers would require a later policy change. Repeat for each supported adapter and exercise partial failure/control partition. See A-10/A-29.
  • Exchange encrypted direct content and content in a room explicitly configured as E2EE while inspecting server storage/logs and available secrets; no participant plaintext/content keys are exposed by routing, administrative privilege or diagnostics. A private room explicitly created as server-readable is not an E2EE test fixture. See A-05/A-16.
  • Restart the control service and retry an acknowledged operation; preserve its durable result and avoid duplicate effects. Exercise quota/retention and grant-expiry behaviour using the approved configuration. See A-15.
  • Demonstrate self-hosted media and the agreed alternative control deployment with applicable conformance cases and documented bootstrap/backup/upgrade/recovery before claiming full independent operation. See A-03/A-19.
  • Compare server configuration code with this section and its canonical linked inventories; every implemented property/default is documented, relevant OPEN decisions are resolved, and client-local preferences are not silently enforced as server settings.
  • Retry after an ambiguous committed mutation and recover its actual result without a second effect; restore a snapshot taken before revocation and demonstrate current-authority recovery or closure of the affected scope. See A-15/A-30.

D-063 audit completion

Implement the batched read contract in SPEC-012 without broadening authorization. Enforcement delivery is single-flight across room services sharing a store; only an integer relay revision at least the requested revision is an acknowledgement. An older delivery cannot overwrite effective/superseded state. The hard deadline remains authoritative even when acknowledgement fails. Reuse verified device authority only under SPEC-011 cache constraints.

Background alarm scheduling retains an earlier durable deadline instead of overwriting it on every read. Outstanding enforcement schedules within the existing one-second retry cadence; otherwise maintenance uses the existing 60-second cadence. Alarm callbacks recover the persisted schedule so a newly queued revocation is never postponed by older maintenance work.

D-063 member management adds pending account invitation metadata to the authorized account listing. Return only unexpired, unused account invites; the owner can see/cancel all, admitted moderators only their own. Store issuer account ID when issuing a new account invitation; legacy invites without that field are owner-only. Never return bearer tokens in the listing. The revision-checked, idempotent account.invite.cancel command accepts exactly an invitation id, verifies this policy and removes the unused invite. Replaying its creation command cannot recreate a cancelled invite. Cancellation does not modify an account, channel access or history. The existing 24-hour lifetime and quota remain unchanged.

D-065 navigation projection

Implement SPEC-012 room-tree/1 within the existing authorized synchronization response. Re-evaluate each room's visibility and the caller's current admission before projecting active voice members; an owner or moderator role alone does not reveal the roster of an unjoined private room. Exclude disabled/unadmitted participants and expired or different-room voice sessions. Return only the documented presentation fields. This projection grants no content access or command authority and does not change membership or voice. Use one bounded voice-record read per synchronization rather than introducing per-room network polling.

Opus admission and relay compatibility (D-084)

Apply SPEC-009's voice-opus/1 capability requirement to voice preparation, joining and lease renewal in every encryption mode. Advertise it in room state. This changes no permissions, visitor/registration setting, placement or persistence. Relay instances require the updated channel label and signed readable audio envelope; encrypted payloads remain opaque. Existing lease/quota/revocation bounds still apply. Tests reject old/missing capabilities and old/malformed readable packets, then exercise valid Opus forwarding in both modes. Acceptance requires a coordinated client/control/relay update and explicit refresh/rejoin, without downgrading encryption or restoring stale sessions.

Voice troubleshooting (D-099)

Emit allowlisted control and media lifecycle/failure events under SPEC-021. This component owns admission/removal, expiry, gateway forwarding and generation observations. Logging must not change permission, lease or cleanup behavior; the shared contract owns limits, configuration, validation and acceptance.

Hosted increment evidence, 2026-11-07: the final rollout sample records 100% configured allocation and target-version observations for both controls (10/10 each) and media services (7/7 each), including Domain and CloudMedia execution. Hosted lifecycle checks observe deployment disconnection and shared-client recovery on both services, with new-version Domain construction observed on the secondary. Deliberately delayed ticket reacquisition demonstrates polling recovery before socket reconnection; one secondary transient read failure during deployment is retained in evidence. Quiet sockets survive and continue authenticated hints, but natural idle eviction is not established. Both changed Container images were separately observed running during actual preparation. These bounded checks do not establish global traffic analytics, hosted acoustic latency or a new forwarding-revocation measurement.