Nook

Screenshots

Nook v0.4.0 #launch channel at 1600 pixels: a team conversation with an accepted request and a recorded decision, from the product screenshot named in RELEASE.json.

Outside services

The services the project declares it sends data to, each with its reason.

cloudflare

Local Worker/D1 emulator for feasibility; remote hosting is not configured

Scope and limits

What it will not do

• Hosted or pilot release claim from local evidence
• Provider effects or resource provisioning in this incubation

Declared limits

Status

unmeasured

Workspace Document Bytes

16,777,216

Cas Attempts

24

File Bytes

1,048,576

Attachments Per Message

5

Staged Per Uploader

50

Raw Workspace Media Bytes

16,777,216

Native Schema Version

4

Native Archive Version

4

Supported Root Archive Versions

1, 2, 3, 4

Maximum Root Ledger

6

Requirements

All 17 clauses of Nook’s CONTRACT.md. They say what the project must do; the handover and verification records say what is built and tested.

NOOK 15 clauses

1. NOOK-001
   Current identity and conversation membership (C1) Every private API validates current active identity and current conversation membership. Search/replay/outcomes use the same policy. Workspace admins cannot read arbitrary DMs. Acceptance evidence: Through signed-in HTTP, SSR, search, replay and generated loaders, revoke or expire a session and remove a participant; every subsequent private read/write is refused, including a workspace admin attempting another person’s DM.
2. NOOK-002
   Atomic messages, retries and replay (C2) Messages commit atomically with per-conversation event sequence and client intent key. Identical retries return the same message; changed retry payload conflicts. Replay pages preserve ordering; edits use compare-and-swap versions; deletes tombstone and erase original body from live revisions. Acceptance evidence: Send through the conversation API, repeat the same intent after a lost acknowledgement, then change its payload; observe one ordered message, the original retry result and a conflict for changed intent. Race edits and delete; replay shows current tombstones without deleted bodies.
3. NOOK-003
   Fixed DMs and channel membership (C3) DMs have fixed participants. Channel owners control membership. Removal revokes reads and writes immediately, including replay and search. New members currently see entire channel history; UI and docs must disclose this. Acceptance evidence: Create channel/private/DM conversations through the app, add a channel member after earlier messages, and observe full-history disclosure and access. Remove that member and deny history/search/replay/files immediately; refuse DM participant changes and unrelated-admin DM access.
4. NOOK-004
   Decisions and commitments (C4) A decision has a human author, conversation scope and immutable version history. Only its author revises it with version comparison. A commitment can become accepted only through the assignee's action. Completion is reported, never labelled verified. Acceptance evidence: From a discussion, record a decision and propose a commitment. Another participant cannot revise the decision or accept for the assignee; the assignee accepts the exact version and reports completion. Reopen history and see human authorship, source context and reported status.
5. NOOK-005
   Read cursors and attention (C5) Read cursors persist per user and conversation, are monotonic and cannot exceed durable frontier. Attention/unread is separate from accepted responsibility. Acceptance evidence: Read a thread from two sessions, reconnect one, and observe monotonic unread recovery with own sends excluded. Refuse read markers beyond the durable frontier; closing Attention does not accept work or mark unseen messages read.
6. NOOK-006
   Offline restore (C6) Restore is offline into an empty database with version and checksum verification and SQLite integrity checking. Current backups contain private content, never live sessions; password hashes belong only to explicitly supported legacy recovery inputs and never become new sign-in authority. No external effects on restore. Acceptance evidence: Use rer export/reset/import into an empty stopped installation, complete explicit identity recovery, and compare conversations, memberships, outcome versions, attention and downloaded file bytes. A populated destination, altered checksum or invalid graph is refused; no old delivery or session revives.
7. NOOK-007
   Safe rendering and local binding (C7) Human text renders inertly. No message, plugin, link or AI output can trigger arbitrary code, client-side or credentialed fetching, or provider effects; the only server-side link fetch is NOOK-068's bounded, SSRF-safe preview service. Authorized app/agent/meeting effects require the explicit scoped doors in NOOK-022–030 and NOOK-054–059, not ambient conversation authority. Bounded bodies, session expiry, origin validation for mutations and loopback-only development binding remain required; production requires HTTPS. New sign-in uses invited Base magic links; legacy password hashes remain offline recovery inputs only. Acceptance evidence: Post active markup and malformed/oversized bodies through public APIs; markup stays inert and invalid input fails without writes. Cross-origin mutations, foreign sessions and unsafe local origins fail; production output excludes dev admission.
8. NOOK-008
   Evidence limits (C8) The complete target in this contract remains an obligation until its acceptance evidence exists. Local tests, synthetic imports and substituted network edges establish only their bounded paths; hosted scale, legal/compliance operation, real inbox/device receipt, native push and live provider integrations require separate evidence. Missing proof changes the status, never the scope. Delivery/provider acceptance, device display, human reading and action are distinct facts. Acceptance evidence: For a release candidate, reproduce the documented local public-door journeys, then separately record hosted multi-device, provider, migration and capacity results before those target clauses become done. Failed or unmeasured end states remain visible.
9. NOOK-009
   Backup and export (C9) Two full backup paths ship, neither an ordinary app-admin export. On a local install, the filesystem operator uses local-only rer export and rer import on a stopped checkout; operator disk access explicitly bypasses app privacy. For a hosted install, the [hosted backup/export path](docs/backups.md#export-a-hosted-nook) uses the owner’s /export download or the documented node --input-type=module command calling scripts/local/remote-export.mjs from a checkout with dependencies installed; it exports the authoritative D1 database records and actual private R2 object bytes into an owner-held verified archive with its erasure journal. Nook's /export and /api/portability doors admit only an active owner's current session and authorize no import. [Base's hosted-data rule](https://github.com/runeditrun/base/blob/main/export/RUN-LOCALLY.md#if-hosted-deployment-stops) distinguishes this from local-only rer export, which refuses a hosted origin: a platform D1 SQL export alone omits R2 files and cannot satisfy this full-backup guarantee. Restore is always local, into an empty destination, and validates table identities, foreign references, schema ledger and event/read frontiers. Archives exclude sessions and sign-in tokens. User-readable and policy-scoped exits are required by NOOK-047; this clause retains the full-backup guarantee and its explicit operator-custody exception. Acceptance evidence: Local: Stop the install, export with rer export, import into an empty stopped local install, complete explicit identity recovery and re-export; compare equivalent records, private media bytes and erasure journal. Hosted: Sign in as an active owner, follow the hosted backup/export path through /export and the documented helper command to download D1 records plus R2 bytes into an owner-held archive, import it into an empty stopped local install and complete identity recovery; compare records, file bytes, rebuilt search and erasure journal. Reject non-owner/expired hosted sessions and any remote restore. Inspect both archives for private records and media, with live credentials, devices and pending deliveries excluded.
10. NOOK-010
    Commitment revision and cancellation (C10) Material text/deadline revision requires renewed assignee acceptance at the exact new version. Assignee and conversation are fixed; changing assignee means explicit cancellation and a fresh proposal, and scope cannot move across conversations. Cancellation is explicit, terminal and versioned; authors may cancel proposals/accepted work but cannot claim assignee completion. Deleted source refs become null; event rows preserve opaque sequence/object facts, never message bodies. Replay clients fetch current object state under current ACL and interpret tombstones. Acceptance evidence: Accept a proposal and revise its text/deadline: renewed acceptance is required at the new version. Cancel and create a new proposal to change the fixed assignee. Refuse stale acceptance, cross-conversation moves and author impersonation of completion; cancellation stays terminal in history and deleted source refs reveal no body.
11. NOOK-011
    Cached retries, synchronization and complete history (C11) Cached retry responses require current ACL before lookup. Reads synchronize monotonically across sessions; replay cursors indicate per-conversation sequence and bounded catch-up, not read receipts. History pages must cover the complete tested log rather than silently truncate. Acceptance evidence: Page beyond the tested history window and reconnect after missed edit/delete events. Repeat a previously successful intent after membership revocation; it must be denied before cached response lookup, with no missing or duplicated durable history.
12. NOOK-012
    Private attachments (C12) Attachments are 1 byte–25 MiB per file, five ordered files per message, with at most 50 pending/staged native uploads per uploader and no aggregate workspace byte quota. Actual bytes reside in private R2; D1 holds metadata and opaque object keys. Plain UTF-8 text, signature-checked PNG/JPEG/PDF only; forced attachment downloads plus private inline PNG/JPEG previews after structural byte validation and opt-in plain-text previews bounded to 64 KiB; no inline PDF preview or virus-scanning claim. Staged uploads last24h for binding/read eligibility, are uploader-only under current conversation ACL, and do not create attention. Unused staged bytes remain until explicitly removed. Binding uploader-owned same-conversation IDs and message/intent/event is atomic; exact ID order belongs to retry identity. Downloads recheck current membership; delete erases live bytes/name/checksum, and message deletion cascades. The media baseline archivev2 carries actual bytes plus hashes, state and binding; historical archivev3 retains these guarantees plus C13 triage and supports explicit prior-v1/v2 migration; current normalized Base portability archives retain the same custody guarantees, as described below. Backups/WAL/remnants retain their stated physical-erasure limits. These limits are the shipped baseline, not the target: NOOK-061 widens admission to any file type up to 1 GiB with in-app previews, malware scanning and admin file-type policy while keeping every custody guarantee in this clause. Acceptance evidence: Upload and bind ordered private files through the app, preview genuine PNG/JPEG and download exact bytes as an authorized participant. Deny outsiders and removed members, reject active/corrupt/oversized input, recover lost-put acknowledgements and verify deletion and backup round-trip.
13. NOOK-013
    Calm attention (C13) Calm attention is explicit per-user triage, independent of unread and outcome authority. GET/PATCH /api/conversations/:id/preferences accepts boolean muted/followed, requires current membership, and returns those choices plus followed root-thread IDs. POST /api/messages/:id/follow {follow:boolean} targets a live root thread under current ACL. Choices persist across sessions; changes affect future routing only. Muting suppresses routine follows, never explicit mentions or commitment proposals. Automatic following when a member authors, replies in or is mentioned in a thread, and of every thread in a one-to-one DM, is NOOK-072 and writes this same followed state; an unfollow through this door also ends an automatic follow. Message sends accept ordered unique mentions (at most50 current member IDs), boolean urgent, and urgentReason (1–240 characters when urgent). Urgent requests require explicit recipients. All current channel members can see the message's Notified names, Urgent marker and urgent reason, including members who were not notified. Defaults [], false, null join immutable intent identity. Identical committed retries survive recipient removal without rerouting; new sends revalidate recipients. Attention creation is atomic with durable message/outcome events and stores opaque references, not copied bodies. Precedence: urgent-request, mention, thread-follow, conversation-follow. Proposals and material revisions route to assignees; assignee actions route updates to authors. Self-authored events do not create self-attention. GET /api/attention returns current-ACL hydrated active items, deferredCount, dndUntil. Deleted sources hydrate tombstones, with no urgent-reason copy. GET/PATCH /api/settings {dndUntil:epochMilliseconds|null} controls quiet time. Quiet time defers routine items while urgent in-app requests remain visible; external delivery follows C14 email and C15 Web Push, and there is no paging guarantee. POST /api/attention/:id {action:done|snooze,until?:epochMilliseconds} requires item ownership and current ACL. Quiet/snooze deadlines must be future times within seven days. Snoozed items become eligible when due; routine items remain deferred during quiet time. Done changes only triage. Reading or accepting a commitment does not automatically close attention, and closing attention never accepts work. Schema5 preserves prior ledgers and appends explicit defaults to live prior intent payloads; erased markers remain erased. Archivev3 retains follows/preferences/quiet time/triage and validates source/event/scope references. Explicit v1/v2 imports add empty attention tables and normalize prior retry identity. Old-format archives cannot carry nonempty new attention state. Root SQLite v3 and native D1 recovery formats require an explicit separately verified mapping; a source manifest alone does not establish compatibility. C13 admission clarification: defaults apply only to omitted mentions/urgent fields, not explicit null. Explicit mentions:null or urgent:null is400 with no committed event/message/attention. Recovered dnd_until must be null or a safe integer; expired valid integers remain legal recovery values. Quiet-time domain checks precede database insertion. Acceptance evidence: At 1440 and 390, follow a thread, mute its channel, send explicit mentions/urgent requests, snooze and complete triage, and enter quiet time. Restart and sign in elsewhere: preferences persist, due items return under current ACL, and neither triage nor reads accepts responsibility. Automatic follows from authoring, replying, mentions and one-to-one DMs are proved under NOOK-072; an unfollow through POST /api/messages/:id/follow {follow:false} ends one.
14. NOOK-014
    Email notifications (C14) Email notifications reach a member away from the browser under this delivery contract. Emailable events are an explicit mention, an urgent request, a commitment proposal or material revision to its assignee, and a completion report to its author; routine thread or conversation follows, reactions, replies without a mention, accept/cancel updates and imported history are never emailed. The destination is the member's own sign-in email (an active account, verified by its sign-in link); there is no free-form address. Every member's email is off until that member turns it on in their own settings, per account: one choice covers mentions and commitments, a second covers urgent requests, with a separate choice to let urgent requests through quiet time. GET/PATCH /api/notify {mentions,urgent,urgentQuiet:boolean} reads and changes the caller's choices. Turning a choice off stops the next email: each queued item is checked again when its email is built. Every email carries a link that turns email off without a session (/notify/off: opening it shows one button and changes nothing, because mail scanners open links; the button turns all three choices off) and a link to the signed-in settings. Queue rows are written in the same batch as the attention rows, only for recipients who turned the matching email on, and hold opaque references (recipient, conversation, actor, message or commitment, reason), never message text, file names or addresses. The ChatHub alarm drains them; pending rows keep it armed, so delivery needs no open socket and a restarted Worker resumes from D1. When an email is built, nothing is sent to an inactive member, about a conversation the member can no longer read, about a deleted or erased source, after the choice was turned off, or for an item the member already marked done or a mention they already read; each is cancelled with that reason. Quiet time (C13 dndUntil) holds every item until it ends; an urgent request goes through quiet time only when its recipient chose that. Each event is queued once per recipient (keyed by its attention item), so identical retries add nothing; a burst within five seconds folds into one email, and a recipient gets at most one email per conversation per ten minutes, with later items folded into a count. A failed send is retried after 15 s, 1 min, 5 min, 30 min and 2 h, then given up; a definite refusal is not retried, and a send the provider did not confirm, or that a stopped Worker may have made, is never repeated. A send being retried or given up shows as "email not delivered" with its reason class (not set up, refused, rate limited, not confirmed) to its recipient, to the member whose message caused it and to the owner for seven days, never as a silent success. Emails name the sender, the conversation (#name, or "a direct conversation") and a link; they never carry message text, file names, urgent reasons or commitment wording. This no-text form is today's behaviour and the sender level an owner policy can force; a member's opt-in to message text in email is NOOK-062's obligation. Hosted mail goes through the same configured sender as sign-in (the owner deployment's provider). Local development sends and stores no email and exposes no mail viewer. Tests fake only the provider network edge. Accepted by the mail provider is not proof of inbox receipt, and a test provider's acceptance is not live delivery. Urgent stays an in-app request, not paging; Web Push follows C15; there is no SMS or native push. Archives carry members' choices but not the queue, so a restore sends nothing old; erasure removes a member's choices and queued items and an erased message's items. Acceptance evidence: Run the emitted-Worker notification journey through sign-in and settings with only the provider network edge substituted: opt in, mention/propose, fold bursts, hold quiet items, cancel read/deleted/revoked items, restart a retry, expose refusal/uncertainty and use the scanner-safe unsubscribe POST. Inspect that mail contains no private body or file name.
15. NOOK-015
    Web Push (C15) Web Push is a separate opt-in channel under C14's current-identity, current-ACL, source, read/done, quiet-time, retry, visible-failure and no-paging rules. Migration 0023 preserves existing email rows and choices. Defaults for a new member: once the member grants browser notification permission, and without opening settings, DMs, mentions (including NOOK-065 broadcast mentions), keyword hits (NOOK-032), call invites (NOOK-022) and replies in followed threads (including NOOK-072 automatic follows) are on, matching Slack's default of desktop and mobile notifications for DMs, mentions and keywords; urgent-through-quiet starts off. Each member may change any of them, and owners set the organization defaults under NOOK-060. GET/PATCH /api/notify adds push:{mentions,urgent,urgentQuiet,direct,threads,keywords,calls:boolean}. Mentions covers the same commitment events as email. Ordinary DMs and followed-thread replies can push without changing email or in-app Attention. Conversation-follow for Attention alone never pushes; only a conversation set to the NOOK-032 all new messages level pushes each new root message and channel-broadcast thread reply. Explicit urgent and mention reasons take precedence and require their own choice; a routine followed reply precedes ordinary DM when both are enabled. Routine follows and DMs respect mute; self-authored and imported events never push. POST /api/devices {transport:"webpush",subscription:{endpoint,keys:{p256dh,auth},expirationTime?:number|null}} registers only the caller's browser subscription under the current session. GET returns only the instance VAPID public key and the caller's opaque device IDs, transport and timestamps. DELETE /api/devices {id} removes only an owned device. Endpoint ownership cannot transfer between accounts: unsubscribe in the browser before enabling another account. At most ten devices per person; HTTPS endpoints are restricted to the supported Apple, Google and Mozilla push hosts, keys must be valid P-256/16-byte material, redirects are refused. This browser door accepts only transport:"webpush" and rejects every other transport; native iOS and Android devices register their APNs, PushKit or FCM tokens through the native device door and push path that NOOK-078 defines, and desktop apps receive over their own authenticated connection to the installation. Web Push needs no publisher service: each installation signs with its own VAPID key and sends straight to the browser vendor's push service. Each delivery rechecks the device's original session, active version, membership, preferences, native source and unread/triage state. Expired or revoked sessions and provider-expired subscriptions retire the device. One durable queue row per event, recipient and device prevents duplicate alerts from overlapping reasons and successful-device repeats during another device's retry. Email and push have independent five-second gathering and ten-minute conversation folding windows; push windows are per device. The first due eligible item gathers the already-queued eligible burst, including items still in their initial gathering period; future retries, snoozes and quiet-held items stay deferred. A counted push uses one opaque delivery ID for the whole burst, and remains current while any folded item remains current. A conditional sending lease becomes visibly not-confirmed if interrupted, and uncertain network sends are never repeated. Failure classes show to the recipient, the sender and the owner for seven days; terminal delivery metadata lasts thirty days. Read and done transactions cancel pending push. Snoozes and quiet time defer delivery; only the separately enabled urgent-through-quiet choice overrides quiet time. POST /api/devices/presence {id,page,visible:boolean} records a current-session visible-page heartbeat. Today fresh visible presence holds all of the member's Web Push; NOOK-073's cross-device active-elsewhere rule replaces that hold for Web Push exactly as for native push: a focused page with recent input is an active desktop client, Web Push to the member's phones and tablets is held while they are active on desktop and released or cancelled under NOOK-073, and the active client itself shows the alert in-app. Open sockets alone never count as presence. Foreground pages renew every fifteen seconds, hidden pages release, and the alarm automatically releases expired forty-five-second presence. No browser page is needed for delivery. GET /api/devices/sync supplies current opaque delivered-notification IDs and badge count for foreground synchronization; the count includes unread active attention and ordinary push-enabled DM events, deduplicated across devices. Web Push uses RFC 8291 encrypted payloads and RFC 8292 VAPID. The instance generates its key pair once on first authenticated use, storing the private key AES-GCM encrypted under a key derived from SESSION_SECRET, and sends only its public key to browsers. The encrypted payload contains sender/conversation display wording (DMs use "a direct conversation"), an authenticated same-origin app link with opaque conversation/message IDs, opaque recipient/delivery IDs, notification tag and badge count. No message body, commitment text, urgent reason or file name is included; this is the sender preview level, and NOOK-062 adds default-on message-text previews (inside the same encrypted payload), org caps and notification actions. Push services see the endpoint, timing, encrypted packet size, TTL/normal urgency, VAPID public key and signed audience/expiry/contact URI. Subscription endpoints, public encryption keys and auth material remain private D1 records. Archives exclude keys, devices, presence and all delivery state; restored installations send nothing old. Member/message/outcome erasure removes associated push records. Logical erasure cannot retract packets already accepted by a push service or notices already displayed on a sleeping device. The installable PWA preserves Nook's UI and authenticates navigation on every notification tap. Its service worker caches no requests or private content. Permission requests require a gesture; the foreground reconciles allowed subscriptions and visibly reports re-enable failures. The previous open-tab OS notification path is removed; the title count remains. Every Web Push shows a visible notification and can update its badge. No badge-only or clear-only background Web Push is sent: WebKit revokes silent subscriptions. Foreground authoritative refresh closes read/revoked notices and updates badges through the service worker. Immediate clearing on a sleeping device, native iOS badge updates and Android native normal-priority clears remain blocked until a native transport exists. Browser acceptance is not proof of OS receipt; C8's evidence limits still apply. Acceptance evidence: Run pnpm test:push through subscription, preferences, emitted Worker and real alarm; independently decrypt the RFC 8291 packet and verify VAPID, revocation, quiet/read cancellation, per-device folding and visible failure. Separately demonstrate foreground/background/locked-device visible notification, tap authentication and badge reconciliation on supported Safari, Chromium and Firefox devices. Defaults: a newly invited member grants browser permission in a fresh profile without opening settings, and a DM, a mention and a keyword hit each show exactly one notification; a channel set to all new messages notifies on a colleague's plain message and a channel left at mentions does not. Defaults include automatic follows: a reply in a thread the member started in a mentions channel shows one notification without any explicit follow. Cross-device routing: with the member's Chrome page focused and in use, a DM shows on that page and no Web Push reaches their phone's installed PWA; after the page is idle 10 minutes the phone notifies (NOOK-073).

DOCS 1 clause

1. DOCS-001
   Public documentation from Markdown Public user documentation is rendered from Markdown sources declared in docs/site.json. Every root and docs/ Markdown file is published or has a reason for remaining GitHub-only; missing files, links and heading anchors fail the build. Raw HTML in a page is reported and never rendered. Acceptance evidence: Build and open /docs; every declared page renders, links and anchors resolve, raw HTML remains inert, and every root/docs Markdown source is published or has a recorded exclusion reason. The app Lobby and private workspace keep their existing routes.

ERASURE 1 clause

1. ERASURE-001
   Member, message and imported-author erasure Current owners/admins may erase accessible channel messages; roles never open an operator DM door. Authors retain their own delete/remove actions. Owners may erase eligible other members; admins only accounts with the member role, including guest access; self and the last active owner are refused. Every destructive commit guards current session, role and scope. Count-only preview, explicit confirmation and a subject-free receipt accompany operator erasure. Authored content, credentials and selected import copies are erased; authored work retains only scope/kind/version count/state. Other authors retain work and state without erased assignee/action attribution. Separate credential-free structural tombstones preserve threads, counters, fixed DM audiences and immutable import ownership; audit attribution and subject references are independently anonymised. D1 atomically records public Base erasure fences and durable blob obligations before R2 deletion. Completion requires verified blob absence, including resolution of uncertain puts; larger work remains pending with bounded continuation. Latest archives carry the journal and restore normally. Old archives are refused by nonempty-destination guards or the latest journal; a virgin destination without a later journal cannot recognize them. External archives, offline copies, provider backups/Time Travel and physical remnants remain outside logical erasure. Acceptance evidence: Through Team and message erasure doors, preview counts, confirm and resume a pending job. Try an unrelated DM, an insufficient role, self and last owner; deny each. Remove native/imported content and verified R2 bytes, preserve only declared structural tombstones, anonymise audit, and refuse an older archive when the latest erasure journal is supplied.

View as agent

These publisher documents are copied unmodified from the release. Site presentation summaries and historical screenshots are attributed separately on this page. An agent evaluating Nook can read them instead of the page.

seed.json

The manifest: capabilities, outside services, extension points, limits, operating cost and deployment needs.

CONTRACT.md

The requirements on this page, in source form.

AGENTS.md

Instructions for the coding agent that maintains an installation.

LICENSE

RELEASE.json

README.md

Source setup, available commands and implementation status.

OPERATIONS.md

How the project is set up, operated and deployed.

ACCEPTANCE.md

What the publisher accepts as a finished release.

publisher-release.json

Every project, with its availability, is in /agents/catalogue.json; the agents page describes the machine-readable files.