Digital archaeology
Recovering a BBS twenty years later is archaeology: the artifact is fragile, the context is everything, and the dig's first duty is to not destroy what it studies. This page is the provenance record.
The artifact
| Object | Level-0 dump(8) image of the OpenBSD system partition (/dev/wd0a) of the velvet.ath.cx host |
| Image | 102006.dmp — 1.53 GB, taken 2006-10-26 14:15 (host clock) — the board's last day, with final posts still being written |
| Restoration | restore -r — 98,776 files back; a single casualty (an unrelated OpenBSD ports RPM) |
| Earlier find | A September 16, 2006 multi-volume dump whose first volume contains no BBS data — the dig's dry well |
| Second engine | A DayDream BBS 2.14.9 installation (/home/bbs2) with only test posts — an experiment, archived with the rest |
The untouched-extraction rule
The recovered tree is kept sealed: a manifest hash (SHA-256 over every file's own hash, in sorted path order) fixes the preserved extraction exactly as restored — a02d848773f1fc3ed1222d8426a9a0dd95196810541d88a3b15d230af6749e5b over 1,842 files (24.4 MB). Before hashing, the site's own copy of the screens was byte-compared against the extraction, so the manifest provably covers the bytes visitors see rendered.
Every figure this site publishes is either derived from that tree by script — message and mail counts, room tables, the g-file catalog, dates — with the recovery totals asserted whenever the generator runs, and the committed data held to those invariants by the test suite; or documented, quoted from the provenance record (DATA_NOTES.md) for the dump-level facts the working copy cannot re-derive — the restore count, the image size, the account totals (the preserved users/ tree is a privacy-pruned subset, so account figures are cited, not counted). Nothing else is typed by hand.
Reading the formats
The board's storage was undocumented binary: fixed-width records laid out for 32-bit OpenBSD structs. The dump made exact recovery possible in a way a “backup of the files” never could — because it also preserved the board's own C source (msg.h, user.h, shack.h, rooms.h). Record layouts were reconstructed against those headers and verified byte-by-byte — alignment pads included — until all 1,005 message records decoded with valid dates. The layouts themselves are documented in the repository's data notes for the next archaeologist.
Publication rules
An archive of people's conversations carries duties. The rules this project follows:
- Private fields stay private, permanently. Real names, e-mail addresses and passwords are never published. The 2006 passwords (plaintext in the dump, as homebrew boards stored them) were hashed on import and sealed.
- Message contents stay on the board. The public web pages catalog the bases — names, owners, counts, date ranges. The conversations themselves are readable on the live board, where the participants' context and community still stand around them.
- Public-era information is published as it was public then. Room names, owners and sysop handles were visible to every caller in 2006; they are visible here.
- No retouching. Archive rows are flagged as archive; spelling, ANSI color codes and quoting style land exactly as written.
Why preserve at all
Because the record of how people actually lived online — the slang, the flame wars, the door-game grudges, the room names — survives nowhere else. The web kept its servers; the BBS era kept its people, and people's disks die. What you are reading exists because one disk image outlived its machine by twenty years, and because treating a filesystem dump as a site of record is, itself, the experiment.
The engineering side of the recovery — parser, seeder, runtime — is documented in the technical pages.