OSL: intended full product specification

This document specifies the product OSL is intended to be. It does not certify the current build. “Must” states a product requirement; “current implementation” states what the canonical integration/full code contains at commit 2b971038d1c89dfeb07b7048f8ed5743fb3b8448. Authority is applied in this order: owner rulings, rendered pages in design/UI-FINAL-INSTRUCTIONS, numbered tasks, then canonical code. Synthetic names, messages, counts, addresses, recovery words, and prices in design previews are not product facts. [RULING D10; RULING D26; RULING D29; RULING D45(c)]

1. What OSL is

In one paragraph

OSL is a Windows privacy client that lets two verified OSL identities exchange end-to-end encrypted messages either through OSL’s own native messenger or through an ordinary conversation in a supported carrier such as Discord, Telegram, Signal, WhatsApp, Instagram, Messenger, Gmail, Outlook, Proton Mail, Yahoo Mail, AOL Mail, or iCloud Mail. On an external carrier, OSL encrypts the private payload, stores only encrypted material at its relay, represents the retrieval pointer as ordinary-looking cover text, places that cover in the already selected carrier conversation, and locally replaces a recognized protected row with the decrypted message when the recipient chooses to reveal it. The carrier still carries and retains an ordinary message and still sees its own account, recipient, size, and timing metadata; OSL does not turn the carrier into an anonymous network. OSL also provides native encrypted DMs, groups, Enclaves, files and community features, plus attended discovery and user-confirmed removal of exposed messages through Scrub. [TASK 0070; TASK 0071; TASK 7760; DESIGN: Strip.dc.html; DESIGN: OSLChats.dc.html; DESIGN: Scrub.dc.html; RULING D17; RULING D17(a)]

In one page

An OSL account is a local cryptographic identity with a globally unique public name used for discovery and up to two synchronized devices in this release. People become trusted peers by exchanging an OSL code or safety number and verifying it out of band. A 60-digit safety number is displayed in twelve groups of five and can also be compared by QR code. A changed identity key is a loud, blocking trust event, not a silently accepted replacement. The relay may know the public name needed to route discovery, but profile details that vary by friend, group, or Enclave are encrypted to that scope. [DESIGN: Owned Confirmation Verify.dc.html; DESIGN: People Key Change.dc.html; RULING 13, 2026-08-09; RULING D12; RULING D17]

OSL supports two transport families. OSL Chats is the first-party encrypted messenger: it sends protected payloads directly through OSL infrastructure and therefore needs no carrier disguise, strip lock, or reveal theatre. External-carrier mode uses a live conversation the person already opened. OSL proves the app, account, and selected conversation; prepares an authenticated encrypted payload; puts the encrypted object at the relay; turns its retrieval reference into ordinary-looking words; inserts those words into the carrier’s composer without exposing the private text; reads the stored carrier output back; and records success only after the carrier-specific proof succeeds. Ambiguous account, room, composer, output, or recipient means a visible refusal with zero fallback plaintext. [TASK 7760; TASK 7780; DESIGN: Strip.dc.html; RULING D30; RULING D33]

Cover text is camouflage against automated service classification, not a claim that a human will find every generated message natural. The default encoder carries bits by word choice using correctly spelled ASCII words and single spaces; capitalization, deliberate misspelling, and spacing tricks are off unless a carrier-specific readback proves them safe. The human-naturalness target and the machine-classifier target are separate. The recorded classifier result was 100% detected, so the required machine-detection bar is specified but not established. The AI cover writer has a Linux/library test path, but the Windows release artifact does not contain that feature and must not advertise it. [RULING D33; RULING D33(a); RULING D37; RULING D66; TASK 0073]

The normal external-carrier experience is deliberately narrow. Home opens a carrier; the strip identifies the current scope and exposes lock/composer reach, local reveal, whitelist, view once, timer, burn, plan, and quick settings; one of exactly three chosen send triggers—Clipboard, Double Enter, or Single Enter—starts a send. The eye is a click-to-toggle local reveal control. OSL never silently sends an unprotected message when a protected transaction fails. Timers destroy OSL’s ability to decrypt on both endpoints; where the carrier permits it, the sender may additionally request deletion of the sender-owned carrier row, but carrier deletion is best effort and failure remains visible. [DESIGN: Home.dc.html; DESIGN: Strip.dc.html; DESIGN: Send Mode.dc.html; RULING D11; RULING D12; RULING D20; RULING D22]

OSL Chats supplies native DMs, groups of up to 20 people, and uncapped Enclaves. Its intended surface includes text, encrypted text attachments, files, reactions, replies, edits, pins, search, typing state, message timers, view once, voice, screen sharing, channels, threads, forums, events, stage voice, customizable roles, moderation, signed participant bots, profiles, stories, and chosen-audience posts. A bot that reads protected content is a participant to whom the relevant key is shared. AutoMod is local after decryption: it may withhold content and let an authorized person reveal it, but neither the relay nor a central moderator receives plaintext, reports, reputation data, or deletion power. [DESIGN: OSLChats.dc.html; DESIGN: OSLServers.dc.html; DESIGN: OSLFeed.dc.html; RULING D2; RULING D3; RULING D6; RULING D14; RULING D16; TASK 7780; TASK 7781; TASK 7783]

Scrub is a separate, attended cleanup tool. It reads only accounts, profiles, folders, and conversations the person explicitly authorizes; it does not read saved passwords or sign in for the person. Discovery can stream findings locally, stop, resume, and report truthful zero/error states. Deletion is always a separate per-message decision made after the exact provider message is shown. AutoScrub is scheduled discovery only: it may add a possible match to a review set and may never create or approve a delete action. [DESIGN: Scrub.dc.html; TASK 7784; TASK 6093; RULING D64(a)]

OSL is local-first. Retained local data remains encrypted, readable, and unmetered even when relay service is unavailable or the data pack is empty; expiry removes relay handover material, not the person’s local archive. Low Data mode does not park unsent messages at the relay: if the recipient is not reachable, the send refuses and remains local. Ordinary offline send also refuses immediately rather than creating a hidden background queue. [RULING D23; RULING D24]

V1 is Windows-only and ships without Authenticode signing. It must plainly warn about Unknown Publisher/SmartScreen, publish an independently verifiable signed release manifest, and disclose the exact tested Windows scale, app language, theme, browser zoom, and carrier versions. OSL’s updater payload has a separate minisign integrity signature; that does not make the executable Windows-signed. Paid capacity is sold as data packs—Starter $2.99/5 GB, Standard $5.99/50 GB, Archive $11.99/150 GB—with no paid daily message cap; the Free tier keeps its cap. The live end-to-end cost measurement required before selling these packs has not been completed. [RULING D57; TASK 1603; CODE: integration/full:docs/release/code-signing-decision.md; TASK 7794]

2. Threat model

What OSL protects

OSL protects message content against the external carrier and against an OSL relay that behaves as designed. The carrier receives cover text rather than private plaintext; the relay receives encrypted objects and routing material rather than private plaintext; the recipient accepts a payload only after authenticating its sender, intended identities, scope, conversation, service, sequence, expiry, and message identifier. Scope-bound encryption prevents an identical profile or payload ciphertext from becoming a cross-scope correlation tag. [TASK 0071; TASK 6090; TASK 6091; TASK 6092; CODE: integration/full:apps/osl-hub/src/broker.rs; RULING D17(a)]

OSL protects against accidental plaintext sends by refusing whenever it cannot prove the selected carrier account, conversation, composer, stored output, or recipient. It protects against silently trusting a replaced identity key by requiring safety-number review. It protects expired and view-once payloads by deleting or consuming the decryption authority on both OSL endpoints, subject to the endpoint limitations below. It protects old messages from a later copied device when “old messages stay locked forever” is selected, which is the default. [TASK 6888; TASK 7760; DESIGN: People Key Change.dc.html; RULING D20; RULING D40; DESIGN: Old Messages.dc.html; CODE: integration/full:apps/osl-hub-ui/src/first-run-spine.ts]

