• Archive-Backed Identity, Publishing, and Messaging
• Core Principles
  • 1. Relays Are Non-Authoritative
  • 2. Archives Are the Source of Truth
  • 3. Local Databases Are Caches
• Supported Event Kinds
• Manifest Types
  • Canonical Manifest
  • History Manifest
  • Tombstone Manifest
• Archive Layout
  • Manifest locations
  • Archived event JSON
• Rehydration Protocol (Deterministic Rebuild)
  • Rebuild Mode (DB empty or reset)
  • Refresh Mode (normal operation)
• Invariants
  • Archive Invariant
  • Deletion Invariant
  • Determinism Invariant
  • Encryption Invariant (DMs)
• Kind-Specific Rules
  • kind:0 (Profile)
  • kind:1 (Notes & Replies)
  • kind:4 (Direct Messages)
  • kind:30023 (Articles)
• Tombstone Protocol (Anti-Resurrection)
• Performance Model
• Key Rotation (Future Protocol)
• Non-Goals
• Summary

§Archive-Backed Identity, Publishing, and Messaging

Andrew G. Stanton - Jan. 11, 2026

This document defines the protocols and invariants used by Continuum to provide durable, sovereign publishing and messaging on Nostr.

Continuum treats relays as caches, databases as disposable, and archives as the source of truth.

The goal is deterministic reconstruction of authored history even if:

• relays forget
• backups reappear
• local databases are wiped
• keys are rotated
• events are intentionally deleted

§Core Principles

§1. Relays Are Non-Authoritative

Relays are used for:

• discovery
• low-latency sync
• interoperability

Relays are never trusted for durability.

§2. Archives Are the Source of Truth

If an event exists in the archive, it exists. If it does not, it is considered lost (or intentionally deleted).

§3. Local Databases Are Caches

The local database may be deleted at any time. All state must be reconstructible from:

• manifests
• archive
• optional relay sync

§Supported Event Kinds

Continuum guarantees durability and reconstruction for the following authored kinds:

Other kinds may be supported later, but are not required for identity continuity.

§Manifest Types

Manifests define the authoritative set of events.

§Canonical Manifest

Used for versioned kinds where only the latest event is valid.

Used for:

• kind:0 (profile)
• kind:30023 (articles)

Example semantics:

• one entry per logical object
• latest event wins

Canonical files typically map:

logical_id → latest_event_id + year

§History Manifest

Used for append-only kinds.

Used for:

• kind:1 (notes & replies)
• kind:4 (DMs)

History files are stored as:

history-YYYY.json

Each entry minimally includes:

• event_id
• created_at

§Tombstone Manifest

Used to preserve deletion intent.

If an event_id appears in the tombstone ledger:

• it must never re-enter active state
• even if found in relays or backups

Tombstones override all other inputs.

§Archive Layout

For a given npub, Continuum archives events by kind and year.

§Manifest locations

/pro/nostr/{npub}/{kind}/canonical.json
/pro/nostr/{npub}/{kind}/history-YYYY.json
/pro/nostr/{npub}/tombstone/deleted_event_ids.txt

§Archived event JSON

https://{year}.mycontinuum.xyz/archive/pro/nostr/{npub}/{kind}/{event_id}.json

The archive stores full raw event JSON exactly as published.

§Rehydration Protocol (Deterministic Rebuild)

§Rebuild Mode (DB empty or reset)

1. Sync from relays (best effort, fast path)
2. Load manifests
3. Apply tombstones
4. Compute missing:

missing = manifest_ids − db_ids − tombstones

5. Fetch missing events from archive
6. Insert into DB and mark archived = true
7. Assert invariants

§Refresh Mode (normal operation)

1. Sync recent events from relays
2. Apply tombstones
3. Do not scan archive
4. Archive is only consulted if missing events are detected

§Invariants

§Archive Invariant

If an event is listed in a manifest and not tombstoned, it must be retrievable from:

• relay OR
• archive

§Deletion Invariant

If an event is tombstoned, it must never reappear, regardless of source.

§Determinism Invariant

Given the same archive + manifests, rebuild produces the same DB state.

§Encryption Invariant (DMs)

Encrypted content may be archived safely because:

• payloads are ciphertext
• archive adds no new disclosure risk

§Kind-Specific Rules

§kind:0 (Profile)

• Versioned
• Canonical manifest required
• Latest event wins
• Archived to prevent identity loss if relays drop profile

§kind:1 (Notes & Replies)

• Append-only
• History manifests only
• Replies are just notes with e/p tags
• All authored notes are archived

§kind:4 (Direct Messages)

• Append-only
• History manifests only
• Encrypted payloads stored verbatim
• Both sent and received messages may be archived
• Attachments referenced by encrypted envelopes

§kind:30023 (Articles)

• Versioned by logical slug (d tag)
• Canonical manifest defines latest version
• Older versions may remain archived but inactive

§Tombstone Protocol (Anti-Resurrection)

Tombstones preserve intentional deletion.

Rules:

• Tombstones are stored in the archive
• Tombstones override:
• relay imports
• backup imports
• historical replays
• Tombstones are applied before rebuild or refresh

This prevents “zombie” events from reappearing.

§Performance Model

• Relays are the hot path (fast)
• Archive is the cold path (slow, guaranteed)
• Archive fetch is performed only when DB is missing known events

This ensures:

• fast normal operation
• reliable recovery under failure

§Key Rotation (Future Protocol)

Key rotation is enabled by archive durability.

Planned rules:

• Old keys become frozen historical identities
• New keys take over forward activity
• Continuity is proven via signed linkage events
• Archive preserves all prior authorship

Key rotation does not erase history.

§Non-Goals

Continuum does not attempt to:

• archive the entire social graph
• preserve likes/reactions by default
• maximize engagement or reach
• replace clients or relays

It focuses on sovereign continuity, not feeds.

§Summary

Continuum implements a manifest-driven, archive-backed protocol stack that guarantees:

• authored content can be reconstructed
• deletion intent is preserved
• encrypted messages remain recoverable
• identity survives relay churn
• databases are disposable

Relays may forget. Archives do not.