# Federated project preservation Status: late-horizon concept, recorded 2026-10-08. No implementation, deployment, admission program or availability commitment is approved by this document. Priority follows [ROADMAP.md](ROADMAP.md): first complete the platform's planned features, operate them successfully ourselves and reach owner acceptance of the product. This proposal adds no launch gate to the current infrastructure rollout. ## Purpose Independent OSS-OO servers could help selected projects survive the loss of a hosting site or operator. Federation would support preservation and recovery as well as cross-server collaboration and access. A project could keep a complete, usable copy under its own control and choose approved peers to hold additional copies. Working editorial idea, subject to the eventual product's actual scope: **“Ours to build. Yours to keep.”** This is a design aspiration, not a claim that data can never be lost. User control should mean a documented export, an independently tested restore and an exit path that works when the original service is unavailable. Operating one's own server is an option. ## Who could participate Explore a voluntary program for selected organizations or projects, with applications and published eligibility criteria. Admission could consider project value, preservation needs, accountable maintainers, data rights, size and change rate, available capacity and a sustainable operating plan. An approved organization explicitly selects the projects and data classes covered; membership alone never enables replication of all its data. Admitting a project and admitting a storage operator are separate decisions. External supporters could contribute server capacity, operations, funding or maintenance. Hosting capacity does not grant access to private project data or administrative authority over another organization. Reciprocal hosting could be supported but need not be required of every project. Each accepted project needs a documented agreement covering retention, quotas, recovery responsibilities, support, withdrawal, expiration and handover when an operator leaves. An application is a way to make bounded commitments that participating operators can actually sustain. ## What preservation must cover Define an explicit recovery set: repository history and references, large files, issues and discussions, attachments, releases and packages, plus the metadata needed to reconstruct the selected project. Publish both included and excluded data classes. Replicating a repository alone cannot establish that the whole project is recoverable. Use versioned, consistent recovery points with authenticated manifests and integrity checks. Retain independent historical recovery points so that accidental deletion or corruption of current data does not immediately destroy every recoverable copy. Credentials and deployment authority must be handled separately from project content. The eventual interface should show the agreed replica target, independently operated failure domains, replication freshness, last verified restore, retention deadline and degraded state. A transfer acknowledgement or a checksum check is not a restore test. Express the tolerated loss window and expected recovery time explicitly. Preservation, read availability and writable service failover require distinct evidence and commitments. ## Security and user control questions The first design task is a threat model and a recovery contract. Resolve: - **Authority and consent:** authenticated peers, narrowly scoped grants, explicit project selection, private metadata exposure, access changes and revocation. Loss of the original login service or domain must not make legitimate recovery impossible or enable another party to take ownership. - **Confidentiality and keys:** for private data, authenticated encryption before transfer to storage peers, a reviewed key-management design and user-controlled recovery options. Define key loss, rotation and compromise handling; reuse established implementations rather than inventing crypto. - **Hostile or failed peers:** verify content and versions, reject replayed or rolled-back manifests, isolate imported data, and exercise unavailable, corrupt and malicious peers. No automatic execution of replicated code, workflows, hooks or recovered production credentials. - **Deletion and retention:** reconcile explicit retention with withdrawal, revocation and deletion requests. Distinguish access revocation, key destruction and peer-reported deletion; none proves that an untrusted party erased a plaintext copy it previously received. Do not promise perpetual storage or universal erasure. - **Operational independence:** account for shared providers, sites, administrators and recovery keys when counting independent copies. Bound storage, network egress, abuse and repair workloads; plan peer retirement and replacement before accepting long-term commitments. An initial pilot should use explicitly approved public project data and prove complete export and read-only recovery with the originating server unavailable. Private data requires its own security acceptance. Future writable failover needs a reviewed authority-transfer and writer-fencing protocol that prevents split-brain operation. ## Storage candidates, including Ceph Evaluate Ceph and other established storage components only when concrete capacity, site topology, latency, recovery goals and operating resources justify the choice. A site storage cluster, replication between cooperating sites and federation between independently governed operators have different trust and failure boundaries. Ceph object multisite is a candidate to investigate for cooperating sites; it does not by itself define project consent, independent ownership, complete application recovery, key custody or organization admission. Keep the project export and recovery contract portable across storage backends. No globally stretched cluster or shared database writer model is selected. ## Entry and expansion criteria 1. Complete the current platform and infrastructure work, with owner acceptance, reliable backups and demonstrated recovery in regular use. 2. Revisit this proposal with interested external projects and operators; define eligibility, capacity commitments and measurable recovery goals. 3. Review the threat model, full recovery format, retention rules and peer exit process before building a small opt-in public-data pilot. 4. Demonstrate recovery after loss of the originating site, export to an independent installation, stale or corrupt peer detection, and operator withdrawal. Record the limits as well as successful cases. 5. Consider wider admission, private data and writable failover separately, using the pilot's evidence and a sustainable support and funding plan.