OSL’s native service must not centrally moderate private plaintext. Enclave owners may set local rules, roles, AutoMod patterns, and bot membership, but enforcement that needs content occurs after authorized decryption on a participant device. New-member history is an explicit current-member re-share encrypted under the current epoch; the service keeps no old group keys. [RULING D14; RULING D18; RULING D18(a)]

What OSL explicitly does not protect against

• OSL does not hide that a carrier account contacted another carrier account, when it happened, how much carrier text moved, or the surrounding social graph. The OSL relay sees the globally unique public name needed for discovery; size and timing remain observable even when profile fields are scope-encrypted. Tor can hide a direct network path from the OSL service, but it does not erase carrier metadata. [RULING D17; RULING D17(a); DESIGN: Connection Choice.dc.html]

• OSL does not protect plaintext from the sender, the intended recipient, malware or an attacker controlling either endpoint, a participant or bot that was deliberately given the relevant key, screenshots, a camera, screen sharing, or a modified client that records content before an expiry action. Capture protection is requested where available but never treated as proof that capture is impossible. [RULING D3; RULING D20; RULING D48; DESIGN: Strip.dc.html]

• Cover text is not steganographic invisibility to people. A human may notice odd wording, and the current recorded classifier result fails the specified machine-detection target. Carrier transformations are handled by readback, error correction, self-repair, or refusal—not by claiming they cannot occur. [RULING D33; RULING D33(a); RULING D37; TASK 0073]

• OSL cannot remove an ordinary email from somebody else’s mailbox. A timer destroys the OSL key on both devices; the cover email remains at the provider until that mailbox owner removes it. Scrub may remove only the person’s own selected provider copy. [RULING D20; RULING D22; RULING D25]

• Disconnecting a carrier removes OSL’s local credentials, tokens, account mapping, cached geometry/appearance data, and cover pointers for that connection; it cannot retract carrier messages already sent or records the carrier independently retains. [RULING Q3]

• Free attachments are encrypted at rest but are not end-to-end opaque to the OSL service; the operator may be able to access them. Client-only attachment custody is a paid-tier requirement. No UI may call a Free attachment E2EE. [TASK 0044b; TASK 0641]

• OSL does not guarantee service availability, carrier compatibility after an unmeasured UI change, carrier-account safety from automation enforcement, or deletion success. It must visibly refuse on drift it cannot repair. Scrub consent must say OSL controls the app and reads messages, this may break the provider’s rules, the account may be suspended or banned, the feature can be turned off, and OSL cannot remove that risk. [RULING “SELF-HEALING IS UNIVERSAL,” 2026-08-09; RULING D22; RULING D64(a)]

• OSL does not recover an account after every device and the current recovery kit are lost. That loss is permanent and tombstones the public name. A recovery kit restores identity, public name, friends, and future receiving, but not message history. [TASK 5193]

• OSL has no completed independent cryptographic or security review and must not claim one. The early release is single-region, best-effort infrastructure with daily backups and tested restore, not an enterprise availability promise. [RULING T5; RULING Q6]

3. The engine

Identity, trust, and keys

Each device holds an OSL identity and device keys. A peer relationship is approved only after an OSL identity exchange and safety-number verification. Conversation and membership state select the service, carrier account, peer or group, and scope used by encryption. Direct-message cover detection is derived from a bilateral secret and the authenticated scope, so ordinary text can be rejected locally without asking the relay to classify it. [DESIGN: Owned Confirmation Verify.dc.html; TASK 0071; CODE: integration/full:apps/osl-hub/src/broker.rs; CODE: integration/full:crates/ipc/src/prose_token.rs]

The intended direct-message payload binds at least the message identifier, sender and recipient OSL identities, service, carrier conversation, scope commitment, send sequence, creation and expiry times, view-once/capture policy, and chunk metadata. The canonical code currently encrypts a fresh AES-256-GCM body key, wraps that key separately for sender and recipient using X25519 plus ML-KEM-768-derived material, and authenticates the envelope; these algorithms describe the current implementation, not a higher-authority promise that may be changed only by migration. [CODE: integration/full:apps/osl-hub/src/broker.rs; CODE: integration/full:crates/ipc/src/wire_v2.rs]

Sending a protected message

1. The person opens or selects the destination and enters the private text or attachments in OSL’s protected composer. OSL establishes the exact carrier executable or browser profile, carrier account, conversation, and recipient scope. It does not infer a nearby composer when two candidates are plausible. [TASK 7760; DESIGN: Strip.dc.html]

2. Local policy is applied: verified/whitelisted sender rules, metadata checks, old-message policy, view once, expiry, attachment limits, and the selected send trigger. Refusal at this stage produces no carrier bytes. [DESIGN: Send Checks.dc.html; DESIGN: Send Mode.dc.html; TASK 6888]

3. OSL serializes and authenticates the private payload, encrypts it to the intended recipient or scope, and retains the sender copy needed for local history. Files use distinct content keys. Free permits up to 16 files, 25 MB each; Pro permits up to 16 files, 1 GB each. A “plaintext attachment” is an encrypted attachment whose content type is text, never an unencrypted carrier attachment. [TASK 0044; RULING D6]

4. The encrypted object is uploaded under an opaque retrieval reference. The intended pointer design uses an 80-bit pointer derived from the bilateral key and authenticated context, carries no secret by itself, and never serializes the cover seed or a clear pointer. A bounded number of cover messages is allowed; if the payload cannot fit, the UI states the exact limit and refuses rather than truncating. [TASK 0070; TASK 0071; TASK 0081]

5. The pointer is encoded as ordinary-looking cover words. The default channel uses word choice only, with correctly spelled ASCII words and single spaces. The same private message encrypted in a different scope must not yield a reusable cross-scope ciphertext or cover marker. [RULING D33; RULING D17(a)]

6. A carrier job inserts the complete cover through a proven direct composer mechanism. It may use Windows UI Automation or a provider-owned DOM/API surface only when that surface is the one proved for the exact carrier version. It does not type character by character, does not use a hidden clipboard/Ctrl+V workspace, and never falls back to plaintext. [TASK 7760; RULING D31 as superseded by D54]

7. OSL reads back what the carrier actually stored, verifies the exact permitted transformation, and only then records the send. A mismatch invokes a carrier-specific repair if one has been proved; otherwise OSL visibly refuses. [RULING “SELF-HEALING IS UNIVERSAL,” 2026-08-09; TASK 7760; DESIGN: Strip.dc.html]

Finding and unpacking a received message

1. With the eye enabled for an approved scope, the receiver job watches only authorized accounts and conversations, using capped polling or carrier events. It ignores ordinary text, wrong pairs, unapproved scopes, ambiguous rows, unsupported versions, and rows that cannot be bound to an exact author and conversation. Eye-off stops protected-message polling. [TASK 3920–3929; TASK 3955–3960]

2. The local, scope-bound detector decides whether a row could contain an OSL token. Ordinary text returns “no token” without a relay fetch. A valid cover token yields the opaque retrieval reference. [TASK 0071; CODE: integration/full:crates/ipc/src/prose_token.rs]

3. OSL fetches the encrypted object, authenticates the expected signer and orientation, decrypts it locally, and validates all bound fields, expiry, sequence, and message identifier before marking the row protected. Gone, burned, expired, consumed view-once, wrong-version, and unavailable states remain distinct. [TASK 3980–3988; TASK 4010–4018; CODE: integration/full:apps/osl-hub/src/broker.rs]

