Vision and Scope

Mission

Build one durable ecosystem in which historically important online game servers and their compatible clients can be preserved, understood, repaired, reproduced, and operated responsibly.

The ecosystem joins material that is often scattered across dead forums, abandoned repositories, old installers, personal notes, chat logs, database dumps, and undocumented patches. The goal is not merely to collect files. The goal is to retain enough context to turn those files back into a verified working system.

Preservation maturity

Use these levels when reporting the state of a server/client pair:

Level	Meaning	Minimum evidence
P0 — Identified	The project or artifact is known.	Name, upstream location, short description.
P1 — Captured	Important material has been copied.	Checksums, acquisition date, provenance, access class.
P2 — Reproducible	A clean environment can rebuild or install it.	Pinned revisions, dependencies, build/install runbook.
P3 — Runnable	Server and matching client reach a defined smoke-test milestone.	Baseline manifest, logs, test result, known limitations.
P4 — Recoverable	The system has redundant copies and a tested restore path.	Backup inventory, restore drill, independent checksum verification.
P5 — Maintainable	Modernization changes are tested without losing the original baseline.	Patch provenance, regression tests, upgrade and rollback procedure.

Each profile should state its present level. Aspirational status must not be presented as verified status.

In scope

• Server source and complete Git history, including tags, branches, submodules, and Git LFS objects.
• Legally retainable server releases, installers, database schemas/dumps, scripts, launchers, protocol notes, and documentation.
• Client metadata and, where authorized, clean client snapshots and patch chains.
• Required toolchains, runtimes, operating-system packages, containers, virtual-machine definitions, and build instructions.
• Reverse-engineering findings required for interoperability, restoration, compatibility, security research, and bug repair.
• Reproducible fixes, shims, converters, migrations, test fixtures, and automation.
• Known bugs, preservation gaps, dead upstream locations, and unresolved technical questions.
• Recovery procedures for Forgejo, Git mirrors, large artifacts, and metadata.

Out of scope

• Credentials, authentication tokens, private keys, or production secrets.
• Personal data or captures containing unrelated third-party traffic.
• Publishing copyrighted client or server binaries without permission.
• Circumventing access controls, live-service abuse, cheating, or unauthorized access.
• Claims that cannot be tied to evidence, an experiment, or a clearly marked hypothesis.

Preservation principles

Original, normalized, derived

Store three distinct states:

1. Original — the exact acquired bytes, immutable and checksum-addressed.
2. Normalized — lossless organizational changes only, such as extracting a container while retaining the original archive.
3. Derived — patched, configured, converted, decrypted where lawful, or otherwise changed for use.

Never overwrite one state with another. A derived artifact must point back to every source artifact and patch used to create it.

Evidence before memory

Record versions, hashes, logs, timestamps, URLs, screenshots, commands, and test results. Human recollection is useful context but is not sufficient provenance.

Reproducibility before convenience

Pin revisions and dependencies, retain lockfiles, and document deterministic steps. Convenience shortcuts are welcome only when the underlying process remains inspectable and repeatable.

Modernize around the artifact

Prefer wrappers, compatibility layers, isolated runtime environments, configuration generators, and documented patches. Keep an unmodified reference path so modernization work can always be compared with original behavior.

Success criteria for a server/client pair

A pair is in a ready-to-use clean state only when all of the following are true:

• Exact server revision and exact client build are identified.
• Original inputs and derived outputs have checksums and provenance.
• Installation/build can begin on a documented clean host.
• Database initialization and configuration are repeatable.
• Secrets are injected at deployment time, not baked into an archive.
• A smoke test defines what “works” and records the result.
• Known limitations and unsafe defaults are visible.
• Backup and restore have been tested.
• The original baseline is retained separately from the working installation.