Reads happen on your device. Provers never see plaintext.

The read path, step by step

1. Authorisation. The client authenticates with SkyeConnex and, by passing through proof of the User Master Key derivation, requests access to a file's metadata.
2. Shard manifest. The platform returns the file's frame manifest: how many frames, which providers hold which shards, the per-shard SHA-256 expected hashes.
3. Parallel fetch. The client opens parallel connections to all seven shard locations. As soon as any five succeed, it has enough to reconstruct.
4. Local RS(5,2) decode. Reed-Solomon decoding happens entirely in the client. The two missing shards (if any) are reconstructed from the parity.
5. Frame decrypt. Each ~5 MB frame is AES-256-GCM decrypted with the per-frame deterministic IV bound to (file_id ‖ frame_index). AAD binding ties ciphertext to file identity — shard substitution is detected.
6. Streaming output. Plaintext streams to the application memory-flat — the platform never allocates a full-file buffer at any layer.

What the server sees

• That you requested file X.
• That you fetched shard manifests for it.
• That you holding a valid session.

The server does not see your plaintext, your DEK, your UMK, or any combinable subset of shards. That's the topological half of zero-knowledge — the cryptographic half is covered in Zero-Knowledge Cloud Storage.

What this means for compelled disclosure

A subpoena to the SkyeConnex operator can compel access logs and metadata. It cannot compel plaintext, because the operator does not have plaintext to compel. A subpoena would have to land at the storage providers — and recall that five providers must be compelled simultaneously, across as many jurisdictions as the customer has configured, to assemble enough shards to attempt decryption. And even then, the keys are not in scope of any one of them.

Streaming downloads, cancellable mid-flight

Streaming is platform-wide. Downloads are memory-flat regardless of file size and cancellable mid-stream, on every client surface — web, mobile, Windows virtual drive, S3 gateway. There is no point in the stack where the platform allocates a full-file buffer.

How long does reconstruction take?

Reed-Solomon RS(5,2) decoding is extremely fast on modern CPUs — typically <5ms per ~5 MB frame on a recent laptop. The bottleneck is network parallelism across the shard providers, not decoding. In practice, reads complete at provider line-rate, with the latency of the slowest of any five (not seven) providers — because two can fail or be slow without blocking.

Memory model: stream, don't buffer

Downloads are memory-flat regardless of file size. The platform never allocates a full-file buffer at any layer — not on the server, not on the client. A 50 GB file streams the same way as a 50 KB file: frame-by-frame, ~5 MB at a time. Cancel mid-stream and the platform releases all state immediately; the partially-decrypted bytes never leak.

This matters for two reasons. First, regulated workflows often require predictable memory bounds for security analysis. Second, large-file workloads (video masters, research data, legal discovery) become tractable on consumer hardware that wouldn't have enough RAM to buffer the file in full.

Browser-based reconstruction

For the web client, all four pipeline steps run in the browser using WebCrypto for AES-GCM, JavaScript-implemented Reed-Solomon for decoding (hardware-accelerated where the runtime supports it), and the Fetch API for parallel shard pulls. No server-side decryption helper exists; if one did, the architecture would not be zero-knowledge.

Mobile reconstruction across battery cycles

Mobile clients persist in-flight reconstruction state to local storage. An OS-killed app or a backgrounded session resumes the read on next launch — surviving up to twenty-four hours of inactivity to match the server-side TTL. A user reading a large research dataset on a long flight with intermittent battery doesn't lose progress.

Implications for procurement and audit

"The platform cannot, by construction, produce plaintext" is the architectural property that procurement teams ask about — and that most cloud-storage products cannot honestly claim. SkyeConnex's read path makes the claim demonstrable: the server-side audit log shows shard manifests being delivered, but never shows a decrypt operation, because none exists server-side.

For regulators inspecting the architecture, this is straightforward to verify: walk the code path on the server, find no decrypt operation, conclude that the architecture genuinely cannot produce plaintext. The non-existence is the proof.