4. The carrier row remains ordinary cover until the person clicks the eye. Reveal replaces or overlays that row locally; it does not edit the carrier’s stored message. Clicking the eye again hides it. A reply or forward is re-bound as a new protected transaction; copied or edited cover is accepted only if authentication and transformation rules still pass. [RULING D11; TASK 0921; TASK 0922; TASK 3953; TASK 3954]

Expiry, deletion, offline behavior, and storage

The relay expiry clock starts when the encrypted relay object is sent and deletes that object at expiry. A view-after-open clock starts only when the protected message is opened. The minimum disappearing interval is one minute and the maximum is 30 days. Key-only expiry is the default on every carrier; where the carrier permits it, the person may choose key plus best-effort deletion of the sender-owned carrier row. Email supports key-only expiry because a sender cannot delete the recipient’s email. [RULING D15; RULING D22; RULING D40]

Expiry destroys decryption authority on sender and recipient devices but does not delete retained local non-expiring data or promise erasure from screenshots, patched clients, backups outside OSL, or the external carrier. Free retention is seven days and Pro retention is 30 days; a downgraded file returns to the seven-day rule. [RULING D20; RULING D23; RULING Q4/Q5]

An ordinary offline send refuses immediately. Low Data mode additionally requires the recipient to be reachable because it parks nothing at the relay; no silent normal-mode fallback is allowed. A quiet-hours notification may be queued locally, but that is not a message-send queue. [RULING D24; RULING D57]

Current engine discrepancy

The intended task design separates a destination-derived pointer from fetch/delete authority. The canonical bridge instead Padmé-frames ciphertext, creates a fresh 96-bit seed, combines it with an eight-byte server identifier into a 160-bit carrier value, and derives one fetch token used as both fetch and management capability. Its receive holder therefore has deletion authority, and the bridge lacks the intended receipt endpoint. Multi-chunk canonical sends plan up to ten 40 KiB chunks and may route the protected result through OSL’s inbox rather than concatenate cover tokens. These are code facts, not the intended authority model; the capability split and carrier contract remain unproven until code and live proof agree. [TASK 0071; CODE: integration/full:crates/ipc/src/prose_token.rs; CODE: integration/full:apps/osl-hub/src/broker.rs]

4. Carrier specifications

Every carrier below uses the same invariant: prove service, signed-in account, exact destination, composer, stored output, and inbound author/row; insert directly through a proved mechanism; read back what the provider stored; decrypt locally; self-repair only a measured drift; otherwise refuse visibly. A checked task is a requirement/evidence record, not proof that the released program works. [TASK 7760; RULING D30]

Discord

Put. OSL attaches to the trusted Discord Windows client, identifies the selected DM, group DM, server channel, or thread, and anchors the OSL strip and protected composer to that live conversation. The selected send trigger starts pre-send checking; Send remains disabled until account, room, recipient policy, composer reach, cover placement, and stored readback pass. OSL inserts the completed cover as one operation and verifies the Discord row before declaring success. [TASK 0901–0922; TASK 6888; TASK 7761; DESIGN: Discord Overlay Checking.dc.html; DESIGN: Strip.dc.html]

Get. The Discord receive job watches the exact approved conversation, attributes a row to its author, locally detects and fetches protected content, authenticates it, and exposes it only through the eye overlay. Ordinary, wrong-pair, edited-beyond-recovery, ambiguous, missing, split, or out-of-order rows are not marked protected. [TASK 3921; TASK 3926; TASK 3953–3960; TASK 7761]

What differs. Discord is the reference surface for the nine-step strip coach: Lock, Composer, Reveal, View Once, Timer, Burn, Verified Senders, Your Plan, Quick Settings. Whitelist state is per scope; burn offers message/chat, app, or account scope subject to the sender-owned deletion rule. The strip must sit over the real signed-in Discord window and match the rendered design structurally. [TASK 6884; TASK 7964; RULING D7; DESIGN: Strip.dc.html]

Implementation evidence. TASK 7761 is checked, but canonical services.ts says Discord has never completed a recorded two-party carry-and-return run and has an open security finding. Canonical discord_release_gate.rs only validates a manually populated boolean evidence object and says its unit/loopback checks do not replace a signed Windows package plus two independent Discord identities. The current design was accepted only with earlier named behavioral fixes, and a checked task alone does not resolve those code claims. Discord is specified, but release readiness is unproven. [TASK 7761; CODE: integration/full:apps/osl-hub-ui/src/services.ts; CODE: integration/full:apps/osl-hub/src/discord_release_gate.rs; RULING D68]

Telegram

Put. OSL binds the Telegram desktop work directory/profile, signed-in account, and selected person or group. It uses the same chosen send trigger as every other carrier, inserts one complete cover message, rejects any route that would introduce a newline, and reads the stored Telegram row back before success. [RULING D12; RULING 20(a), 2026-08-09; TASK 7762]

Get. OSL watches only the bound chat, verifies the exact sender and row, decodes and authenticates protected content locally, and uses the same reveal, view-once, expiry, and sender-owned burn semantics as Discord. Composer carry by itself is not receipt or delivery. [TASK 7762; TASK 7762b]

What differs. The support catalog records a Telegram composer-carry receipt but no two-party delivery proof and simultaneously calls the surface externally blocked. The apparent TASK 7762 acceptance test builds its identities, work directories, rows, and actions in an in-memory fake host, not Telegram Desktop, so it does not establish that receipt against the carrier. The rendered design provides only a Telegram skin in Strip.dc.html, not provider-specific put/get mechanics. OSL therefore makes no current availability claim even though the intended lifecycle is complete. [CODE: integration/full:apps/osl-hub-ui/src/services.ts; CODE: integration/full:apps/osl-hub/tests/task_7762_telegram_protected_carrier.rs; DESIGN: Strip.dc.html; TASK 7762]

Signal

Put. OSL uses a separate Signal OSL profile so the person’s ordinary Signal session can remain open. A local protected sheet prepares the private message, then OSL must prove the target Signal account and conversation and drive the real composer through the screen-reading/UI Automation route. Any changed control or synthesized-input refusal triggers repair or a visible refusal, never clipboard insertion. [DESIGN: Service.dc.html; DESIGN: Local Protected Sheet Initial.dc.html; DESIGN: Local Protected Sheet Prepared.dc.html; DESIGN: Local Protected Sheet Ready.dc.html; TASK 7763]

Get. The Signal adapter must enumerate real rows in the selected conversation, bind author and conversation, recognize cover locally, fetch and decrypt it, and show the protected result in OSL’s local panel/eye state. Timers, view once, and burn retain the shared semantics. [TASK 7763; TASK 7763b]

What differs. Signal is organized around an isolated OSL profile and a local protected sheet rather than Discord’s in-place private panel. The Signal production tasks are open. Canonical services.ts says its adapter has never been driven against the live client and refuses the only synthesized-input technique known to land on other surfaces, so Signal must remain unavailable until a real two-identity send/readback/receive proof exists. [TASK 7763; TASK 7763b; CODE: integration/full:apps/osl-hub-ui/src/services.ts]

WhatsApp

Put. OSL captures a protected draft, proves the WhatsApp account/conversation, and must place the cover into the real message document—not merely the accessibility Value property—then read the actual document and sent row back. If placement fails, the overlay presents Retry and leaves the provider untouched. The selected send mode and clipboard rule remain universal. [DESIGN: WhatsApp Overlay Draft.dc.html; DESIGN: WhatsApp Overlay Error.dc.html; TASK 7764; RULING D54]

Get. The adapter must bind a real WhatsApp row to its author and conversation, recover the cover token, fetch and authenticate the object, and present the local reveal/timer/view-once/burn states. An empty overlay or captured draft is not evidence of delivery. [DESIGN: WhatsApp Overlay Empty.dc.html; TASK 7764b]

What differs. WhatsApp requires a visible cover-capacity budget. Package prose says 28/1000, while the rendered WhatsApp pages show no counter; the ruling requires a byte budget but the authoritative rendered value is therefore not established. Canonical evidence says an attempted write reached accessibility while the real message document stayed empty, so the safe current behavior is refusal. [RULING D12; DESIGN: README.md; DESIGN: rendered WhatsApp Overlay *.dc.html; CODE: integration/full:apps/osl-hub-ui/src/services.ts]

Instagram

Put. OSL’s Instagram surface is private Direct messaging only. It must identify the exact signed-in account and DM thread, insert into the real private composer, read the stored provider row back, and never substitute a post, story, comment, or an in-memory dispatch acknowledgement for delivery. [TASK 7766; TASK 7766b]

Get. OSL must read real Direct rows, bind author/thread, recognize and authenticate protected content, and apply the shared eye, timer, view-once, and sender-owned deletion rules. [TASK 7766; TASK 7766b]

What differs. Instagram has no carrier-specific rendered put/get page; Home and Settings only name it. Its production tasks are open, and canonical instagram_direct_message.rs is an abstract/in-memory inbox whose own contract says dispatch acceptance is not delivery. Instagram must be absent or visibly unavailable until live two-identity proof passes. [DESIGN: Home.dc.html; DESIGN: Settings.dc.html; TASK 7766; CODE: integration/full:apps/osl-hub/src/instagram_direct_message.rs]

Messenger

Put. OSL must attach to the real private Messenger composer for the exact account and thread, place and read back cover, and record success only after the provider row is proved. It may not treat a pending envelope in an internal queue as a sent message. [TASK 7767; TASK 7767b]

Get. OSL must enumerate real Messenger rows, bind author/thread, decode and authenticate protected content, and expose it through the local eye. Burn may delete only a row owned by the sender unless a separately proved provider capability says more. [TASK 7767; TASK 7767b; RULING D22]

What differs. Messenger has no carrier-specific rendered mechanics. Its production tasks are open, while canonical messenger_delivery.rs is explicitly a MessengerTestMachine with in-memory pending envelopes and private words. It is not a production carrier and cannot appear Ready. [DESIGN: Home.dc.html; TASK 7767; CODE: integration/full:apps/osl-hub/src/messenger_delivery.rs]

Gmail

Put. OSL uses an existing, explicitly selected signed-in Gmail browser profile. It proves the To/CC/BCC set and thread, writes cover directly into Gmail’s body editor without a hidden clipboard, reads the body back, and deliberately activates Gmail’s named Send control only after the OSL send trigger fires. The subject is never private content. Reply retains the proved recipients; forward warns that a non-OSL recipient will receive only cover; BCC is not silently propagated. [TASK 1200; TASK 1211; TASK 1217; TASK 1230; TASK 7768; TASK 7769; RULING D54]

Get. With explicit mailbox and folder/label consent, OSL lists capped Gmail thread rows, fetches only the text needed to classify/open a candidate, binds sender and recipients, and decrypts locally. It does not fetch unnecessary attachments or continue through an expired sign-in. A user-confirmed Scrub delete moves the sender-owned Gmail item to Trash/Bin; key expiry leaves the recipient’s ordinary email. [TASK 4336; TASK 5906; TASK 7769; RULING D25]

What differs. Gmail is browser-only in the specified roster and uses Gmail labels, threads, compose body, named Send, and Trash/Bin semantics. The rendered design has no Gmail-specific put/get page. The checked Gmail task therefore defines intent but does not prove a live adapter. [TASK 1230; TASK 7769; DESIGN: Home.dc.html]

Outlook

Put. Outlook is one provider with two selectable surfaces in Settings: Outlook on the web and the Windows desktop client. Each advertised surface must independently prove its signed-in profile, To/CC/BCC set, conversation, body editor, direct insertion, stored readback, and named Send action. Passing one surface does not promote the other. [DESIGN: Settings.dc.html; TASK 1236; TASK 1284; TASK 1285; TASK 7770]

Get. Web and desktop readers must independently list/fetch real messages, bind folders/conversations and author/recipients, decrypt locally, and perform only sender-owned, explicitly selected deletion. Key expiry never removes the other person’s email. [TASK 4337; TASK 4338; TASK 7770b; RULING D25]

What differs. Outlook is the only mail provider with an optional native Windows profile as well as a browser profile. Canonical services.ts says no Outlook desktop carrier is wired. The Outlook task expressly rejects opening a desktop window or fake page as proof, so desktop must remain unavailable and web is unproven until live receipts exist. [TASK 7770; CODE: integration/full:apps/osl-hub-ui/src/services.ts]

Proton Mail

Put. OSL attaches to an existing selected Proton Mail browser session, identifies Proton’s floating composer, recipients, body, and named Send control, inserts directly, and reads the stored provider content back before success. [TASK 1242; TASK 7768; TASK 7771]

Get. It lists/fetches consented Proton folders, labels, and threads, obtains only the needed text, binds sender/recipients, and decrypts locally. User-confirmed deletion uses Proton-specific provider actions; expiry remains key-only for the recipient copy. [TASK 4339; TASK 7771; RULING D25]

What differs. Proton requires provider-specific handling for the floating composer and its folder/label/thread model; a generic webmail fixture is not sufficient. Its task specifically requires replacing the in-memory boundary. No rendered Proton mechanics or live canonical provider adapter establishes that replacement. [TASK 1242; TASK 7771; DESIGN: Home.dc.html]

Yahoo Mail

Put. OSL uses the selected signed-in Yahoo browser profile, proves recipients and the real body composer, performs direct insertion, reads the result back, and activates Yahoo’s named Send only after the OSL trigger. Changed layouts use measured self-healing selectors or refusal. [TASK 1248; TASK 7768; TASK 7772]

Get. It lists/fetches only consented Yahoo folders and candidate rows, binds author/recipients, decrypts locally, and moves only explicitly selected sender-owned items to Trash. [TASK 4340; TASK 7772b]

What differs. Yahoo’s contract calls out self-healing selector changes and replacement of seeded snapshots with a real host. The rendered package contains no Yahoo-specific mechanics, and a checked task is not live-provider evidence. [TASK 7772; DESIGN: Home.dc.html]

AOL Mail

Put. OSL uses an existing selected AOL browser session, proves the recipient set and real composer, inserts directly, reads the exact author/body representation back, and presses AOL’s named Send control. [TASK 1255; TASK 7768; TASK 7773]

Get. It reads only consented AOL folders/rows, binds exact author and recipients, decrypts locally, and performs explicit sender-owned deletion through AOL’s real provider UI. [TASK 4341; TASK 7773b]

What differs. AOL requires replacement of the named AolFakePageFixture/in-memory boundary and carries the general automation-ban warning. No rendered AOL page specifies mechanics. Until real host evidence exists it is intended but unproven. [TASK 7773; RULING D64(a); DESIGN: Home.dc.html]

iCloud Mail

Put. OSL uses an existing selected iCloud browser profile, proves account, recipient set, conversation, composer, direct insertion, stored readback, and named Send. [TASK 1273; TASK 7768; TASK 7774]

Get. It lists/fetches only consented iCloud mailbox rows, binds sender/recipients, decrypts locally, and applies key-only expiry plus explicit sender-owned deletion. [TASK 4344; TASK 7774b; RULING D25]

What differs. iCloud requires two isolated live identities for end-to-end proof and must replace the SharedMailboxSnapshot fixture. Those production tasks are open because the second identity is unavailable. iCloud is therefore not established as a working V1 carrier. Home Empty.dc.html also omits iCloud while full Home.dc.html includes it; the full Home roster and six-provider ruling win. [TASK 7774; TASK 7792; DESIGN: Home.dc.html; DESIGN: Home Empty.dc.html; RULING D36]

