130 — Could a standard uploader explain the XZ posting format?
Checked 2026-09-05 UTC. No identified writer; this narrows one concrete lead.

The original pastebinit author explicitly listed paste.ubuntu.org.cn as supported in the January 2011 release. Therefore selection of this host need not originate in contemporary Chinese agent tooling.
https://stgraber.org/2011/01/30/pastebinit-1-2-released/

Inspected the current upstream main program and exact-host config as source text, without executing or submitting anything. GitHub blob identities were independently verified. Captures and hashes: 130-private/sources.json; tree c269632a37e6fd603bde65a5d4b2cad7f3055557.
https://github.com/pastebinit/pastebinit
Main program blob: 22ceccc6eafed564056a20e2faafbde27473f931
Host config blob: 39fbbf87a6d1122239086e22c4fe94f47eaaccfb

Findings from these two files:
* Maps author/user to poster, content to code2, syntax format to class. Config has no title field and no size limit.
* Default author comes from USER/LOGNAME; the caller can override it. A label in poster is not necessarily an account identity.
* Reads text input, strips trailing whitespace, submits each input as one paste.
* General size-limit behavior is rejection, not multipart splitting.
* Form encoding uses urllib.parse.urlencode, which preserves literal plus signs through percent-encoding under a normal single form decode.
* No encryption, Base64 transform, 30,000-character chunker or generated _p1 naming found in this main-program/config path.

Implication: unmodified pastebinit does not explain the XZ multipart naming or encoding by itself. A wrapper could prepare those inputs first, so the tool cannot be excluded as a transport. It also does not supply a client-side explanation for the observed plus-to-space transformation. Additional server decoding or another client remains possible; no posting experiment performed.

The Krita support manual independently recommends text paste hosts including this exact Chinese Ubuntu host, and describes Base64 as a way to share binary files. That makes generic file sharing another mundane origin for an uploader, without establishing any connection to XZ.
https://docs.krita.org/en/contributors_manual/user_support.html#how-to-share-a-file

Searches for pastebinit with Fernet or 30000, and the host with encrypt/backup/storage terms, did not surface a matching writer in the returned results. Unrelated IRC logs and package mirrors are not evidence of a match. Search absence is not absence from all repositories.

Next discriminating direction: public support-channel logs may preserve someone sharing the release URL or discussing an uploader, even when the source itself never entered a repository. Search exact XZ labels and selected known release IDs, then inspect only public read-only logs. Keep chronology and ordinary support traffic separate from provenance.