No source change here. atproto-bridge vendors atproto-did-peer, and that package gained a deadline on every RPC (atproto-did-peer 6ec4b28) -- but a vendored sibling only reaches production on a REBUILD, so the membrane kept running the Aug 7 copy. Measured on stortron's live install before this: node_modules/atproto-did-peer/lib/did-peer.js Aug 7 DEFAULT_RPC_TIMEOUT_MS occurrences: 0 :109 const res = await rpc.request(method, params) That is the component the fix was FOR. Every membrane->hpp call -- get-blob, apply-write(s), create-session, refresh-session, upload-blob, get-service-auth, get/put-preferences, list-blobs, and the derive path of get-repo-car -- is made from inside an HTTP request handler here. protomux-rpc defaults timeout=-1 and arms its timer only when timeout > 0, so an hpp that was alive but wedged never answered and the HTTP request hung forever: no 504, no log, nothing to restart. 0.9.47 added withDeadline to the HTTP upstream and left the P2P upstream in the same handlers unbounded; this closes that half. Version bumped deliberately: pgh-sidecar skips install when the version is unchanged, so republishing at 0.9.47 would put bytes in the registry that no host would ever install -- a silent no-op rebuild, which is exactly the trap that makes "I redeployed it" untrue. Pre-flight: npm run smoke passes (bare membrane closure boots + serves the keyless surface). Local vendored copy verified to carry the fix before publishing. Refs: hyper-social #47 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>