Shared mail implementation discrepancy

The six-provider mail seam is specified for real, already signed-in WebView2/browser or Outlook desktop hosts. Canonical protected_mail_seam.rs instead keeps rows, keys, and receipts in BTreeMaps, synthesizes provider row identifiers, and uses an in-process pointer-sealing model. That is not a live Gmail, Outlook, Proton, Yahoo, AOL, or iCloud adapter. Accordingly, checked provider tasks describe intended acceptance bars, not proof that any mail lifecycle works in the current artifact. [TASK 7768; CODE: integration/full:apps/osl-hub/src/protected_mail_seam.rs]

5. End-to-end journeys

First run and onboarding: all 13 steps

Create Account/Welcome is the entry, not one of the 13 configuration steps. Returning users branch to Sign In, Restore Account, Forgot Password, Key Lost, or account recovery. A clean new account then follows exactly these 13 steps before Home: [DESIGN: Create Account.dc.html; CODE: integration/full:apps/osl-hub-ui/src/first-run-spine.ts; TASK 7752; TASK 7974]

1. Recovery kit. Generate and durably save the current identity and password recovery material; display the full loss/replacement warning before completion. [DESIGN: Recovery Kit.dc.html; TASK 5193]

2. Identity choice. Choose a searchable public identity or the non-searchable path. Public identity uses the ruled username rules; a one-use 24-hour invite link belongs later in Friends, not in onboarding. [DESIGN: 006-007.dc.html; RULING D47; RULING D53]

3. Passwords. Set and confirm the main password with a 12-character minimum and strength level 3; short legacy design copy is superseded. [DESIGN: Create Password.dc.html; RULING D12]

4. Burn password. Optionally set the separate destructive sign-in credential, with the exact ERASE acknowledgement and clear local-data consequence. The removed decoy behavior is not offered. [DESIGN: Burn Password.dc.html; RULING D1]

5. Pro. Redeem a Pro/voucher code or skip; success, checking, failure, and restart persistence are explicit states. [DESIGN: Pro Code.dc.html; DESIGN: Onboarding Pro Active.dc.html; TASK 7752]

6. Privacy/send checks. Choose local checks for unprotected messages, protected messages, and metadata handling. No hidden default is allowed. [DESIGN: Send Checks.dc.html; RULING D42]

7. Tor connection. Explicitly choose Tor or Direct; there is no preselected switch. The current task proof says Tor became the default after the required rerun, but the person still sees and can change the choice. Tor and OSL LAN are mutually exclusive with a visible reason. [DESIGN: Connection Choice.dc.html; RULING D42; TASK 4918; RULING 19, 2026-08-09]

8. Old-message defaults. Choose whether old messages stay locked forever or stay readable; locked forever is the ruled default and the standalone page is the accepted behavior. [DESIGN: Old Messages.dc.html; RULING D43; CODE: integration/full:apps/osl-hub-ui/src/first-run-spine.ts]

9. Sending behavior. Choose exactly one of Clipboard, Double Enter, or Single Enter. Nothing is preselected. Dangerous automatic triggers require explicit acknowledgement; “Manual” is not a fourth mode. [DESIGN: Send Mode.dc.html; RULING D12; RULING D50]

10. Cover insertion. Choose the Free insert-on-send behavior or the Pro natural-typing presentation, subject to carrier proof and refusal rules. [DESIGN: Cover Insertion.dc.html; TASK 7752]

11. Device cleanup. Immediately after Cover Insertion, choose local cleanup behavior for unsent private material and retained old messages. Deletion is confirmed and retained data remains encrypted. [DESIGN: Device Storage.dc.html; TASK 7974]

12. Browser import. Select individual supported browser profiles OSL may inspect; multiple profiles are a dropdown of separate choices, never blanket browser consent. Capability copy must list only profiles that can actually be inspected. [DESIGN: Onboarding Browser.dc.html; TASK 7970]

13. Detected apps. Show each supported native app as Detected or Not detected, with no “Ready/Needs claim” third state. The page remains in onboarding; the retired Install/apps route does not. [DESIGN: Onboarding Detected.dc.html; RULING D5; RULING D39; TASK 7752]

The rendered design package itself documents only an obsolete eight-screen order, while canonical FIRST_RUN_SPINE contains Welcome plus the 13 routes above and redirects retired Install, Apps, Tutorial, Decoy, Visibility, Mullvad, and separate Forward Secrecy routes. That code route list establishes the present intended order only because it agrees with later rulings/tasks; it is not proof that a packaged clean-profile run reaches Home. [DESIGN: README.md; CODE: integration/full:apps/osl-hub-ui/src/first-run-spine.ts; RULING D9; RULING D39; TASK 7752]

Sending through an external carrier

From Home, the person opens a carrier and its specific account/profile. OSL attaches only to the trusted executable or selected browser profile, proves the live scope, and opens the strip. The person writes privately in OSL, selects per-message view-once/timer options if needed, and invokes the chosen universal trigger. Pre-send checking disables Send until policy, recipient, composer, encryption, upload, cover insertion, and readback pass. Success means the exact provider row was read back; any uncertainty names the failed boundary and sends zero plaintext. [DESIGN: Home.dc.html; DESIGN: Strip.dc.html; TASK 6888; TASK 7760]

Clipboard mode means the person controls copying and pasting and OSL itself does not read or write the clipboard for the send. A separate user-pressed Copy control may copy the value the person knowingly chose. Double Enter and Single Enter may drive the proved carrier Send control only after their onboarding warning and only when the destination is certain. [DESIGN: Send Mode.dc.html; RULING D54; RULING D54(a)]

Receiving through an external carrier

OSL monitors only authorized accounts/scopes while the eye is enabled. It ignores ordinary text locally, resolves a recognized cover token, fetches the encrypted object, authenticates every binding, and marks the row protected only after decryption succeeds. Cover stays visible by default; clicking the eye reveals the private content locally and clicking again hides it. Expired, burned, unavailable, wrong-version, ambiguous, and missing states are shown honestly rather than converted to a generic failure. [TASK 3920–3929; TASK 3980–3988; TASK 4010–4018; RULING D11]

Home, friends, verification, and whitelisting

Home is a launcher, not a dashboard. It exposes OSL Chats, the available external carriers, Scrub, settings/account entry points, notifications, and Friends without restoring the retired sidebar. A tile is actionable only when the corresponding capability state allows it; an intended but unproved carrier remains absent or opens an honest unavailable state. Hidden-tile customization changes the launcher only, not whether a capability exists. [DESIGN: Home.dc.html; RULING “SIDEBAR REMOVED ENTIRELY,” 2026-08-09; TASK 7791]

In Friends, a person can search an exact public identity or generate a one-use contact link. The link expires after 24 hours, dies after one successful use, and can be replaced before use; it is generated here rather than during onboarding. After identity exchange, both people compare the 60-digit safety number or QR over an independent channel. Only a verified friend becomes eligible for protected direct messaging. A later key change removes the verified state and blocks protected sending until separate re-verification. [DESIGN: 006-007.dc.html; DESIGN: Friends Dialog Populated.dc.html; DESIGN: Owned Confirmation Verify.dc.html; RULING D47; RULING D53; RULING D12]

Whitelist permissions are then applied per service and exact conversation/scope. Selecting a friend row silently and reversibly toggles that permission, with an immediate visual state and no notification. A whitelist never overrides wrong-account, wrong-conversation, key-change, or cryptographic refusal. [RULING D7; DESIGN: Home.dc.html; TASK 3926]

OSL Chats

Home → OSL Chats opens the native messenger. DMs are between two people; groups contain at most 20; Enclaves have no product member cap and rekey with visible progress. Because OSL owns the composer and transport, there is no cover generation, carrier lock, composer reach check, or eye-reveal theatre. Native messages are encrypted, authenticated, persisted, searchable locally as policy permits, and support text, files, reactions, replies, edits, pins, typing, timers, view once, safety-number review, and blocking. [TASK 7780; TASK 7781; DESIGN: OSLChats.dc.html; RULING R1]

