Sterister
8746571d2a
Browsers' Window.fetch is a WebIDL bound operation; storing it as this.fetchImpl / this.fetchFn and calling via the instance receiver threw "Illegal invocation" on the first request. Bind once at construction in InboxClient, LongPollBridge, and SseBridge. Reported by Prism (multi-device E2EE terminal), blocking every browser consumer of the v4.6 transport stack on inbox.start() / bridge.connect(). WsBridge unaffected (uses WebSocket). Node/Bun fetch tolerates a free receiver, so the bug never surfaced server-side — added regression tests that install a strict-receiver globalThis.fetch to catch the issue without an actual browser harness. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@shade/transport-bridge
Transport-agnostic delivery for Shade: WS → SSE → long-poll, in priority
order, behind a single IncomingMessage interface.
import {
FallbackBridgeTransport,
WsBridge,
SseBridge,
LongPollBridge,
} from '@shade/transport-bridge';
const auth = { crypto, signingPrivateKey, address: 'bob' };
const bridge = new FallbackBridgeTransport([
new WsBridge({ baseUrl, auth }),
new SseBridge({ baseUrl, auth }),
new LongPollBridge({ baseUrl, auth }),
]);
await bridge.connect({
onMessage: (msg) => {
// msg: { from: string; bytes: Uint8Array; receivedAt: number; msgId?: string }
},
});
console.log(bridge.activeKind); // "ws" | "sse" | "long-poll"
Pair with createBridgeRoutes in @shade/inbox-server to expose the
matching /v1/bridge/{stream,poll,ws} endpoints. Full design + threat
model in docs/transport.md.
What it solves
Browser extensions, strict corporate proxies, and edge runtimes routinely block long-lived WebSockets. Apps that already use the Shade inbox shouldn't have to write three custom delivery paths to handle the realistic mix of hostile networks they ship into. This package is the canonical answer.
Status
V3.7. Stable wire format, additive change to @shade/inbox-server. See
CHANGELOG.