Files
Shade/docs/V2.2.md
Sterister fa770d3063
Some checks failed
Test / test (push) Has been cancelled
feat(files): @shade/files 0.3.0 — E2EE filesystem RPC primitive
M-Files-1..6 land the full files-RPC layer + everything 0.3.0 needs to
ship. Apps keep their own UI; this layer ships the typed RPC, the
streams bridge for content I/O, and production hooks (rate limit,
retention, fingerprint gate, metrics).

@shade/files (NEW)
- Standard ops: list/stat/mkdir/delete/move/read/write/getThumbnail with
  Zod-validated wire schemas + clean user-handler types.
- Custom ops: typed via TypeScript declaration merging on CustomOpsMap
  + per-op Zod schemas; client.custom('app.foo', {...}) is fully typed.
- Content I/O: inline (≤ 256 KiB plaintext) base64-in-RPC; streams
  (> 256 KiB) ride @shade/transfer via userMetadata.shadeFilesWriteId
  / shadeFilesReadStreamId correlation. Server-side TransformStream
  bridges accept inbound transfers immediately (engine rejects chunks
  that arrive before accept) and park the readable for the matching
  RPC.
- Directory ops: walk(path, opts) async-iterable depth-first walker;
  uploadDirectory()/downloadDirectory() with bounded concurrency pool
  (default 4, cap 16), aggregated progress, abort.
- Production hooks (callback-based, vendor-neutral): rate-limit (op +
  byte), idempotency cache (LRU + TTL + in-flight de-dupe), path
  policy (traversal + percent-decode hardening), fingerprint gate
  (required/optional/reject), pluggable Ed25519 sig verification with
  ±5 min replay window, onMetric sink (standard names).
- React hooks (subpath @shade/files/react): ShadeFilesProvider,
  useShadeFiles, useFileList, useFileTransfer/Upload/Download.
- Shade.files.serve(handler) + Shade.files.client(peer) high-level
  entrypoint in @shade/sdk; lazy + memoized; one handler per Shade.

Wire format bump
- @shade/proto wire VERSION 0x01 → 0x02. Length prefixes changed from
  u16 to u32. The previous u16 silently truncated payloads above
  64 KiB — a hard correctness ceiling that blocked inline file ops
  up to 256 KiB. Wire-incompatible with 0.2.x peers; new sessions
  only. Cross-platform Kotlin port (android/shade-android) updated to
  match; test-vectors/wire-format.json regenerated.

Concurrency safety
- ShadeSessionManager.encrypt/.decrypt now run under per-peer mutex.
  Concurrent decryptions of the same peer raced ratchet state
  (manifested as sporadic "Failed to decrypt — wrong key or tampered
  data" under load — surfaced once concurrent uploadDirectory pumped
  many writes in flight). Encrypt was already serialized via
  Shade.send's encryptChains; decrypt is now serialized at the
  manager layer too.

@shade/streams extension
- StreamMetadata.userMetadata?: Record<string, string> for
  application-level key/value pairs that round-trip verbatim through
  stream-init plaintext. Used by @shade/files for write/read
  correlation; available to any consumer.

@shade/sdk extension
- Shade.files getter (lazy + memoized).
- BackgroundHooks.onPruneFiles + periodic timer (default 5 min) +
  BackgroundTasks.setHook(name, fn) for runtime hook registration.

Bundles in-flight 0.2.0 work
- packages/shade-streams/, packages/shade-transfer/, related
  shade-sdk streams-bridge + shade-widgets transfer hooks were
  uncommitted prior to this session. Including them keeps the
  workspace consistent at 0.3.0 since @shade/files depends on them.

Tests
- 74 new tests in @shade/files (572 → 646 workspace pass; 0 fail;
  3× stable). Coverage spans unit (inline-threshold + concurrency),
  integration (read-write inline + streams up to 1 MiB, walk +
  upload/download directory, custom-op, metrics, SDK namespace
  end-to-end), and security (tampered-envelope sig verification,
  replay window, fingerprint gate, rate-limit + quota).

Release artifacts
- All packages bumped to 0.3.0 via scripts/bump-version.ts.
- scripts/publish-all.ts PACKAGES updated with shade-files in
  topological order (after shade-transfer, before shade-sdk).
- bun run publish:dry clean (14 packed, 0 failed).
- examples/08-files-browser/ — three-process CLI demo (prekey + Bob
  server + Alice CLI) covering list/stat/mkdir/delete/upload/download.
- docs/files.md — full API + design doc.
- CHANGELOG.md 0.3.0 entry.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 14:00:01 +02:00

5.4 KiB
Raw Blame History

Shade V2.2 — Feature plan: product, platform, and developer experience