Enclaves add customizable roles, categories, text/voice channels, threads, forums, event RSVP, stage voice, membership/vetting, current-member history re-share, moderation, local AutoMod, bots, and one-way broadcasts. Profiles, stories, and posts are encrypted to their chosen audience; OSL does not make a post public. Story viewer identity defaults to named, may be changed to literal user, or hidden entirely, and that choice is not retroactive. [RULING D2; RULING D3; RULING D8; RULING D14; RULING D16; RULING D18; DESIGN: OSLChats.dc.html; DESIGN: OSLFeed.dc.html; DESIGN: OSLServers.dc.html]

The six rendered OSL Chats states were still too far left and not 1:1 in the latest review. TASKS 7780/7781/7783 are checked, but neither those ticks nor synthetic design interactions certify the native feature set in a packaged two-identity run. [RULING D68; TASK 7780; TASK 7781; TASK 7783; RULING D45(c)]

Discord strip and eye overlay

The strip is anchored to the carrier window, not a standalone default-position window. Its visible state includes current plan, quick settings, burn, whitelist, timer, view once, composer reach/lock, the single eye reveal control, and proof/readback state. The tutorial order is Lock, Composer, Reveal, View Once, Timer, Burn, Verified Senders, Your Plan, Quick Settings, and dismissal persists per carrier. [DESIGN: Strip.dc.html; TASK 6884; TASK 4501; TASK 7964]

The lock means whether OSL can reach and prove the composer; it is not a password-sealed strip. The eye is click-to-toggle, never hold-to-peek, and can reveal only a row already checked, authenticated, and decrypted. The overlay never captures input on the owner’s primary screen by default; any created Windows window must be explicitly placed on an allowed monitor under the operational placement rule, though that is an agent/testing constraint rather than an end-user feature. [RULING D11; TASK 0921; TASK 0922; DESIGN: Strip.dc.html; operational source: OSL-AUDITS/reference/AGENT-WINDOW-PLACEMENT.md]

Scrub and AutoScrub

Scrub begins with provider/account/profile/folder consent and the four-sentence automation warning. It reads messages through real provider readers without reading saved passwords or performing login, streams findings locally, shows readable-item and apparent-public-exposure counts, and lets the person stop before further work. Discovery deletes nothing. The person opens a finding, sees the exact provider message and scope, selects it, receives a destructive confirmation with real counts and consequences, and only then authorizes a provider-specific delete attempt. [DESIGN: Scrub.dc.html; DESIGN: Scrub Review Dialog Empty.dc.html; TASK 7784; RULING D64(a)]

AutoScrub is Pro scheduled discovery. Its exact disclosure is: “AutoScrub finds possible matches for review; it does not delete them automatically.” A classifier hit may add a review item and may never create, queue, authorize, or perform deletion. TASK 6093 supersedes all earlier tasks and the Scrub.dc.html phrase “Discovery + deletion, reviewed batches.” [TASK 6093; DESIGN: Scrub.dc.html]

Canonical UI still exposes find_and_delete/“Find and delete” language in autoscrub-deletion-permission.ts and says AutoScrub “can delete” in autoscrub-account-page.ts, although its base contract blocks unattended runs. That code and TASK 7785 conflict with TASK 6093 and must change; the intended product is find-only. [TASK 6093; TASK 7785; CODE: integration/full:apps/osl-hub-ui/src/autoscrub-deletion-permission.ts; CODE: integration/full:apps/osl-hub-ui/src/autoscrub-account-page.ts; CODE: integration/full:apps/osl-hub-ui/src/autoscrub-contract.ts]

Settings

Settings is one click-through page with nine current sections: Account, Apps, Privacy, Security, Whitelist, Notifications, Appearance, Window and sounds, and About. Account-state loading/locked/unavailable pages are states, not extra settings sections. OSL Chats settings opens as a region/modal within OSL Chats rather than a separate routed screen. [RULING D45(a); RULING D45(b); RULING D57; DESIGN: Settings.dc.html; DESIGN: Settings Account *.dc.html; RULING D46]

• Account manages public name and its 30-day change lock, private/discovery status, recovery kit, devices, Pro/voucher state, data usage, reset, and account burn. [DESIGN: Settings.dc.html; RULING D47]
• Apps selects native app profiles, browser profiles, and Outlook web/desktop without promoting an unproved surface. Disconnect removes local connection state but not already-sent carrier data. [DESIGN: Settings.dc.html; RULING Q3]
• Privacy controls discovery, friend/message requests, profile visibility, old-message forward secrecy, Tor/Direct, Low Data, cover behavior, send checks, and the three send triggers. Tor and OSL LAN cannot be enabled together. [DESIGN: Settings.dc.html; RULING D12; RULING D24]
• Security manages passwords, burn password, safety/reverification, devices, timer defaults, and local deletion policy. [DESIGN: Settings.dc.html; RULING D45(b)]
• Whitelist applies per-service and per-scope permissions. Clicking a row silently toggles it with an immediate clear visual state and no notification. [RULING D7; DESIGN: Settings.dc.html]
• Notifications controls local notification behavior; quiet hours queue notifications and release them afterward without queuing sends. [RULING D57; TASK 7990]
• Appearance uses only the approved visual system and live preview. [DESIGN: Settings.dc.html; visual bar in TASK 0118]
• Window and sounds ships with three reopen modes, four named sounds each with Preview, quiet-hours start/end, and Reset to defaults. [RULING D57; TASK 7988; TASK 7989; TASK 7990]
• About shows version, update, release limitations, unsigned status, compatibility tuple, and support/legal information without claiming unproved accessibility or security review. [DESIGN: Settings.dc.html; TASK 1603]

Mullvad is not an onboarding step. Settings may offer “connect Mullvad at startup” only if OSL can prove the installed Mullvad control actually works; otherwise it is absent or unavailable. [RULING D9]

Data packs and voucher purchase

The person selects one of the ruled data packs, chooses Card, BTC, or XMR, and receives a purchase result appropriate to that rail: card confirmation/failure, or cryptocurrency address/amount, confirmations, underpayment, and overpayment handling. The purchase produces an opaque, one-use voucher rather than account credit. The voucher is redeemed in a separate step and must not be linkable by OSL to the purchase; OSL stores no payment data. The UI discloses that Stripe knows the card payer, Bitcoin payments are public, Monero is private, and purchases are not refundable. [RULING “IN-APP PURCHASES: STRIPE, BITCOIN AND MONERO,” 2026-08-10; RULING 6 and 8, 2026-08-09; TASK 7796]

Redemption adds the purchased data allowance and never adds a paid daily message cap. A used voucher is permanently rejected. Empty, invalid, already-used, network-failed, and successful states are distinct, and payment success must not be inferred from a local UI model. The canonical code currently implements only in-memory purchase/redemption models and labels the packs “/month,” so this journey is intended but not established. [RULING D57; TASK 7796; CODE: integration/full:keyserver-cf/src/lib/approved-voucher-purchase.ts; CODE: integration/full:apps/osl-hub-ui/src/approved-voucher-purchase.ts]

Recovery, replacement, and destructive exits

The current recovery kit contains separate identity and password recovery material; the UI says both are needed. Forgot Password consumes password-recovery material and sets a new password. Restore Account consumes identity recovery material, accepts a kit file, and creates the successor local credentials. Key Lost is terminal on that device until recovery material is supplied. [DESIGN: Recovery Kit.dc.html; DESIGN: Forgot Password.dc.html; DESIGN: Restore Account.dc.html; DESIGN: Key Lost.dc.html]

