Sterister
96c20cb4b2
aliasSession knew that two labels name the same peer, then threw that knowledge away. The binding lived only in the caller's memory, so a restart lost it — and the peer could not repair it from its side. First contact forces the receiver to label a session by the only sender hint a relay surfaces, an 8-byte signing-key fingerprint (`fp:<hex>`). Once the peer announces its canonical address, aliasSession moves the session there. But the peer keeps sending under `fp:<hex>`, because its transport derives the same label from the same hint every time. After a restart the session sat under the canonical address, inbound frames resolved to `fp:<hex>`, and nothing matched. The peer held a valid session so it never re-ran X3DH: the failure was permanent, and only a manual re-link cleared it. Observed in Prism as `No session for address: fp:579c3b335d66e2c0` on every receive for three days, with a phone whose every RPC timed out. StorageProvider gains saveSessionAlias / getSessionAlias / removeSessionAliasesFor, optional so third-party implementations keep compiling, and implemented across all seven backends. Lookups resolve through resolveLabel(), which runs BEFORE the peer mutex — locking the alias while mutating the canonical session would let an aliased and a canonical caller ratchet the same state concurrently. A live session under a label always wins over an alias, and prekey envelopes never resolve: both keep a re-link establishing a fresh session instead of being redirected into the stale one. Aliases are dropped in resetSession and acceptIdentityChange, and memoized so the hot path costs no extra read. The sdk.test.ts case that asserted a dead fp-label encoded the old behaviour; it now pins the new contract. Verified: 1166 tests pass (from 1160). With alias persistence disabled as a negative control, 5 of the 6 new tests fail, including both restart cases. Also drops `baseUrl` from the consumer-strict tsconfig — removed in TS 6.0, and it was failing the typecheck that gates publishing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@shade/transport-webrtc
V3.11 — direct peer-to-peer chunk transport for Shade transfers via
RTCDataChannel. Plugs into @shade/transfer's ITransferTransport
contract and wires automatically into @shade/sdk via
shade.configureWebRTC().
import { createShade } from '@shade/sdk';
import { nativeRtcFactory } from '@shade/transport-webrtc';
const shade = await createShade({ prekeyServer });
shade.configureWebRTC({ factory: nativeRtcFactory() });
shade.configureTransfers({ resolveBaseUrl });
await shade.upload({ to: 'bob', input: file }); // → P2P when NAT allows,
// HTTP otherwise.
See docs/webrtc.md for the full guide: NAT-traversal realities, TURN config, glare resolution, wire format, diagnostics, and end-to-end test recipes.
What's inside
WebRtcConnection— one peer connection between two Shade endpoints, driving offer/answer/ICE through Shade's own ratchet.WebRtcConnectionManager— per-peer pool with deterministic glare resolution.WebRtcSignalingChannel— JSON signaling messages multiplexed overShade.send/Shade.onMessage.WebRtcTransferTransport— implementsITransferTransportover the managed DataChannel; ack-correlated by 16-byte requestId tokens.MemoryRtcFactory— in-process WebRTC simulator for tests.nativeRtcFactory()— adapter overglobalThis.RTCPeerConnection(browsers / Deno / Cloudflare Workers).
Adapters
@shade/transport-webrtc ships only the standard-API adapter
(nativeRtcFactory). For Bun / Node, wrap your library of choice
behind the IRtcFactory interface — only createPeerConnection,
createDataChannel, and standard addEventListener are required.
Recommended adapters: