068 — REVIEWED: shared transport can explain xinzhai/xz encoding differences
September5,2026. Focused follow-up to067.

Finding
All nine multipart xinzhai groups exactly match the following structural pipeline:
Fernet-layout-compatible binary -> URL-safe Base64 token text -> standard Base64 -> split into30,000-character paste pieces.
This reproduces all76 authored multipart bodies exactly. It is a reconstruction of encoding and chunk boundaries, not recovery of plaintext or encryption keys.

Why this matters for the shared-workflow hypothesis
The large posts have no literal plus signs or spaces; the small xz posts exhibit the spaces-to-plus Base64 pattern. That difference can arise even if both use the SAME submission code. Standard Base64 applied to URL-safe Base64 ASCII text cannot emit a plus or slash character. Thus this extra layer shields large posts from a hypothetical transport path that turns literal plus into space. Standard Base64 of arbitrary binary, as in the small records, can contain plus signs and expose the same transport defect.
The absence of space damage in large posts is therefore not evidence of a different transport/client. Together with the uninterrupted sequence and interleaving in067, this supports investigating one application with two serialization branches.
It does not prove the form-submission bug, client identity, shared key, content semantics, or a cryptographic relationship between the large and small binary payloads. Different ciphertext formats remain possible within one application.

Exact checks
- Nine groups: xinzhai, v5.2, v52, v60, v61, v70, v71, v72, v73.
- All numeric part sequences contiguous within each group, including gaps in paste IDs caused by interleaved xz posts.
- All76 raw-source hashes and authored-text hashes verified against the final checkpoint before decoding.
- Decode each outer part, concatenate by numeric part number, then verify the inner URL-safe Base64 canonically.
- Standard-Base64 encode the reconstructed inner token text, split every30,000 characters: every piece equals the original authored body.
- Every non-final outer piece decodes to22,500 bytes of inner token text. This gives a second exact chunking fingerprint.
- All nine groups: zero outer spaces, zero plus signs, zero slash signs. Inner token text contains URL-safe punctuation, so the observed outer alphabet is not just an accidental lack of symbols in the underlying token.

Alphabet verification
Exhaustively encoded all274,625 three-byte combinations from the65-character inner alphabet (letters, digits, dash, underscore and padding equals). None produced plus or slash in the outer Base64. Short final groups only introduce padding and cannot create the missing symbols. This is an encoding property; no statistical guess about the encrypted content is needed.

What cannot be inferred about operation order
Base64-encoding the whole token text before30,000-character splitting is observationally equivalent here to splitting that text into22,500-byte pieces and encoding each piece. The piece size aligns with Base64's three-byte input groups. The data do not determine which implementation order was used. Search public source for both30000 and22500 chunk constants.
Likewise, calling the inner bytes a Fernet token records layout compatibility only; no keyed authentication or decryption was performed.

Focused client fingerprint
Public code that combines version-labelled multipart paste names, one of the aligned chunk sizes, outer encoding of already encoded token text, and a separate small knowledge-record path would be a much more specific candidate than a generic encrypted memory framework. Evaluate source statically; do not run an uploader or use any discovered secrets.

Reproduce
swarmhunt/.venv/bin/python investigation/china/068-xinzhai-encoding-pipeline.py
Input:039 final checkpoint plus hash-verified local source captures.
Private metadata output:068-private/analysis.json. No decoded payload bytes were saved. No origin requests, test uploads, key searches or source-code execution occurred.