Every time a kit is issued—during onboarding or recovery—the UI must say, before completion, that the new kit replaces the old kit, can replace lost devices, restores identity, public name, friends, and receiving but not message history, and that losing every device plus the current kit permanently destroys recovery and tombstones the public name. The actual kit must be flushed, reopened, and authenticated before acknowledgement. During recovery, the exact successor kit must be saved and verified before the signed authority transition; a failed pre-commit write leaves the predecessor usable, while a completed transition makes every predecessor invalid. [TASK 5193]

Canonical onboarding currently shows Copy/Download and “I saved my recovery kit,” but the required warning phrases and flush/reopen/auth sequence were not found in the canonical code audit. Its Copy handler also says clipboard is disabled, contrary to D54. Recovery is therefore fully specified but not established in the current artifact. [CODE: integration/full:apps/osl-hub-ui/src/main.ts; RULING D54; TASK 5193]

Personal export is a separate portability journey. Export creates an encrypted archive and names every deliberate exclusion. Importing that archive into a clean OSL install must yield a working account with content, attachments, settings, membership state, and sufficient device/recovery material; payment data and voucher state are explicitly excluded. Only the clean-install round trip establishes a valid export. [RULING T2]

Burn is separate from recovery. The optional burn password permanently erases local OSL data when used. Message/chat/app/account burn actions require a confirmation naming real affected counts, scope, what survives, and what cannot be undone. Requests to delete remote or offline copies are explicitly best effort; a third party cannot tombstone somebody else’s public identity. [DESIGN: Burn Password.dc.html; DESIGN: Burn Dialog Account.dc.html; DESIGN: Strip.dc.html; RULING T3; TASK 5193]

6. Product constraints and owner rulings

Visual and interaction bar

The shipping UI uses ground #080c0d and only six semantic accents: cyan #2ac0f0, safe #3dd68c, timer #f0b429, warning #f0a93a, Pro #a79bff, and danger #e05656. Corners are square or 0–3 px radius. Buttons are outlines and never become filled slabs. There are no shadows or gradients. Status labels are uppercase Consolas. Where current design pages use larger radii, filled cyan buttons, shadows, or gradients, this bar wins. [TASK 0118; TASK 0025; RULING D10]

Rendered geometry, structure, computed text, interaction state, and route behavior—not synthetic preview content—are compared to the correct design page before human review. Registered Windows chrome is excluded from design parity. A page with missing reference, wrong route, or wrong interaction fails rather than being judged “close.” The current parity verdict is structural/behavioral; pixel difference still ranks work but the withdrawn blanket sub-1% rule is not the sole acceptance bar. [RULING D26; RULING D27 as amended by D45(c); RULING D58]

Onboarding tasks must follow the current rendered UI and later owner edits rather than preserve an older plan sequence. Interim screen-review rulings record acceptance or named defects but do not relax behavior: D56, D62, and D67 are followed by the latest D68 review, while accepted pages remain regression-frozen under D55/D58. [RULING D4; RULING D55; RULING D56; RULING D58; RULING D62; RULING D67; RULING D68]

The product has no retired left sidebar, fake Inbox/People/Privacy/Activity/Connections navigation, tutorial-card carousel, Visibility onboarding page, or decoy workspace. Stealth opens an ordinary empty OSL workspace. States such as loading, empty, locked, checking, and unavailable are regions of their owning screen unless a ruling makes them a route. [RULING D1; RULING D9; RULING D12; RULING D41; RULING D46]

Clipboard and input

D54 and D54(a) supersede the absolute reading of D31 and the onboarding/app-usage distinction in D49. OSL may touch the clipboard only for a task the person directly chose and only with the value they expected—for example, pressing Copy on their own recovery or invite value. OSL may never use the clipboard as invisible workspace, may never place cover, synthesize Ctrl+V, and restore the old contents in the background, and in Clipboard send mode the person performs the copy/paste while OSL itself does not read or write. Canonical consensual-clipboard.ts still always returns unavailable and recovery Copy says disabled, so code reflects the obsolete absolute ban. [RULING D31; RULING D49; RULING D54; RULING D54(a); TASK 7977; CODE: integration/full:apps/osl-hub-ui/src/consensual-clipboard.ts]

Exactly three send modes exist: Clipboard, Double Enter, and Single Enter. No Manual mode or screenshot-detection switch exists, no mode is silently preselected, and the chosen trigger applies to every carrier. Capture protection is still requested; only the refusal screen that claimed it could guarantee protection was deleted. [RULING D12; RULING D42; RULING D48; RULING D50; RULING D55]

Messaging, identity, and community

The eye is a click toggle. Whitelist is a silent reversible per-scope toggle. Timers range from one minute to 30 days, have relay-send and after-open clocks, destroy decryption on both OSL devices, and offer sender-owned carrier deletion only as a visible best-effort option. Email always uses the exact key-only explanation approved in D25. [RULING D7; RULING D11; RULING D15; RULING D20; RULING D22; RULING D25; RULING D40]

The public name is globally unique and visible to the relay; other profile data is scope-encrypted. The final discovery design says a searchable public username is 3–30 lowercase letters/numbers, while earlier owner decision 11 records 1–16 letters/numbers/underscore. That unresolved authority-internal collision must be settled before validation ships; this specification does not invent a third rule. Username changes are locked for 30 days and may be made private. [RULING D17; RULING D47; RULING 11, 2026-08-09; DESIGN: 006-007.dc.html; RULING R4]

Roles are customizable, with Steward/Builder/Everyone only defaults. Bots are signed participants and receive keys for scopes they can read. AutoMod runs after local decryption and has no relay inspection, central reports, appeals, reputation, or central-delete path. Forums, events/RSVP, stage voice, profiles, posts, stories, beacons, voice, and custom roles are not cut merely because a screen was once missing; each must meet its own acceptance evidence. [RULING D2; RULING D3; RULING D14; RULING D16]

Story viewers are named by default, may choose anonymous literal user, or be omitted from the viewer list and count. Relay operators see none of these choices, and changes are not retroactive. New-member history is off by default, contains only post-epoch messages, and occurs through a current online member re-encrypting the allowed window under the current key; no old keys are retained. [RULING D8; RULING D18; RULING D18(a)]

Carrier honesty and cover

Every screen-driven carrier must detect behavioral and appearance drift, repair only a proved variant, and refuse visibly when identity, composer, stored output, or inbound row is uncertain. A carrier transformation is never declared impossible merely because one fixture preserved the text. Word-choice-only cover is the default; capitalization, spacing, and misspelling channels remain off until exact carrier readback proves them. [RULING D30; RULING D33; RULING D33(a); TASK 7760]

Wordbank cover is intended to reduce service-classifier detection, not fool every person. Human review has no numeric bar; the machine target is at most 50% detection, and the recorded 100% result is a failure. AI cover is not a Windows V1 feature because the Windows artifact lacks it. [RULING D37; RULING D66; TASK 0073]

Scrub safety

Scrub requires the four disclosures that OSL controls the app and reads messages, may break provider rules, may lead to suspension or banning, can be turned off, and cannot have that risk removed by OSL. Consent is account/profile/folder-specific. AutoScrub is FIND-ONLY and never auto-deletes; its classifier cannot authorize deletion under any name or schedule. The recovery-kit warning and write ordering in TASK 5193 are similarly non-skippable safety boundaries. [RULING D64(a); TASK 6093; TASK 5193]

Storage, performance, and service behavior

Relay expiry does not meter or erase readable local data. Low Data parks nothing in the cloud and refuses when the recipient is unreachable. The current performance targets are: 8 GB minimum target machine; no more than 750 MiB working set; 2-second cold start; 1% idle CPU; protected-key response typically within 100 ms and no worse than 250 ms provisionally; no more than 10% working-set growth over eight hours; no more than 5 GB local disk; and a provisional 30-minute ceiling for Scrub over 100,000 items. These are acceptance ceilings, not claims that current code meets them. D21’s earlier figures were withdrawn by D21(a); D44 is current. [RULING D21; RULING D21(a); RULING D23; RULING D24; RULING D44]

