RURAL that keeps running

Status: proposed architecture and source-backed research, 20 September 2026. The Operator specifically wants RURAL itself to keep operating across a decentralized network and supplied Morpheus as a reference. No distributed RURAL service or Morpheus integration has been implemented or deployed. This appendix extends The Visible World (not published).

1. The commitment we can engineer

RURAL should eventually function without the continued existence or permission of its original company, its default website, one gateway, one hosting provider or one founder key. Independently operated nodes should preserve accepted state, repair lost copies and continue serving within their declared failure envelope.

That is a stronger and more testable commitment than a marketing promise of being impossible to stop. Electricity, networking, available operators, sufficient replicas, correct software, keys and funding still matter. A globally partitioned network cannot both accept every conflicting write everywhere and preserve one immediate authoritative history.

Three states must be visible:

• Serving: the requested operation's availability and consistency conditions are met.

• Degraded: some operations remain possible, with explicit staleness, locality or capacity limits.

• Recoverable but unavailable: valid retained data can be restored, but the requested live service cannot currently be supplied.

A surviving encrypted file is not a continuously running database. A running endpoint with incomplete or divergent state is not proof of continuity either.

2. What Morpheus actually contributes

Morpheus's current node documentation describes a peer-to-peer AI inference marketplace: independent providers serve models, consumer/provider nodes route requests, and BASE contracts coordinate marketplace state. This is relevant to replaceable providers and individually operated agents. It does not establish a general-purpose persistent database hosting contract. Current node introduction.

The hosted inference API is explicitly a separate gateway product. Using its convenient endpoint introduces that gateway as an access dependency; running a consumer node provides a different route into the marketplace. We should evaluate the exact selected route rather than transfer a network-wide decentralization claim to every API client. Official gateway documentation source.

MRC 62 proposes a storage router and marketplace. MRC 64 proposes a broader Morpheus Virtual Machine spanning registries, intents, sessions and execution records, with heavy work off-chain. These are useful design directions; the inspected proposals do not prove that continuously hosted RURAL replicas, transactional storage or our recovery guarantees are available today. The older Morpheus whitepaper is marked superseded, so it is not used here as current implementation evidence. MRC 62, MRC 64.

Morpheus also documents hardware attestation of selected inference paths. Its own overview distinguishes attested software from answer quality and identifies external verification dependencies. Such attestation can contribute evidence about a remote execution environment; it does not establish database persistence, quorum safety, absence of hardware flaws or permanent availability. Official TEE overview source.

Proposed relationship: RURAL owns durable world state and its transaction semantics. Morpheus could supply optional inference and, if a suitable hosting contract is later verified, optional execution placement. Neither becomes a prerequisite for local CRUD or access to already-owned data.

3. Independently hosted database groups

The proposed unit of continuous operation is a database partition with a versioned replica-membership policy, authority domain, durable log, checkpoint manifests and client routing metadata. It is a logical service identity independent of any provider hostname.

For an initial managed, non-malicious deployment, a three-voter group can be designed to continue committing with two mutually reachable healthy voters after one fails. Durable acknowledgement requires the specified persistent quorum and correct fencing of obsolete leaders. A minority cannot commit authoritative writes. Independent reads can expose an explicitly labeled retained snapshot; authoritative reads need the protocol's freshness check. These properties are proposed requirements informed by crash-fault consensus, not an implemented RURAL Raft claim. Raft paper.

Independent operators improve fault diversity only when their failure domains are actually different. Three processes in one account or data centre are not three independent operators. Placement records should include operator, provider, region, power/network dependencies and correlated services where known; unknown independence remains unknown.

Provider loss triggers a visible repair workflow: choose an eligible replacement, transfer and verify a checkpoint, replay the committed suffix, confirm required durability, then change membership through the consensus protocol. An external scheduler cannot simply declare an empty replacement authoritative. Membership and routing epochs prevent old processes from continuing to accept valid writes after relocation.

Untrusted open providers are a different threat model. Crash-fault consensus does not tolerate arbitrary malicious replicas. Encryption protects confidentiality but does not force a provider to retain or correctly execute data. Before permissionless state execution, choose and verify an appropriate Byzantine protocol, independently verifiable execution scheme or explicitly trusted confidential-compute arrangement. Each adds assumptions, cost and operational dependencies. A signed false result remains false.

Ordinary query-executing replicas need plaintext while they evaluate a query. Transport and disk encryption do not conceal it from that executing host. Placement therefore must select owner-trusted operators, an explicitly accepted confidential-compute boundary, or a separately verified encrypted-computation protocol. Verifying a result's integrity alone does not provide input confidentiality.

4. Keep strong authority local to the invariant

Every person's private domain can have its own placement and availability policy. Shared text, analytics intake, a payment ledger and a governance register need not use the same consistency mode.

During a partition, a person may continue an independent local branch and later propose reconciliation. That branch must not be presented as a globally committed ownership transfer, payment or policy change. Existing independent domains can continue even if another domain loses quorum. Cross-domain workflows use explicit receipts and compensations unless a separately specified atomic protocol covers every participant.

For analytics, local producers may spool stable event identities while the authoritative group is unavailable. A spool receipt describes only that producer or collector's durability. Only the stronger commit receipt promises the corresponding replicated guarantee. Backpressure, spool exhaustion and retry expiry must remain visible.

This permits a network to remain useful while some services degrade. It does not manufacture uninterrupted strong writes to every object under every failure.

5. Code, data and discovery without one control server

An independently running network needs more than replica storage. The proposed distribution contract includes:

Discovery itself faces Sybil, eclipse, poisoning and denial-of-service attacks. Peer diversity and multiple bootstrap methods need adversarial tests; a DHT is not automatically safe or private. Global distribution of executable artifacts also requires an appropriate redistribution licence. This repository is currently UNLICENSED; this paper does not change its legal permissions or publish it. An explicit future licensing decision is necessary before claiming permissionless independent operation.

The resulting intranet is an application network of authenticated worlds, artifacts and services over normal available connectivity. It can route through different transports and providers without pretending to replace the physical internet.

6. Continuity has a budget and an owner

Each continuously hosted database needs a service budget: storage, CPU, repair bandwidth, replication, backups, discovery and operational reserves. Provider incentives must pay for useful verified service, not just a registration or a token balance.

Budget exhaustion has a contract. Notify before the reserve is consumed; suspend new expensive work; preserve export and recovery access within the paid retention window; allow migration; then apply the disclosed retention policy. No staking yield or token-price assumption guarantees perpetual hosting. Durable remote service has an ongoing cost even when an individual begins free locally.

The owner can stop their database, revoke sharing and request deletion subject to already disclosed recipient and backup constraints. Shutdown resistance protects against a single outside operator disabling everyone; it does not remove the owner's control or make private data permanently public.

The founder's loom must therefore gate specified optional features, not the right to start the core engine, decrypt user-owned data, renew ordinary read access or serve an existing valid database. An update-signing monopoly, expiring licence or compulsory activation server would contradict this continuity objective and must be visible in the dependency audit.

7. Tests that earn the claim

Run these as repeatable multi-host tests with real failure domains before using the claim commercially. Record recovery time, acknowledged-data loss, stalled operations, repair bytes and costs. Separate adversarial-provider tests from crash tests.

The long-term target is precise: RURAL can outlive its original operator and keep serving from independently controlled infrastructure within a published failure envelope. Morpheus is a valuable reference and possible optional collaborator. RURAL's own durable state, recovery and authority contracts must make the promise true.