Restoring historical projects
An archive becomes more useful when its preserved files can explain what people made with them. Avichive’s restored projects take surviving source code, databases and assets and turn them into readable or interactive experiences within the Rails application. Each restoration has a different relationship to the original: recovered writing, playback of a historical dataset, or a reconstruction of an interaction whose media has vanished.
The technical work starts with an evidence inventory. Which application version survives? Is there a production database or only development data? Are images stored locally, and did video depend on an external service? Those answers determine what the restoration can faithfully reuse and what must be adapted or left missing.
Recover a working set
The application can extract an archived directory tree from scanner entries. The extraction task finds files beneath a source path, copies reachable originals from the mounted archive drive, or materializes uploaded B2 content by hash. It recreates relative paths and modification times, skips common dependency/cache directories by default, and writes a manifest of missing files. See the tree recovery task (lib/tasks/restore.rake:1).
A content-addressed object store preserves bytes without requiring the original directory to exist on the running server. The scanner catalog supplies the paths needed to reconstruct that directory. Both matter: a pile of objects cannot alone explain how a project was arranged, while a directory listing cannot recover missing bytes.
Extraction is therefore the beginning of restoration. It cannot recreate a disappeared CDN, revive old credentials, guarantee obsolete dependencies install, or turn a development database into missing production history.
Choose a maintainable representation
The restored sections use the modern Rails host rather than running every historical application stack. Writing can become Markdown with metadata; a social dataset can become JSON; a montage can become a file-backed layout with static media. Dedicated layouts and browser code preserve selected presentation and interaction while the app provides routes and project links.
The resulting experiences are deliberately different:
| Project | Preserved evidence | Modern presentation |
|---|---|---|
| flombaum.com | Access database, writing, comments, photos and assets | Markdown/YAML content rendered by Rails |
| Sawbaum | Source, a recap GIF and presentation slides | Montage playback and a temporary editor using replacement footage |
| Tweefle | Moderated historical tweets, cached media and interface assets | Browser playback of a curated JSON dataset |
Restored Project records link these experiences from the archive. Their URL and restored status are catalog data, separate from the file-backed page content. The implementation is described in the Project data model (docs/DATA_MODEL.md:194).
Preserve the limits alongside the result
A useful technical explanation identifies what survived, what changed and what cannot be recovered. Flombaum’s migration preserves readable content without requiring classic ASP. Tweefle reconstructs a Twitter-wall experience without claiming live ingestion. Sawbaum demonstrates the montage behavior with new loops while acknowledging that the original Vine clips are unavailable.
These distinctions also guide future work. An extracted Flatiron source tree is research material; it does not by itself establish a publicly restored Flatiron website. A working modern interface is evidence of reconstruction, not proof of byte-perfect historical fidelity.
The three case studies follow the same trail from surviving artifacts through extraction and adaptation to present behavior. Their public links let readers explore the result; the implementation notes identify how it was built. Current runtime completeness is separate from this source-grounded account of the implementation.