This document gathers planned features that extend Shade beyond todays core (X3DH + Double Ratchet + Streams/transfer): groups, asynchronous delivery, richer file UX, web workers, CLI, API docs, and scaffolding.

Add optional per-feature status (Idea / Design / IMP / Done).


1. Groups / multiple participants

Vision: Beyond strict 1:1 — multiple identities in the same “conversation” or shared context (messages and possibly shared file/stream policy).

Challenges:

  • Todays Signal-like core is naturally 1:1; groups need either pairwise sessions per member, sender keys / fan-out, or a dedicated group protocol (larger architectural step).
  • Lifecycle: invites, member removal, compromised device, history, and group PCS.

Goals for early milestones (proposal):

  1. Document a recommended pattern for “group-lite” (e.g. coordinator relays ciphertext without decrypting + clients encrypt per-recipient).
  2. Optional minimal API making fan-out easier in the SDK (without promising full MLS).

Acceptance criteria (MVP definition): Explicit scope in docs + one reference architecture; no ambiguous “group is done” without an updated threat model.


2. Async store-and-forward messaging

Vision: Recipient need not be online; ciphertext is stored temporarily and fetched when the recipient returns — the server never sees plaintext.

Distinction from the prekey server:

  • Prekey stays public keys only (or extended only under strict policy).
  • A dedicated relay/inbox service (or app-owned backend) holds encrypted blobs only with TTL, idempotency, and authorization (who may list/fetch).

Deliverables (proposal):

  • Protocol sketch: address registration, PUT blob, GET/DELETE or lease, replay protection at the application layer.
  • SDK helpers: outgoing queue, poll/pull, or push-notification hook (without dictating mobile platform).

Acceptance criteria: Threat-model section “what the relay sees” + reference implementation or example app.


3. File metadata and preview

Vision: Richer UX without leaking sensitive content to the server: filename, MIME type, length where known; optional client-generated thumbnails or previews encrypted as separate blocks or small payloads on the control init path.

Technical considerations:

  • Anything sent must be E2EE or omitted; plaintext metadata on the server must be deliberate and minimal.
  • Thumbnails should use format hardening on the client (size limits, sandboxing in UI).

Acceptance criteria: Extended stream-init (or sidecar envelope) with optional fields + widget support for “preview when available”.


4. Web: worker-based crypto and streaming

Vision: Large files in the browser without blocking the main thread or blowing RAM — Web Crypto / noble inside a Worker, ReadableStream/WritableStream end-to-end chunk pipeline aligned with @shade/streams / transfer.

Deliverables:

  • @shade/crypto-web (or companion) patterns: transferable buffers, lifecycle, errors surfaced to the UI.
  • Documented constraints (Safari, chunk sizing, Service Worker vs dedicated worker).

Acceptance criteria: E2E demo or test that sends multiMiB through a worker without a blocking UI.


5. CLI: shade doctor

Vision: One command that diagnoses the environment before production debugging.

Typical checks (proposal):

  • Reachability of prekeyServer (/health, optional OpenAPI).
  • Local config: storage path, rotation headers, clock skew (relevant for signed requests).
  • Streams: transfer routes mounted, auth matches expected key, GET .../state behaves as expected in test mode.
  • CLI / Node/Bun runtime versions and @shade/* packages where readable from package.json.

Acceptance criteria: shade doctor with exit codes suitable for CI (warn vs fail).


6. OpenAPI / docs

Vision: All HTTP contracts teams are expected to implement (prekey and transfer) appear in one OpenAPI story or clearly linked specs — not only README examples.

Deliverables:

  • Consolidate or cross-reference openapi.yaml with transfer endpoints (/v1/transfer/*) and security schemes for chunk upload.
  • /docs (Redoc or similar) or published static artifacts for versioned specs.

Acceptance criteria: Generated client (e.g. Python/Go) from spec without manual fixes for the happy path.


7. shade init

Vision: Scaffolding from empty repo to a minimal runnable app with Shade and optional streams.

Extensions:

  • New or extended template: minimal Hono/Fastify app with Shade.transferRoute() mounted, auth example matching the SDK authenticator, .env template.
  • Optional: demo shade doctor after init.

Acceptance criteria: shade init … produces a project that bun install && bun run start runs with documented env vars.


Dependencies between items

shade init ─────► doctor (same conventions for URLs and secrets)
openapi/docs ◄── transfer + prekey (single source)
web workers ───► streams UX (large file in browser)
groups ◄──────── store-and-forward (often related socially/technically)
metadata/preview► widgets + proto/control plane

Document versioning

  • V2.2 — feature backlog as described. Split into issues/ADR per feature when implementation starts.