Files
Shade/packages/shade-recovery
Sterister 7520b11b25
Some checks failed
Test / test (push) Has been cancelled
Docker build and publish / docker (push) Has been cancelled
Publish / publish (push) Has been cancelled
release(v4.2.0): pull-mode streams for browser @shade/files
4.1.0's HTTP RPC for browsers capped at inline payloads (≤ 256 KiB).
4.2.0 unlocks streams: server queues outbound chunks + control
envelopes per peer, browser long-polls the queue. Browser-to-server
writes ride the existing /v1/transfer/<id>/chunk POST routes
unchanged.

For Dispatch this unlocks mod-jar uploads (50 MB) and world-backup
downloads (100+ MB) — the actual reason browser-side @shade/files
matters.

### New API

@shade/sdk:
- shade.transferQueueRoute(opts?) — Hono app with /queue +
  /v1/transfer/* routes. Auto-configures the queue transport.
- shade.configureTransfers extended: transport + envelopeTransport
  override slots; resolveBaseUrl optional when both supplied.

@shade/transfer:
- OutboundQueue — per-peer monotonic event log with long-poll
  semantics, idle-eviction GC, ring-buffered to maxEventsPerPeer.
- QueueTransferTransport — enqueues instead of POSTing.

@shade/files:
- httpClient({ outboundQueueUrl, transferBaseUrl }) — when set,
  starts a long-poll drainer + builds a streams-bridge. fs.read /
  fs.write of >256 KiB work end-to-end.
- startQueueDrainer(shade, opts) — exported helper for advanced
  consumers driving their own drainer.

### Implementation notes

- ClientStreamsBridge's TransformStream had HWM=0 by default which
  stalled the drainer's await chain at chunk 4 (writer.write pended
  before the consumer's reader was attached). Bumped to HWM=64 so
  the receive loop can buffer ahead of the consumer.

### Tests

3 new integration tests in tests/integration/http-rpc-streams.test.ts:
4 MiB streamed read round-trip, inline-only error path, idle-timeout
long-poll behaviour.

Wire-compatible. Source-compatible. Lockstep bump to 4.2.0.

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

@shade/recovery

Social key recovery for Shade — V3.10.

Shamir Secret Sharing over GF(2^8) splits the user's identity backup key into n shares; any threshold-many k together reconstruct the identity onto a new device. Distribution and reconstruction ride existing 1:1 Shade sessions — no centralized recovery agent.

Install

bun add @shade/recovery

Quick wire-up

import {
  setupRecovery,
  attachGuardian,
  requestRecovery,
  MemoryRecoveryStore,
} from '@shade/recovery';

// Primary (Alice's existing device)
await setupRecovery({
  shade,
  guardians: ['bob', 'carol', 'dan', 'eve', 'faythe'],
  threshold: 3,
  deliver: async (to, envelope) => myOutbox.send(to, envelope),
});

// Each guardian
attachGuardian({
  shade,
  store: new MemoryRecoveryStore(),    // swap for persistent store in prod
  approve: async (ctx) => askUser(ctx),
  deliver: async (to, envelope) => myOutbox.send(to, envelope),
});

// New device (Alice on a fresh phone)
await requestRecovery({
  shade: tempShade,
  originalAddress: 'alice',
  setupId: '<from recovery card>',
  threshold: 3,
  guardians: ['bob', 'carol', 'dan', 'eve', 'faythe'],
  deliver: async (to, envelope) => myOutbox.send(to, envelope),
});

See docs/recovery.md for the full threat model, persistence recommendations, and guardian-UX guidance.

Tests

bun test                    # all
bun test tests/shamir       # Shamir primitives
bun test tests/integration  # 3-of-5 end-to-end
bun test tests/adversarial  # k-1 collusion + forged shares + OOB-gate