Network forensicsBrowser/API boundary

The session is legible.
The backend is not.

This Chrome capture exposes DeepSeek’s browser-facing protocol in unusually clean detail: prompts, search cards, streamed answer patches, proof-of-work, uploaded-file derivatives, polling, and telemetry. It does not expose the server-side retriever, ranking stack, prompt assembly, or token-level grounding path.

Primary source chat.deepseek.com.har
SHA-256 Loading…

Public build — conversation content removed

The captured session's later turns mapped named family, investor, immigration, and professional relationships, including third parties who did not consent to publication. That material is removed from this build's data files, not hidden in the interface: the prompts, responses, generated queries, uploaded image, and raw response streams are absent from report.json and from the blob directory. Per-turn structural telemetry, the wire protocol, and the network analysis are unchanged.

01 / Findings

What the file proves

Every claim is tagged by epistemic status. “Observed” is directly recoverable from the HAR; “inferred” follows from request ordering; “limit” marks the edge of the evidence.

02 / Search evidence

Enabled sixteen times.
Triggered twice.

The distinction matters. A request flag expresses capability; a SEARCH fragment in the SSE state is direct evidence that the backend actually ran search.

Turn outcomes
Search triggered No search fragment
Source-quality warning

Three “architecture” citations are community posts—not DeepSeek documentation.

The surrounding bundle fetched and translated Baidu Cloud community articles surfaced by turn 2. Their precise metrics and confident internal diagrams are useful as examples of what DeepSeek retrieved, not as proof of how DeepSeek itself works.

Answer-claim audit

DeepSeek explains itself with more confidence than the evidence warrants.

Turn 2 turns retrieved third-party material into a mechanistic story about DeepSeek’s private infrastructure. The matrix below separates what the capture actually supports from what the answer merely asserts.

03 / Reconstructed session

Sixteen completion streams,
one conversation

The capture begins mid-thread at parent message 6. Each visible user request and assistant stream after that point is reconstructed from the stateful SSE delta protocol. Fourteen of the sixteen turns have their text withheld here; their timing, frame counts, token usage, and search flags are intact.

04 / Wire protocol

What actually crosses
the browser boundary

The visible protocol is a sequence of anti-abuse setup, one completion request, and a long-lived SSE response carrying a compact patch language.

01Browser

Request challenge

POST /create_pow_challenge

Target path identifies chat completion or file upload.

02Client compute

Solve DeepSeekHashV1

difficulty = 144000

SHA3 WebAssembly is requested nearby; its body is omitted from this HAR.

03DeepSeek API

Submit completion

x-ds-pow-response

Prompt JSON plus PoW, HIF, client, locale, version, and settings fields.

04State stream

Patch response

APPEND · SET · BATCH

Ready → optional search → token deltas → finished → close.

Decoded PoW headerBase64 ≠ encryption

        

The SSE patch grammar

p
State path, e.g. response/fragments/-1/content
o
Operation: APPEND, SET, or BATCH
v
Value. Path and operation carry forward across tiny token frames.

This carry-forward design explains thousands of minimal {"v":" token"} frames.

05 / Tokens & cryptography

Encoded, encrypted,
and merely opaque

These categories are easy to blur together. The capture contains all three.

06 / Network anatomy

Most requests are not chat

Volcengine collection calls dominate the request count. Chat and settings carry most of the meaningful application state; static assets dominate declared bytes.

Client settings snapshot · version 61

The product advertises Instant, Expert, and Vision—not the model names claimed in the answer.

These labels are client-facing configurations rather than proof of underlying model weights. They are still stronger evidence about this session than names synthesized from search results.

Endpoint ledger method, path, count, size, and latency
EndpointRequestsBytesMedianP95
07 / Evidence & provenance

Every recovered body
is content-addressed

Embedded response bodies are decoded exactly once, SHA-256 hashed, and stored by digest. Missing static bodies are recorded as missing—not silently treated as empty.

How this directory was assembled

The “recent additions” are a five-stage research bundle.

File modification times show a clear sequence: browser capture, follow-up source collection, translation, a reading interface, then Finder metadata. The raw HAR predates all of the explanatory material around it.

SourceRoleSizeSHA-256
BlobTypeSizeReferences

The full 194-item ledger lives in blob-manifest.json. Eighteen blobs carrying private session material are withheld from this build; their hashes and sizes remain in the ledger so the integrity chain stays auditable, but their bytes are not published.

08 / Evidentiary boundary

What remains unknowable
from this capture

  1. 01
    Backend retrieval implementation

    No server-to-search-provider traffic, index calls, crawlers, or rerankers are visible at the browser boundary.

  2. 02
    Prompt and context assembly

    The result cards reaching the browser are observable; the exact material injected into the model context is not.

  3. 03
    Attention or token-level attribution

    Citation order is evidence of presentation, not a trace of which source tokens causally shaped each generated token.

  4. 04
    Missing static bodies

    65 entries omit their bodies, including the versioned JavaScript and SHA3 WebAssembly required for a full client-code audit.