Integration evidence must come from one canonical integration/full tree that compiles/typechecks and executes the claimed paths. Grep-only tests, fixture-only pages, old artifacts, synthetic events, or a checked task do not establish a shipping feature. The local canonical branch, not the stale remote history or the dirty checkout branch, is the code authority. [RULING D19; RULING D29; RULING D32; RULING D34]

Packaging, pricing, payments, and release claims

This release ships unsigned under the owner decision dated 2026-07-31. It must say OSL is not Windows code-signed and may show Unknown Publisher/SmartScreen; publish the offline-signed manifest and verification commands; obtain the first-install public key through a separately authenticated channel; and include exactly the compatibility and unverified keyboard/screen-reader disclosures required by TASK 1603. Minisign update signing is not Authenticode. [CODE: integration/full:docs/release/code-signing-decision.md; TASK 1603]

Paid packs are data only: Starter $2.99/5 GB, Standard $5.99/50 GB, and Archive $11.99/150 GB. They have no daily message cap; Free retains its subsidy cap. No preview, lane, or code constant may substitute an invented price for this ladder. The estimated per-message cost came from code paths and must be measured in a real send/receive before sale. Canonical purchase/UI models wrongly label packs “/month” and use local/in-memory redemption models, so they do not establish real Card, BTC, or XMR rails. [RULING D28; RULING D57; TASK 7794; TASK 7796; CODE: integration/full:keyserver-cf/src/lib/approved-voucher-purchase.ts; CODE: integration/full:apps/osl-hub-ui/src/approved-voucher-purchase.ts]

The intended purchase model accepts card, BTC, and XMR for an opaque one-use voucher, keeps payment identity out of the OSL account, and discloses that Stripe sees card identity, Bitcoin is public, and Monero is private. Confirmation, failure, underpayment, overpayment, and no-refund behavior must be explicit. This is a specified journey, not a claim that processor or chain integrations exist. [RULING “IN-APP PURCHASES: STRIPE, BITCOIN AND MONERO,” 2026-08-10; RULING 8, 2026-08-09; TASK 7796]

Scope and operations

The shipping carrier roster contains Discord, Telegram, Signal, WhatsApp, Instagram, Messenger, Gmail, Outlook, Proton, Yahoo, AOL, and iCloud subject to live acceptance. GMX and mail.com are removed, and Tuta is not in the six-provider mail roster. Standalone OSL Mail is planned post-V1, not deleted. [RULING D35; RULING D36; RULING D9; TASK 5908]

V1 is Windows-only. Linux is a development/test harness; macOS and mobile clients are deferred. Malware scanning and quarantine remain required. The release operates one region with daily backups and tested restore on a best-effort basis, and all user-facing strings are externalized even though V1 ships English only. [RULING S1; RULING S2; RULING Q6; RULING Q7]

The five behavior-only routes—timed-delete scheduler, settings/schedule, auto-whitelist rules, friend, and behavior—ship without invented visual designs and must obey their functional contracts. Window and sounds and Security ship. discord-qa-shell never enters a release build. OSL-QA-1 is local Hyper-V test infrastructure, not a product feature. [RULING D13; RULING D45; RULING D57; RULING D65]

Owner test accounts may be used for private acceptance runs but must not message third parties or post publicly. Account readiness must be recorded fresh and automatically; stale credentials, old receipts, or synthetic identities cannot satisfy release proof. [RULING D38; RULING D59; RULING D63]

Rulings D60 and D61 govern agent capacity and the Clause G acceptance mechanism, not end-user behavior; they create no OSL feature. [RULING D60; RULING D61]

7. V1 boundary

Included in V1 by specification

• A Windows desktop client; account creation, sign-in, first-run 13-step onboarding, recovery, device replacement/revocation, Home, Friends, the carrier strip/eye, Settings, Scrub, and honest update/release-limit surfaces. [TASK 7752; TASK 5193; DESIGN: Home.dc.html; DESIGN: Settings.dc.html; DESIGN: Scrub.dc.html]
• Native OSL Chats DMs, groups, Enclaves, files, reactions, replies, edits, pins, search, typing, safety/key-change, blocking, voice/community features, profiles, stories, posts, beacons, bots, and local AutoMod, with the limits and trust model specified above. [RULING D14; RULING D16; TASK 7780; TASK 7781; TASK 7783]
• External-carrier contracts for Discord, Telegram, Signal, WhatsApp, Instagram private DMs, Messenger private messages, Gmail, Outlook web and desktop where separately proved, Proton, Yahoo, AOL, and iCloud. A carrier is included in the release UI as actionable only when its real two-identity insertion/readback/receive evidence matches the exact artifact; otherwise the same V1 specification requires honest unavailable/refusal state. [TASK 7760–7774; TASK 7791]
• Protected text and attachments, timers, view once, sender-owned best-effort carrier deletion where available, word-choice cover, readback/self-healing/refusal, Tor/Direct, Low Data, old-message forward secrecy, whitelists, and local safety checks. [RULING D6; RULING D20; RULING D22; RULING D24; RULING D33]
• Attended Scrub discovery plus explicit reviewed per-message deletion; scheduled AutoScrub find-only; data packs and voucher UX; unsigned distribution with independent manifest verification and precise compatibility limits. [TASK 7784; TASK 6093; RULING D57; TASK 1603]

Deliberately out of V1

• Standalone OSL Mail is post-V1 but remains planned. OSL Notes remains held. The six external mail carriers above are not the standalone OSL Mail product and remain within the V1 carrier specification. [RULING D9; TASK 5908]
• GMX, mail.com, and Tuta are outside the mail roster. [RULING D35; RULING D36]
• The X carrier is design-only for V1 under the higher-authority timer/carrier ruling and may not be promoted merely because later fixture/task work exists. [RULING D20; TASK 7765]
• AI-generated natural cover is absent from the Windows artifact; only its non-Windows/library test path exists. [RULING D66]
• macOS, Linux consumer release, mobile clients, and the Android isolated workspace are deferred. Linux remains a harness. [RULING S1; DESIGN: Connections.dc.html]
• Authenticode signing is deferred for this release. The app ships unsigned with explicit warnings and independent artifact verification. [CODE: integration/full:docs/release/code-signing-decision.md; TASK 1603]
• Enterprise SLOs, multiple-region availability, public social posting, central plaintext moderation, relay-held old group keys, automatic Scrub deletion, guaranteed screenshot prevention, guaranteed carrier-row deletion, and recovery without a device or current kit are explicitly not part of the product promise. [RULING D14; RULING D18; RULING D20; TASK 6093; TASK 5193; RULING Q6]

What is not yet established

The intended V1 boundary is broader than the evidence. TASK 7791 remains open and requires the same release artifact to satisfy all 61 product areas and every carrier receipt. Canonical status currently makes no Discord claim, records Telegram carry but not delivery, refuses Signal and WhatsApp, contains in-memory Instagram/Messenger and six-mail seams, lacks Outlook desktop, and has open Signal, Instagram, Messenger, and iCloud production tasks. AutoScrub copy violates FIND-ONLY; consensual Copy is disabled; the recovery warning/save ordering is not evident; pack UI says “/month”; the cover capability bridge differs from the intended authority split; and the classifier result misses its target. Therefore this document defines V1 but does not say a releasable V1 exists. [TASK 7791; TASK 7763; TASK 7766; TASK 7767; TASK 7774; TASK 6093; TASK 5193; RULING D37; CODE: canonical files cited in the corresponding sections]