coop/docs/community-history-sync-plan.md

Community history and live sync

A community panel currently shows a short, stale slice of a channel: often only the newest handful of wraps a relay happened to replay, no older history, no messages for private channels, and nothing at all after a rekey. The reference client (soapbox-pub/armada, src/concord/lib/channelSync.ts and friends) pages history from relays into a local store, keeps a cursor per channel, and keeps the timeline live. This document is the diagnosis and the plan to get there.

Revision 2. Three corrections to the first revision, all of them structural:

1. concord stays a thin protocol layer. Relay and database operations do not belong in it. Revision 1 put the whole paged fetch — fetch_page, Window, WrapPage, Walk, the per-page subscriptions — into concord/src/store.rs, next to a local cache layer that writes to the client database. That is now framed as the mistake it is: concord keeps wire formats, crypto, and the plain community document; community keeps every Client.
2. One notification pump, subscriptions that stay. community already has a global relay notification handler (CommunityRegistry::handle_notifications). The history path must go through it: subscribe to a filter, read the page back from the local database, keep the live subscription alive for new data, and let the pump — not a hand-rolled per-relay wait loop inside the protocol crate — be the only consumer of relay notifications.
3. Cold asks for everything, warm asks for what is new. Opening a community with nothing cached subscribes wide (since = None) and pages down; opening it again asks only for the region since the cursor. Exhaustion still has to be earned (§3).

And one correction to a claim in revision 1: an auth-required CLOSE is not a failure. The SDK marks that subscription for resubscription and re-issues the REQ under the same id once the AUTH handshake completes — for auto-closing subscriptions too, which is what a page REQ is (nostr-sdk/src/relay/inner.rs handle_relay_message → MarkAsClosed, and the auto-closing handler's RelayNotification::Authenticated arm). Only AuthenticationFailed ends a relay's wait, and it is reported rather than rendered as an empty channel.

Revision 3. One more correction, from a review of what revision 2 landed:

4. Time is a type, not a u64 with the unit in its name. The read path held three different units in the same u64: HeldKey/HeldRoot.retired_at held seconds (but were compared with a Timestamp through .as_secs()), ChannelCursor held milliseconds that were only ever seconds multiplied by a thousand, and CommunityState.channel_cuts held epochs. Every filter boundary divided by a thousand on the way out. §10 types the time fields (Timestamp, Epoch) and leaves a millisecond only where a millisecond is real.

Revision 4. The six phases landed and the symptom was still there: a community showed its full history, its full roster, and never a new message. The audit that followed found the read path asking for addresses nobody writes to, plus two smaller reasons the same shape comes back (§11):

5. A public channel's plane follows the ROOT epoch, not the epoch its material names. held_keys derived every held root's plane at the channel's recorded epoch, and channel_secret sealed at it, so after a Refounding the current root's plane was asked for and written to at the retired epoch — an address no other client reads. The channel kept everything written before the rotation and received nothing after it, while the Control and Guestbook planes (which derive from the roots directly) stayed current: the roster looked complete while the room looked dead.
6. The walk never reported its floor. Walk::accept computed the page's oldest wrap into a local and never into Walk::oldest, so every page reported oldest: None. The older pass had no point to resume below (scroll-up could only re-read the local cache), the bridge never ran (a burst larger than one page left a hole the cursor then sealed as covered), and exhausted could never be earned.
7. Two ways for the live path to go quiet are closed. A cursor is clamped to the local clock, so a peer's future stamp cannot bound every later filter below a region that has not happened; and a community whose relays go silent re-issues its standing REQ, because a subscription that died without saying so is indistinguishable from a quiet one.

Read path today (phase 1 landed the walk, phase 2a moved each layer, phase 2b swapped the transport and put the pump in charge of settling pages, phase 3 added the rekey watch and held epochs, phase 4 made an empty or unreadable room say so, phase 5 typed the times they all compare, revision 4 fixed the plane a public channel is read at once its root has rotated):

CommunityPanel::load              community_ui/src/lib.rs:192
  -> Community::sync_channel      community/src/community.rs:220
       -> sync_round              community/src/community.rs      (purge_expired,
                                                                  Window::opening)
            -> history::page      community/src/history.rs      (one REQ per page
                 -> ask_page      community/src/history.rs      over the community's
                                                                  relays, registered
                                                                  in the page registry)
                 -> PageRegistry  community/src/history.rs      (EOSE / CLOSED arrive
                                                                  through the pump)
                 -> client.database().query(filter)          (the page)
            -> cache::cache_rumor community/src/cache.rs
  -> Community::timeline          community/src/community.rs:370
       -> cache::query_rumors     community/src/cache.rs
       -> cord03::fold            concord/src/cords/cord03.rs

live wire                         community/src/lib.rs:309  (sync_subscriptions)
  -> sync::live_filter            community/src/sync.rs      (both wrap kinds,
                                                                private channels,
                                                                Window::opening,
                                                                limit LIVE_REPLAY)
  -> rekey::watches               community/src/rekey.rs     (base next epoch +
                                                                a channel window per
                                                                held root)
  -> pump                          community/src/lib.rs:433  (routes by subscription
                                                                id, batches within
                                                                PUMP_WINDOW, settles
                                                                pages by EOSE/CLOSED)
  -> rekey::adopt                 community/src/rekey.rs     (reads the rekey wraps
                                                                back from the database,
                                                                adopts one epoch at a
                                                                time)

scheduler                         community/src/lib.rs      (one tick per
  -> Community::tick              community/src/community.rs   MIN_ROUND_INTERVAL;
                                                                a channel that has
                                                                passed STALE_AFTER
                                                                re-folds and re-rounds)

What is wrong today

#	Finding	Status	Evidence
1	History was fetched at most once per channel, only when the cache was completely empty, so the relay round was almost always skipped.	fixed in phase 1 (sync_channel runs per open)	community/src/community.rs:218
2	That one round was one shallow page with no continuation.	fixed in phase 1 (paged walk + cursors)	community/src/history.rs
3	The timeline was a fixed 200-row window with no way to ask for older.	fixed in phase 1 (timeline + has_more + load-older)	community_ui/src/lib.rs:263
4	Cursors existed but nothing used them; no "has more" signal.	fixed in phase 1	community/src/community.rs:337
5	Private channels are never subscribed and never folded: planes() skips channel.private, so a private channel gets no live REQ and no cache_rumor from the subscription.	fixed in phase 2b (planes derives a private channel's plane from the held key; it is subscribed, paged and folded like a public one)	community/src/sync.rs
6	The standing REQ asks for kind 1059 only, and the pump drops anything that is not 1059, so 21059 (ephemeral) wraps can never be routed even though the read path asks for both kinds.	fixed in phase 2b (live_filter/plane_filter ask for both kinds; the pump routes by subscription id and never inspects the kind)	community/src/sync.rs, community/src/lib.rs
7	A rekey strands history: ChannelKeyRef holds one epoch/key, channel_secret returns one plane, sync::refresh overwrites a held key in place, and the rekey pseudonyms are never watched.	fixed in phase 3 (priors/held_roots + retired_at, the rekey watch, and strict one-epoch-at-a-time adoption)	community/src/rekey.rs, concord/src/state.rs
8	"No messages yet" is three different states: unreadable wraps are dropped silently, a failed round is logged, and the panel renders all of them as an empty room.	fixed in phase 4 (WrapPage/Progress/Snapshot carry unreadable, the community exposes progress/unreadable/missing_key/channel_removed_at/removed_at/stranded, and the panel renders a reason plus a retry instead of an empty room)	community/src/community.rs:46-53, community_ui/src/lib.rs:235
9	A new message replaced the whole timeline and forced scroll_to_end().	fixed in phase 1 (FollowMode::Tail, in-place merge)	community_ui/src/lib.rs:121, :364-411
10	Backfill fetched through client.fetch_events(..) with ReqTarget::auto, i.e. every relay in the pool.	fixed in phase 1 (relay-scoped, no fetch_events anywhere)	community/src/community.rs:262
11	The local cache document is authored by a process-random key, so the same rumor cached in two runs is a different event id and the store keeps both copies; fold then re-reads all of it on every inbound wrap.	fixed in phase 2a (one fixed cache key)	community/src/cache.rs
12	cache::purge_expired is never called, so expired rows only drop at fold time, never from disk.	fixed in phase 2b (sync_round sweeps the channel before it starts)	community/src/community.rs
13	Every relay and database operation lived in concord: fetch_page installed its own subscriptions and read the client database, cache_rumor/query_rumors/save_state/load_states wrote and read it. Consequences: the pump could not see a page's REQ (so the panel's live view and the history path were two unrelated worlds), each page hand-rolled a per-relay notification loop, and the protocol crate could not be built or tested without a Client.	fixed in phase 2a (split into concord/src/state.rs, community/src/cache.rs and community/src/history.rs; the page REQ still waits on its own loop — §2 moves it into the pump)	concord/src/state.rs, community/src/{cache,history}.rs
14	The fold is O(history): sync::fold re-reads every wrap in the community's planes and NIP-44-opens each one on every inbound wrap, purely to cache channel rumors and observe their authors for the member list. The live REQ replays the plane on every start, so this happens on every app run and every burst of messages.	fixed in phase 2b (channel wraps are opened once, on the way in; fold reads already-cached authors and times from cache::wrapper_index instead of opening them again)	community/src/sync.rs, community/src/cache.rs
15	A public channel's plane was derived at the channel's recorded epoch for every held root, so after a Refounding the current root's plane was subscribed, paged and sealed at the retired epoch: no live events, no new pages, and no cursor ever written for the channel — while the history of the prior epoch and the wholeControl and Guestbook planes still read.	fixed in revision 4 (§11)	concord/src/state.rs (held_keys), community/src/community.rs (channel_secret)
16	The walk never reported its floor (Walk::oldest was computed into a local), so the older pass never ran, the bridge never healed a gap, and exhausted was never earned.	fixed in revision 4 (§11)	community/src/history.rs (Walk::accept)

Findings 1-4 and 9-10 are the user-visible symptom and were phase 1; 13 is where that work landed in the wrong crate; 5-7 are why some channels look empty forever; 8 is why a failure looks like an empty room; 11 and 14 are why the store and the fold get slower the fuller a community is; 15-16 are why a rotated community reads as a complete archive that stopped receiving.

What the reference client does

Observed in Armada (src/concord/lib/channelSync.ts, src/concord/hooks/useChannel.ts, src/wire/spec.ts, src/concord/hooks/useRekey.ts):

Mechanism	Reference detail
Local-first read	the query resolves on an IndexedDB read (WINDOW_SIZE = 100 rows) and network catch-up runs behind it, so the panel never waits on relays
Three-pass round	newest page → bridge (since: cursor.newest, until: newest.oldest - 1, healing an offline burst larger than one page) → older (until: cursor.oldest, resumed on later rounds)
Page size	BACKFILL_PAGE = 50 wraps per relay per page, BACKFILL_MAX_PAGES = 20 per round, LOAD_OLDER_MAX_PAGES = 6 per scroll-up
Cursors	{ newest, oldest, exhausted } per channel, persisted locally, merged monotonically (newest forward only, oldest back only, exhausted sticky), advanced only when the region is verifiably complete
Failure semantics	a failed relay blocks exhaustion and cursor advancement; an all-empty round is a failure, never exhaustion (otherwise a notification-only room is sealed as "exhausted" and never pulls its history)
Page-by-page decode	each page is decrypted and committed as it lands; a deep round paints as it goes
Scroll-up paging	local store first (pure re-read), relays only when the store is exhausted
Side events	messages and their decorations (edits/deletes/reactions) get separate budgets (×4) so reaction floods cannot displace rows and edits outside the row window still fold
Live wire	one REQ per relay with the channel's current stream addresses; every held epoch stays in the decode set; retired epochs are asked once more, then frozen out of the REQ
Rekeys	a watch on baseRekeyGroupKey(root, id, rootEpoch + 1) plus CHANNEL_REKEY_LOOKAHEAD = 8 epochs of channel rekey pseudonyms; adoption clears exhausted and re-runs the channel's sync round
Polling	a scheduler re-runs a channel round when it is older than 5 minutes, at most once per 30 s

The flow we are converging on: subscribe, then read the database

The Signed app (crates/signed_state/src) is the model, and it maps onto what community already has:

Signed	coop
Backend owns the Client and runs one notification pump that batches relay events into BackendEvent::NostrUpdate(Vec<Update>) within PUMP_DEBOUNCE = 200ms	state::NostrRegistry owns the Client; CommunityRegistry runs the pump
Backend::subscribe_bootstrap(filters) / sync_bootstrap(filter) install the REQ; the pump delivers what relays send into the database	CommunityRegistry::sync_subscriptions installs the live REQ; a round installs a page REQ
Stores (RepoListStore, ProfileStore) subscribe to backend events and re-query only client.database(), never the network	Community::refresh → community::cache reads
RefreshGate (running/dirty, one coalesced follow-up)	Community::{refresh_task, dirty} and Round{running, queued, waiters}
A store never awaits a relay: it reacts to a batched update and reads the database	a round awaits its own page's EOSE (through the pump) and then reads the database

Two consequences for this codebase, stated as rules:

• A relay is only ever asked by a subscription. No fetch_events, no ReqTarget::auto, no per-relay notifications() loop outside the pump.
• Every read is a database read. Cursors, folds, timelines, member lists and pages are computed from what the database holds after a subscription put it there.

The fix

1. concord keeps the protocol, community keeps the relays and the database

concord gets one rule: no Client, no database, no subscription. Its remaining job is wire formats, crypto and the community document. Everything that talks to a relay or the local store moves one crate up:

Today	Target
concord/src/store.rs: CommunityState, ChannelKeyRef, ChannelCursor (+ merge), from_genesis, from_join_material, apply_fold, floors, identifier, list_entry	concord/src/state.rs — the document and its pure folds, no I/O
cache_rumor, purge_expired, query_rumors, save_state, load_state, load_states, state_identifier, LOCAL_KEYS, the c/t/k/e tags, STATE_PREFIX	community/src/cache.rs — the local cache and the local documents
Window, WrapPage, fetch_page (renamed history::page), wrap_filter, ingest_page, auth_required, history_subscription, within, Walk, Walker	community/src/history.rs — the page REQ and the walk
planes, subscription_filter, subscription_id, community_of, subscribe_list, load, fold	stay community/src/sync.rs, extended
Signal, handle_notifications, sync_subscriptions, track, reset	stay community/src/lib.rs, extended into the pump (§2)
The Walk/serve_page tests	move to community/src/history.rs; the ChannelCursor::merge and from_join_material tests stay with the document; the load_states test moves to community (it needs a database)

Notes:

• The document module is concord::state; items are imported by full path (use concord::state::{ChannelCursor, CommunityState};) so the separate state crate keeps state::… for itself.
• concord's dependency list shrinks: futures and smol are used only by the relay code that moves out (smol stays, as a dev-dependency, for the cord tests).
• ChannelCursor stays a plain data type inside CommunityState (it is persisted, and its merge is pure). What moves out is when to advance it — that is community's judgement, not the protocol's.
• Two deviations from the table, both to keep the layers honest. STATE_PREFIX, state_identifier and CommunityState::identifier stay in concord::state: they name the document's own local key, and the document cannot reach up into community to borrow them. And community's cache and history are pub mod, so the surface that used to be concord::store is still reachable (a private module turns purge_expired and load_state into dead code).
• docs/concord-usage.md documented store::fetch_page; it was updated in the same change.

2. One notification pump, and subscriptions that stay

Subscription ids and their routes

Subscription	Id	Owner	Lifetime
Community List	concord/list (existing)	registry	signer lifetime
Live planes	<community hex> (existing sync::subscription_id)	community	until the signer or the plane set changes; kept alive
History page	concord-history-<n> (opaque, unique)	the round	one page; auto-closes on EOSE
Rekey watch	rekey-<community hex, first 32> (opaque)	community	kept alive while the community is tracked

route_of(&SubscriptionId) -> Option<Route> parses the two standing ids into Route::{List, Community(CommunityId)}, so the pump routes an event by subscription id and never has to guess from the event itself (which is what keeps another crate's subscription out of a community's fold).

A page id cannot be parsed this way, and that is deliberate: a NIP-01 subscription id is capped at 64 characters, which a community hex alone fills, so an id cannot carry both a community and a channel. A page's id is therefore an opaque concord-history-<n> and the pump resolves it through the page registry instead — PageRegistry, a HashMap<SubscriptionId, flume::Sender<PageReport>> shared between the registry and the rounds. PageReport { relay, outcome } carries facts; the walk decides what they mean. A report for an id nobody is waiting on is dropped at debug, which is the ordinary case when a round is cancelled. Phase 3 added the Rekey route the same way, through a parallel rekey::WatchRegistry that maps an opaque rekey-<32 hex> id back to its community: the whole id is sent to the relay, so a page's rule applies — an id cannot carry a community hex and stay within the cap.

The pump

CommunityRegistry::handle_notifications becomes the only consumer of client.notifications(), and it handles the message variants it drops today (route and the window loop live in community/src/lib.rs):

fn route(notification, pages, batch) -> Flow {
    match notification {
        ClientNotification::Event { subscription_id, .. } => match route_of(&subscription_id) {
            Some(Route::List) => batch.list = true,
            // Only the database is told; the fold reads it when the window closes.
            Some(Route::Community(id)) => { batch.communities.insert(id); }
            // A page's event needs no routing at all: the subscription already put
            // it in the database, and the round reads it back from there.
            None => {}
        },
        ClientNotification::Message { relay_url, message } => match *message {
            RelayMessage::EndOfStoredEvents(id) => pages.deliver(&id, relay_url, Settled::Replayed),
            RelayMessage::Closed { subscription_id, message }
                if !auth_required(&message) =>
            {
                pages.deliver(&subscription_id, relay_url, Settled::Refused(message.into_owned()));
            }
            // auth-required: the SDK re-issues this REQ under the same id after
            // AUTH, so the page keeps waiting for the resubscribed answer.
            _ => {}
        },
        ClientNotification::Shutdown => return Flow::Stop,
    }
    Flow::Continue
}

• Kind 1059 and 21059 both route (finding 6); the previous revision's "drops every non-1059" check goes away entirely.
• The window is a fixed PUMP_WINDOW (200 ms, the reference app's value) from the first notification of a burst, not a debounce that a steady stream can keep extending. What it produces is one Signal::Event(id) per community that saw an event plus one Signal::List — so a burst of fifty messages costs one fold, not fifty. Community::refresh keeps its own dirty follow-up.
• Page verdicts (Message) are delivered immediately, inside the window, so an EOSE is never held up by a burst on another subscription.

The live REQ stays

CommunityRegistry::sync_subscriptions keeps installing one REQ per community over state.relays (ReqTarget::manual, never auto), and it keeps that subscription alive: a long-lived subscription is re-sent by the SDK after a reconnect and after a successful AUTH, which is exactly the "resync on socket reopen" behaviour the reference client implements by hand.

What changes is the filter: it now asks for both wrap kinds, includes private channels (§5), and carries a window and a bound:

/// What a community with no history in the database asks for: everything a relay
/// stores, bounded per relay so a cold start is not a whole plane.
const LIVE_REPLAY: usize = 500;

impl Window {
    /// The window a channel is opened with.
    ///
    /// Nothing held: ask wide, the round pages down from there.
    /// Something held: ask only for what is new, plus an overlap for the seam.
    pub fn opening(cursor: ChannelCursor) -> Self {
        match cursor.newest {
            Some(newest) => Window {
                since: Some(newest - CURSOR_OVERLAP),
                until: None,
            },
            None => Window::default(),
        }
    }
}

/// The window a community's standing subscription opens with.
///
/// One REQ covers every channel, so the floor is the **oldest** held cursor:
/// starting any newer would skip a channel's new region. A channel with no
/// cursor is left to its own round. `since = None` only when nothing is held.
pub fn live_window(state: &CommunityState) -> Window {
    let floor = state
        .channels
        .iter()
        .filter_map(|channel| state.cursors.get(&channel.id)?.newest)
        .min();

    match floor {
        Some(floor) => Window {
            since: Some(floor - CURSOR_OVERLAP),
            until: None,
        },
        None => Window::default(),
    }
}

The floor is computed when the REQ is installed (on open, on a plane change, on a signer change) and is not recomputed as cursors advance: a live REQ that is re-subscribed on every cursor merge would replay the seam on every message, and the region it did not cover is the round's job, not the live REQ's. Note that a since bounds only the stored replay; live events arrive whatever it is, so a channel with no cursor still receives new messages and gets its history from its own round.

3. A channel round over page subscriptions

Community::sync_channel(&self, channel, intent, cx) keeps its shape and its coalescing (Round { running, queued, waiters }, one round per channel, a request that arrives mid-round re-runs it once), and the panel keeps its two intents:

pub enum Intent {
    /// Opening a channel: newest data, the bridge, then a bounded older walk.
    CatchUp,
    /// Scrolling up: continue older history, at most `pages` pages.
    Older { pages: usize },
}

What changes is the transport. A page is now:

1. the round registers a flume::Sender<PageReport> in the page registry under the page's id, before the REQ goes out;
2. it installs one REQ per page over the community's relays (client.subscribe(ReqTarget::manual(..)).with_id(page_id).close_on(ExitOnEOSE + PAGE_TIMEOUT)), after checking each relay is in the pool (the pool refuses a target it does not hold, and would fail the whole REQ);
3. the pump delivers one report per relay that settles (EOSE, or a non-auth CLOSED); the round waits until every relay it asked has settled or PAGE_TIMEOUT passes, then unregisters;
4. it reads the page from the database with the same filter the REQ used.

A relay the pool does not hold is settled as refused up front rather than failing the page: its region was never read, so it blocks exhaustion like any other dead relay.

Rules carried over from phase 1, none of which are negotiable:

• A page boundary is exclusive. until = oldest_seen - 1, so consecutive pages never share an event and the walk terminates.
• exhausted is earned. Only raw > 0 plus a bottomed-out page on every relay that answered may set it. An all-empty page sets failed, so the next round re-asks the same region instead of sealing the channel at "no more history".
• A relay that never answered (deadline) or refused (any CLOSED that is not auth-required) is out of the walk and blocks exhausted; it is counted in Progress.errors.
• auth-required is not a failure. The relay stays in the walk and the page waits for the re-issued REQ's EOSE. Only AuthenticationFailed settles a relay as refused, and it is surfaced.
• One cursor, one filter per page. The database is not per relay, so per-relay cursors do not exist; a relay is a source that fills the database.
• newest advances only on a complete round (!newest.failed && bridge.exhausted), oldest only walks down on a complete page, and exhausted is cleared by a rekey.

The cold/warm distinction is now the window rule rather than a special case:

State of the channel	Window
no cursor, nothing cached (cold open)	Window::opening → since = None: subscribe for everything the relays have, then page down
cursor with newest (warm open)	Window::opening → since = newest - CURSOR_OVERLAP: new data only
cursor with oldest	Window::older_than(oldest): older data, on demand
a hole between saved.newest and the newest seen	Window::between(..): the bridge

So an open does two things, and they follow the same rule: it makes sure the live REQ is installed — wide when nothing is held, which is where "subscribe to get all data" comes from — and it runs a round whose newest pass asks only for the region the live REQ did not already cover (a warm open therefore replays nothing: the REQ is already streaming).

And the passes fall out of that rule:

• Newest pass (CatchUp): one page at Window::opening(saved). Cold, this is "get all data"; warm, this is "get only new data".
• Bridge: while the previous page was full and still above saved.newest, keep walking down with until = oldest - 1, bounded by CATCH_UP_PAGES. A short page ends it, which is what lets newest advance.
• Older pass: resume at saved.oldest.or(oldest_seen) and walk down, bounded by CATCH_UP_PAGES on a catch-up and LOAD_OLDER_PAGES on a scroll-up.

Sizes stay the reference numbers: PAGE_WRAPS = 50, CATCH_UP_PAGES = 20, LOAD_OLDER_PAGES = 6, CURSOR_OVERLAP = 60s.

Known limitation, unchanged and deliberately deferred: the bridge is bounded by CATCH_UP_PAGES, so an offline burst larger than CATCH_UP_PAGES * PAGE_WRAPS (1,000 wraps) is not repaired by one round and does not heal later (the bridge restarts from the same point). Fixing it needs a fourth cursor field recording how far a partial repair walked. One cheap improvement belongs in phase 2b: skip the older pass entirely when saved.exhausted is already set.

4. The read path

Unchanged from phase 1, moved intact:

pub struct Timeline {
    /// Oldest first, ready for a bottom-aligned list.
    pub messages: Vec<ChatMessage>,
    pub has_more: bool,
}

pub fn timeline(&self, channel: &ChannelId, before_ms: Option<u64>, limit: usize, cx: &App)
    -> Task<Result<Timeline>>;

• Reads limit + 1 rows to compute has_more, plus the side-event budget over the same span (SIDE_EVENT_FACTOR = 4), folds with cord03::fold (unchanged — it already resolves edits, deletes and reactions), reverses, returns.
• TIMELINE_PAGE = 100 is the first paint; older history stays on disk and comes back when the user scrolls up.
• The panel's only read is timeline.

5. Live completeness

• Private channels get a plane. sync::planes derives one per held epoch (the current key plus every priors entry), and a public channel one per held root, so a rotation never blanks a plane; a private channel is subscribed and folded exactly like a public one (finding 5).
• Both wrap kinds. The filter asks for KIND_WRAP and KIND_WRAP_EPHEMERAL in the live REQ and in every page REQ, and the pump routes both (finding 6).
• Community relays only. The live REQ and every page REQ use ReqTarget::manual over state.relays; a relay outside the community is never asked (finding 10).
• Expired rows are swept on the open and round cadence with cache::purge_expired (finding 12).
• A stable cache key. One local signing key persisted in the config dir replaces LazyLock::new(Keys::generate) (finding 11); the same rumor cached twice then has one addressable coordinate, so save_event replaces its predecessor instead of adding a copy per app run.

6. Held epochs and rekey adoption (phase 3) — landed

The client has to be able to read the epochs it is supposed to read, and learn the next ones:

• ChannelKeyRef gains #[serde(default, skip_serializing_if = "Vec::is_empty")] priors: Vec<HeldKey> where HeldKey { epoch: Epoch, key: [u8; 32], retired_at: Option<Timestamp> }, and CommunityState gains the same shape for roots (HeldRoot { epoch, key, control_pk, retired_at }). channel_secretreturns every held epoch,history::pagealready takes&[(Epoch, [u8; 32])], and sync::refreshstops overwriting a held key in place and pushes the old one ontopriors`.
• retired_at is a read cutoff. The reference retires the key a rotation steps off at the rotation's own publish time: nothing sealed under that key after it is read again. The read side needs the same floor: a wrap at epoch e whose created_at is past priors[e].retired_at is refused, at both the page and the fold.
• The rekey watch is a subscription too: one long-lived REQ per community over its relays for authors(rekey pseudonyms), kinds([KIND_WRAP]), where the authors are cord06::rekey_group(RekeyScope::Base, held_root, id, epoch + 1) and — for every private channel and every held root (a Refounding seals channel rekeys under the prior root) — cord06::rekey_group(RekeyScope::Channel(channel), held_root, channel, epoch) for epoch in held_epoch + 1 ..= held_epoch + REKEY_LOOKAHEAD (8).
• Adopt strictly, one epoch at a time, off the key actually held: cord01::open_wrap → cord06::parse_rekey_chunk → cord06::collect_rotations → is_complete → rotation.continuity(held_epoch, held_key) must be Extends (Gap is fetched, never waived; Fork resolves with cord06::fork_winner's lowest-key rule) → cord06::find_my_blobs + open_blob → KeyDelivery.
• Persist per delivery, then re-install the subscription (the plane set changed), clear that channel's exhausted, and run a CatchUp round for it.
• Two terminal states, both persisted and both shown, never rendered as an empty timeline: removed (cord06::am_i_removed on a complete rotation at/after my join whose rotator outranks me — added_at_ms and rekey_authorized already carry the comparison) and stranded (a complete rotation ahead of my epoch that predates my join and carries no blob for me, which says the invite link is out of date).

What landed. HeldKey { epoch, key, retired_at } and HeldRoot { epoch, key, control_pk, retired_at } live in concord::state; ChannelKeyRef gained priors and CommunityState gained held_roots, channel_cuts, removed_at and stranded. CommunityState::roots() and held_keys(channel) are the read surface: a private channel returns its current key plus every prior, a public channel one entry per held root. sync::planes derives a plane for each, history::page takes &[HeldKey] and refuses a wrap sealed under a retired key after its cutoff, and sync::fold applies the same cutoff. sync::refresh no longer overwrites a held key in place — it pushes the superseded one onto priors — and a recorded channel_cuts entry keeps a stale grant from merging a removed channel back.

The wire side is community/src/rekey.rs: watches(state) builds the base next-epoch address plus a 1..=8 channel window under every held root, watch_filter is the one standing REQ over the community's relays, and adopt reads the delivered wraps back out of the database and walks each scope forward. CommunityRegistry installs the watch beside the live REQ when a community's plane set changes, routes its events to Signal::Rekey through the pump, and Community::merge_adoptions folds the result in, persists it, clears the moved cursors' exhausted verdicts, and runs a CatchUp for the active channel.

Three deviations from the sketch above, all of them smaller than planned:

• The rekey watch is one subscription per community, not per scope. The base and every private channel ride the same authors filter; the wraps are addressed by pseudonym, so one REQ covers them all and one watch_filter rebuild covers every adoption. The id is opaque (rekey-<32 hex>) and resolves through rekey::WatchRegistry for the same 64-character reason a page id does.
• A removal is judged without continuity, a strand with it. Adoption requires Extends; the removal/strand decision considers every complete authorized rotation at the target epoch except one whose prevcommit forks (which is neither, and acting on it is how a member ends up on a fork). A member who missed a link is still removable — the reference's own channel watcher treats "past my epoch" as the removal test.
• Adoption chains within one pass. walk loops held + 1 while each step is adoptable, so a member who missed several rotations catches up in one database read instead of one pass per poll. The lookahead window is what feeds it.

The writer (phase 6) — landed

Phase 3 gave the client a receiver; phase 6 gives it a hand. rekey::rotate builds the rotation from the key the client actually holds and publishes it, and Community::rotate is the entry a moderation surface will call:

• One plan, drawn in the protocol crate. cord06::plan_rotation(scope, epoch) mints what the rotation delivers — a Refounding (new root and control pair) for a base scope, a fresh key for a channel — beside plan_refounding, which is now the base arm of it. No caller ever holds a rotation secret before the rotation exists.
• Authority first, and the same authority the receiver applies. Rewrite::authorized runs cord06::rekey_authorized under permissions(scope) — the same list adopt now walks with, shared instead of written twice — so the client cannot publish a rotation it would not itself adopt. Community::rotate adds the three states the role fold cannot see: a removal, a strand and a ban.
• One blob per recipient, and the rotator is one of them. A rotation that delivered no blob to its own rotator would strand them, so the writer refuses one. Staff get the new Control Plane root beside the key, everyone else gets the key alone.
• A refounding carries its heads. carry_heads reads the control editions back out of the store, picks the ones the settled floors name, and compacts them onto the new epoch's groups. Without it the new Control Plane starts empty and the next reader that does not hold the old root folds no roles, metadata or banlist at all. (compact re-signs nothing, so this only works on the plaintext seals the Control Plane already uses.)
• Then it adopts itself, through the ordinary receiver. The chunks are saved into the local database as they are sent, so Community::rotate calls the same rekey::adopt the watch calls instead of adopting by construction: one path for every rotation, whoever wrote it. Publish failures are logged per relay and do not change the held state, so a rotation that only reached some relays still leaves this client consistent — which is the same asymmetry the reference has.
• The receiver now keeps the signing root it is handed. BaseAdoption carries the delivered control_root through to state.control_root; before this, a refounding's root was dropped at the receiver and a staff member went on signing under the epoch they had left.

What is still not here: the trigger. Kicking a member, choosing a channel's remaining audience, and rendering any of it is the moderation and community-management surface §8 keeps out of scope, so Community::rotate is an API with no caller in the app yet — and Rewrite.recipients is the caller's to name, because a private channel's audience is in each member's own invite and not in the local state. And the new epoch's roster is not seeded: CORD-02 §5 has the refounder publish a snapshot of the present members into the Guestbook it just minted, which is the only way a client that joins after the rotation ever learns who was already there. cord02::guestbook::build_snapshot_chunks is implemented and unobliged; a refounding published from here would leave every later joiner with an inferred roster (§12c).

7. Honest states (phase 4) — landed

"No messages yet" is a claim, and finding 8 is that the client made it in three situations it could not tell apart. The rule is that a room only says it is empty when it knows it is empty; otherwise it says what is actually wrong.

What is carried out of the read path:

• history::WrapPage.unreadable counts the wraps a page reached under a held plane that no held key could open — sealed past the cutoff a rotation set on the key that reads them, or bound to another channel. Walk's count is the page's; Progress.unreadable sums the pages of a round.
• sync::Snapshot.unreadable is the same count over the whole store, per channel, so a wrap is counted whether it arrived on a round or on the live wire. A wrap already opened on the way in stays readable through its cached row and is never counted.
• Community keeps the last completed round's Progress per channel and the unreadable counts, merged monotonically: an unreadable wrap stays unreadable, so a later quiet round cannot erase the count.

What the community answers:

• progress(channel), unreadable(channel), missing_key(channel) (a private channel we know and hold no key for, with the epoch), channel_removed_at(channel) (a channel rotation's cut), plus the phase-3 removed_at() and stranded().
• due(channel): whether an automatic catch-up is worth asking for yet.

What the panel renders, in precedence order, instead of an empty room:

State	Rendered
stranded()	"This invite is stale — the community has rotated past the epoch it names"
removed_at()	"You were removed from this community at epoch N. Its history stays readable"
channel_removed_at()	"A rotation removed you from this channel at epoch N"
missing_key()	"Messages here can't be read yet — this channel's key for epoch N is missing"
progress.failed && progress.errors > 0	"Couldn't reach the community's relays" + Retry
unreadable(channel) > 0	"N messages here can't be read yet — no key we hold opens them"
otherwise, no rows	"No messages yet"

The notice replaces the empty state, and sits as a one-line strip above the rows when there are rows, so a stale room says it may be stale rather than looking complete. Only Retry is actionable, and it runs the round directly — the MIN_ROUND_INTERVAL gate below only paces automatic rounds.

One of those states is about writing, not reading. A room a rotation removed us from, a channel it cut, a key we never held, or a stale invite all mean the same thing at the wire: channel_secret is None, so a wrap sealed now would be sealed under a root nobody who rotated reads. Community::send therefore refuses in those cases (§6's deferral, closed), and the panel disables the send button while the notice says why. A channel that is merely unreachable or partly unreadable still writes: reading and publishing are separate paths.

Two CommunityEvents carry the same news to any other view: Failed(id) (the last round could not reach the relays) and Unreadable(id) (history here that no held key opens). Failed replaces the Error(..) toast a failed round used to raise, because the panel now says it in place.

7b. The round scheduler (phase 4) — landed

Two constants in community/src/community.rs:

• MIN_ROUND_INTERVAL = 30s — Community::due(channel) is false while a round for that channel ran inside the window. The panel's automatic round on open (and on a channel switch) is what consults it, so opening a channel twice in a breath asks the relays once. A round for Older, a retry, and the catch-up a rekey adoption triggers all bypass it — only the automatic open is paced.
• STALE_AFTER = 300s — Community::tick re-folds, and re-rounds the active channel, once a channel that has been synced before has gone unsynced that long. A channel with no recorded round is left alone, so a community nobody has opened costs nothing, and a quiet one asks its relays at most once per five minutes.

CommunityRegistry owns one task for this, armed beside the pump and the signal consumer in handle_notifications and cleared in reset, so a signer change stops it and re-arms it.

7c. Not done in phase 4

• NIP-77 (client.sync) catch-up. Still skipped deliberately. A negentropy reconciliation is a second way to ask the same question, and getting its "unsupported"/partial answers right — never reading one as exhausted — is its own piece of work with its own failure modes. The paged walk is the fallback the plan already specifies, so nothing here blocks on it.
• The fold's control and guestbook planes keep logging an unopenable wrap rather than counting it: Snapshot.unreadable is per channel, and there is no honest place yet to render "the community's own metadata is unreadable".

8. community_ui: reach the older rows

Landed in phase 1, unchanged by the re-layering: per-channel rows, has_more, loading, FollowMode::Tail instead of scroll_to_end(), load-older from the scroll handler plus an always-index-0 "Load earlier messages" row, prepend via splice(1..1, n), append via splice(at..at, n), and in-place merging unless the newest window no longer reaches the rows on screen.

Two rules survive, both about GPUI rather than about history:

• Never set_follow_mode or force a scroll position inside a scroll-handler callback — the list holds its state borrowed while it invokes the handler, so touching ListState there panics. load_older is written to avoid it.
• The panel's Intent::{CatchUp, Older} calls do not change the list: the round they trigger is subscription-driven, which is invisible to it. Phase 4 added one gate in front of the CatchUp one — due() — and it only paces how often the relays are asked, not what the list does with an answer.

Still deferred: per-channel timeline state (switching back re-reads), and the MAX_TIMELINE_ROWS trim (trimming the oldest rows fights load_older, which prepends at the same end — the reader would oscillate).

9. The fold stops being O(history) (phase 2b) — landed

sync::fold used to open every wrap in the community's planes on every inbound wrap: channel wraps were re-opened only to cache_rumor them again and to observe their authors, which the database already holds as decoded rows (the cached row carries the author in a p tag, the message time in created_at, and the wrap it came from in an e tag). Finding 14.

What landed is smaller than the first sketch and needs no new queue:

• cache::wrapper_index(client, channel) reads the cached rows back as EventId -> Observed { author, at_ms }, keyed by the wrap they were opened from.
• fold opens a channel wrap only when its id is not in that index; an already-cached wrap is observed from the row instead. A wrap is therefore opened once, on the way in — by a round for a page, by the first fold after it arrives for the live wire — and never again.
• The control and guestbook planes are still read from wraps (they are small, and cord02::fold_control is a fold over all editions by construction).

The fold still reads every wrap from the database (plane_filter, which is now its own unbounded filter separate from the live one); what it no longer does is NIP-44-open them all. The plan's per-channel work queue in the pump turned out to be unnecessary for that: the first fold after a live wrap already opens exactly the uncached wraps.

10. Time is a type: Timestamp, not padded milliseconds (phase 5) — landed

The read path compared times through a bare u64 in three units, and each boundary paid for the confusion:

Value	Held	What it cost
HeldKey.retired_at, HeldRoot.retired_at, Plane.retired_at	seconds	compared with wrap.created_at.as_secs(), written as at_ms / 1000
ChannelCursor.newest_ms/oldest_ms, WrapPage, Window, the Walk bounds	milliseconds, always secs * 1000	* 1000 on every accepted page, / 1000 on every filter
CommunityState.channel_cuts	epochs	Epoch unpacked to u64 and rewrapped at the boundary
added_at_ms, a rumor's at_ms	milliseconds, genuinely	—

What landed:

• HeldKey/HeldRoot.retired_at, ChannelCursor.{newest,oldest}, WrapPage.{newest,oldest}, Plane.retired_at, Window.{until,since} and the Walk bounds are Timestamps. A window bound and a wrap's created_at are now the same type, so read_under and Plane::accepts compare them directly, wrap_filter/live_filter hand them to until/since unchanged, and the page's exclusive boundary is written oldest - 1 instead of oldest_ms - 1 truncated back to seconds.
• CURSOR_OVERLAP is a Duration (60s), not 60_000, so newest - CURSOR_OVERLAP reads as what it is.
• channel_cuts is BTreeMap<ChannelId, Epoch>, which is what rekey::Adoptions::cuts already carried.
• The two millisecond fields stay milliseconds. A rumor's time is genuinely finer than a wrap's second-granular created_at: CORD-01 carries the sub-second offset in an ms tag and resolve_ms_strict puts it back, so a reader's at_ms and timeline's before_ms keep it. The cord02 list document's added_at/removed_at keep it too, and not merely for fidelity: added_at is an ordering key judged against a tombstone's removed_at under a strict >, so narrowing both to seconds could tie a rejoin with the leave that preceded it.
• A stored cursor is retired, not reinterpreted. A document written when the boundaries were milliseconds would deserialize into a Timestamp far in the future, and its exhausted would then wedge the older pass for good. The map's serde key changed (cursors → channel_cursors), so such a record is dropped and the next round rebuilds the cursor from the wraps it reads; a_cursor_stored_in_the_old_unit_is_dropped_rather_than_reinterpreted pins both halves of that. retired_at needed no such treatment, because it was already written in seconds.

No behaviour changes with it: the walk paged the same regions before and after, because every millisecond it held was a second multiplied by a thousand.

11. A Refounding moves a public channel's plane (revision 4) — landed

The symptom that survived every phase: a channel showed its history and its room members, and never a new message — not while the panel was open, and not after reopening it, while another client was writing to the same channel. Three findings, in order of how much they explain.

11a. The plane a public channel is read and written at

A public channel holds no key of its own: CORD-03 §1 derives its Chat Plane from the community root, at the root epoch — channelGroupKey(root, channel, rootEpoch). A Refounding moves the root to a new epoch, so every public channel's plane moves with it. The reference therefore keeps one stream per held root epoch and writes to the newest (channelsView's rootStreams with current: rootStreams[0]), which is also what makes history survive the rotation.

This code paired every held root with the channel's recorded epoch — the root epoch the channel's material was published at — and channel_secret sealed at the same value. At genesis the two agree, so nothing looked wrong; after a rotation they diverge, and every plane the client asked for was addressed at the retired epoch:

Plane	Derived from	After a Refounding
Channel (channel_group_key)	held_keys	current root at the old epoch — an address nobody writes
Control (control_group_key)	state.control_pks epochs	current
Guestbook (guestbook_group_key)	roots() epochs	current

That shape is the whole report: the roster, the channel list and the old history were all right, the room received nothing, and because the newest pass came back empty the round read as failed, so no cursor was ever written for that channel. The community's own messages went to the same unreachable plane — readable by us, invisible to everyone else.

Fixed: held_keys pairs each root with its own epoch (HeldKey { epoch: root.epoch, key: root.key, retired_at: root.retired_at }), and channel_secret seals a public channel at (state.root_epoch, state.community_root) — the newest held root, the one the reference calls current. The two halves move together on purpose: reading where we write, and writing where the rest of the protocol reads, is the same statement.

11b. The page's floor

sync_round uses history::page's report three ways: the newest pass's oldest is where the older pass resumes (resume = saved.oldest.or(newest.oldest)), the newest pass's oldest is the top of the bridge (Window::between(saved.newest, oldest)), and a page that reached the bottom earns exhausted so later rounds can stop paging. Walk::accept computed that value into a local and never assigned Walk::oldest, so every page reported oldest: None and all three consequences followed at once: the older pass never ran (scrolling up could only ever re-read the local cache), the bridge never ran (a burst larger than one page left a hole that the next cursor advance then sealed as covered), and the bottom was never reached. The persisted state said so plainly — no cursor carried an oldest, and every exhausted was false.

Fixed: accept folds the page's floor into Walk::oldest.

11c. Two ways for the live path to go quiet, closed

• A cursor is clamped to the local clock. A wrap stamped in the future — a peer's skewed clock, or a hostile stamp — used to become ChannelCursor.newest, and the cursor is persisted, so every later REQ for that channel would open with since ahead of the present. Relays apply since to live events as well as to the stored replay, so the channel goes deaf for as long as the stamp leads and no restart heals it. The reference clamps at exactly this point (WireSync's writeCursor: an event stamped in the future "must not drag the cursor past now"). clamped bounds newest both on the way into the document and on the way into a filter, so a cursor already stored past now heals on the next round instead of staying deaf.
• The standing REQ is re-issued when a community goes quiet. A relay can end a subscription without a reason the SDK acts on, and nothing here re-installed one whose plane set had not moved, so a community whose subscription died looked exactly like a quiet community until the next launch. The reference rotates every relay's REQ after 90s of silence for this reason ("never trust one subscription for long"); CommunityRegistry::tick now does the same, because an accepted REQ that yields nothing and a REQ that was never accepted look identical from here. The re-issue resumes from the current window, so the seam is replayed rather than lost.

What is deliberately still not here: a future-dated message is folded and shown rather than held out of the timeline until its time comes (the reference's FUTURE_HOLD_MS). The clamp already keeps such a stamp from bounding a filter; hiding it is a display decision this client has not made.

And one gap this revision leaves open, because it is a different symptom (depth, not freshness) and it cannot be closed honestly from what the code has at hand: sync::refresh overwrites community_root/root_epoch from the community list's material without retiring the root it replaces, and held_roots is populated only by rekey::adopt. A client that learns of a Refounding from a re-materialized list entry rather than from a rekey blob the watch delivered therefore loses the prior root, which is exactly the history the reference keeps in heldRoots ("every held epoch stays in the decode set"). The messages are still on screen — they are in the local cache — but paging below them against a relay needs that plane. Retiring a root correctly needs the rotation's publish time; a list entry carries only its own added_at, so the honest fix is for the re-materialization to carry the prior root the way an adoption does, not to guess a cutoff here. Closed in revision 5 (§12c), on the same terms: a root the List moved past is retained as a key we were given, and the cutoff stays absent rather than guessed.

12. Two reports from one client (revision 5) — landed

The plane fix worked — history, the roster and new messages all arrived — and the same client then reported two things it could see: "when the message list updates, the order isn't by timestamp anymore", and "the member list still isn't showing full members like the other client". Two independent bugs, both confirmed against the client's own database before anything was changed.

12a. Rows are placed where the fold puts them, not appended

The panel treated a read as newer than the rows on screen: new ids were appended to the end (apply) and the older page was spliced onto the front (prepend). Both hold only while every read is newer than everything shown or older than everything shown — and reads are neither. A catch-up round heals a gap by caching history sealed long ago, the bridge pass fills the region above the cursor's newest, and a message delivered late lands with its own (older) time. The client's own database shows the ground for it: the room held 1,176 cached rows, so every window read is a selection of its history, and a round finishing while the panel is open hands apply rows older than the newest row already on screen. The same read also reaches apply twice — once through Updated and once through load_older's own re-read — so whether a page of history landed at the top or the bottom depended on which task ran first.

Fixed: one merge for both paths. Rows already shown keep their position (an edit replaces its row in place); a row that is new is inserted where the fold would have put it — partition_point over (at_ms, id) ascending, the exact order Community::timeline returns — and the list state is spliced at that index instead of at the end. The order the panel shows is now a function of the data, not of the order reads happened to land in.

One other lie about time went with it: send stamped at_ms as Timestamp::now().as_secs() * 1000, and a rumor's ms tag is the remainder within the second (split_ms), so every message this client sent carried 0 — placed at the start of its second, up to 999 ms before it was written, and before any message from another client in the same second. The reference stamps Date.now(); now_ms() does the same, with the clock error propagated rather than flattened.

12b. A Refounding snapshot could never be honored

sync::fold called guestbook::coalesce with None as the snapshot authority, and coalesce drops every snapshot chunk whose refounder is not that authority — so every Refounding snapshot this client ever received was ignored, and the roster fell back to the members it could infer: authors seen publishing, granted npubs, and joins it had itself received.

The client's database shows exactly what that costs. Vector Community is at root epoch 9 with no retained roots; its epoch-9 Guestbook holds 13 wraps — 11 joins, 1 leave, and one snapshot naming 240 members, authored by d133ecb0…. Folded with no authority the roster comes out at 41 members; folded with that one snapshot honored it comes out at 247. Nothing about the wraps is missing or unreadable — only the authority to believe them was.

Fixed: the refounder is recorded where the protocol states it and honored where CORD-02 §5 asks for it.

• CommunityState.refounders — the npubs whose rotation minted an epoch this client verified. guestbook::coalesce now takes that set (&BTreeSet) instead of an Option, which is also what the reference passes: the wire never says which epoch's stream carried a chunk, so the authorities are unioned and the residual (one held epoch's refounder accepted on another's snapshot) is documented there and here. An empty set honors no snapshot, and genesis — where no rotation minted anything — has no authority at all.
• rekey::walk records the rotator of every base step it adopts (Delivery.rotator → Adopted.refounders → BaseAdoption.refounders), and merge_adoptions folds them into the state. A rotation is the only place a refounder is ever named, and it is verified the way an adoption already was: continuity from the key held, a blob for us, and the rotator's rank.

Which raised the question the client's own state answered: it holds epoch 9 but never adopted the 8 → 9 rotation (its held_roots is empty), because it learned of the refounding from a re-materialized List entry. A rotation can only be read from the root it stepped off, so the refounder of an epoch the client was away for was unreachable. Fixed in §12c, and the two fixes are one story: the refounder of the current epoch is recoverable precisely because the root before it is retained.

12c. A superseded root is history, not a secret

Three points, one rule — a root the community has rotated past stays held:

• sync::refresh no longer overwrites community_root/root_epoch from the List's material without retiring the root it replaces, which is what lost the prior root in the first place (the gap §11 closed on paper).
• sync::load likewise keeps the root the List's seed material names: the List carries the community as it was when we joined, so that root is a key this client was given. merge_entry already preserves the lowest-epoch material as the seed, so a client that joined three rotations ago still has three rotations' worth of read keys recoverable.
• rekey::watches now watches the epoch after every held root, not only the current one, and rekey::adopt walks from every held root before it, keeping the furthest adoption (the epoch the community is actually on). That is what turns a retained root into a refounder: the 7 → 8 and 8 → 9 rotations are still verifiable from the roots they stepped off.

The retained roots pay for themselves a second time: held_keys derives channel planes from them, so public-channel history below the local cache becomes pageable again for a rotated community — the depth gap §11 named, not just the refounder.

What is honestly still missing, in the order it matters:

• Recovery needs the old rotation chunks to still be on a relay. A refounder is only learnable from the rotation that named it; if the relays have dropped the chunk for the epoch a client is on, the seeded members stay unknown until the next Refounding — the client cannot verify a snapshot it has no rotation for, and accepting one from an unverified npub would let any member inject arbitrary npubs into everyone's roster.
• A Refounding this client publishes seeds nobody. build_snapshot_chunks exists and the reference publishes one at every refounding ("present members only, chunked at 400"); Community::rotate does not yet. It has no caller, so nothing regresses today, but the first client that refounds without it leaves every later joiner with an inferred roster.
• complete_memberlist is still given no ban times. The reference passes the Control Plane's authorized ban history so that activity before a ban does not resurface as membership after an unban; fold_control exposes the Banlist as a set and no times, so an unbanned member's older activity counts as present here. Nobody is lost by it — the failure mode is a member shown who left — and it is the fold in concord that would have to grow the times.
• The panel's order is untested. The merge is a few lines and the crate has no harness for a panel; the invariant it restores is the one Community::timeline already promises, and it is asserted here by reading it against the fold, not by a test.

Order of work

Phase 2a — move the code (no behaviour change) — landed

1. concord/src/store.rs split into concord/src/state.rs, community/src/cache.rs and community/src/history.rs per the table in §1; call sites updated (community/src/sync.rs, community/src/community.rs, community/src/lib.rs, and the cord02 test's crate::store::CommunityState). fetch_page is now history::page.
2. The local cache key is stable (cache::LOCAL_KEYS is one fixed secret, not a per-process Keys::generate), so caching a rumor twice leaves one row. cache.rs carries the new caching_the_same_rumor_twice_leaves_one_row test.
3. docs/concord-usage.md updated; concord dropped futures and nostr-memory and demoted smol to a dev-dependency; community gained futures and smol.
4. Gate, all green with the phase-1 transport still in place: cargo test -p concord -p community (50 + 14), cargo clippy -p concord -p community -p community_ui --all-targets, cargo +nightly fmt --all --check (no diff in the touched files), cargo check -p workspace --all-targets. No behaviour changed beyond item 2.

Phase 2b — subscribe, then read the database — landed

1. The pump (§2): route by subscription id for events, EOSE and CLOSED; batch within PUMP_WINDOW; both wrap kinds; auth-required never a failure.
2. Page REQs (§3): the round registers a PageReport channel, installs one REQ per page over the community's relays, awaits the pump's reports with PAGE_TIMEOUT, reads the page from the database, and keeps the walk's rules (exhausted earned, all-empty is failed, newest_ms only on a complete round, skip the older pass when saved.exhausted).
3. The live REQ (§2, §5): both kinds, private channels, the window rule with LIVE_REPLAY = 500, kept alive across reconnects.
4. cache::purge_expired on the round cadence (every round is an open).
5. The fold issue (§9).
6. Gate: cargo test -p concord -p community (50 + 23), cargo clippy -p concord -p community -p community_ui --all-targets, cargo +nightly fmt --all --check, cargo check -p workspace --all-targets; plus the phase-1 manual bar and a dev-relay check that a warm open sends one REQ per relay carrying a since, and a cold open sends one with no since and pages down.

Three deviations from the revision-2 sketch, each forced by a constraint it did not account for:

• A page id is opaque and resolved through a registry, not parsed. A NIP-01 id is capped at 64 characters and a community hex fills it, so concord-history/<community>/<channel>/<n> could never be sent. route_of therefore only parses the two standing ids, and PageRegistry maps a page id back to the round waiting on it.
• The live window is per community and aggregates cursors. There is one REQ per community, so Window::opening(cursor) applies to a channel's newest pass while sync::live_window(state) derives the community floor as the oldest held cursor (a channel with no cursor forces since = None).
• The fold needs no pump work queue. Skipping already-cached wraps through cache::wrapper_index already makes a wrap open once, on the way in, because the first fold after a live wrap is the one that opens it. See §9.

Also landed as the cheap win §3 promised: the older pass is skipped entirely when saved.exhausted is already set.

Phase 3 — epochs and rekeys — landed

1. The document (§6): HeldKey/HeldRoot, ChannelKeyRef.priors, CommunityState.held_roots/channel_cuts/removed_at/stranded, and the roots()/held_keys() read surface.
2. The read cutoff: history::page takes &[HeldKey] and refuses a wrap sealed under a retired key after the rotation's publish time; sync::fold applies the same rule from the channel's priors.
3. sync::planes derives planes from every held channel epoch and every held root; sync::refresh preserves priors and honors recorded channel cuts.
4. The rekey watch and adoption (§6), community/src/rekey.rs, wired through the pump's Signal::Rekey and a WatchRegistry.
5. Gate, all green: cargo test -p concord -p community (50 + 29), cargo clippy -p concord -p community -p community_ui --all-targets, cargo +nightly fmt -p concord -p community -p community_ui --check, cargo check -p workspace --all-targets.

Phase 4 — honest states and polish — landed

§7, §7b: the read path counts what it cannot open (WrapPage/Progress/ Snapshot unreadable), the community exposes the honest read surface (progress, unreadable, missing_key, channel_removed_at, due, beside the phase-3 removed_at/stranded), the panel renders a reason and a retry instead of "No messages yet", the round scheduler paces automatic rounds (MIN_ROUND_INTERVAL) and repairs a stale one (STALE_AFTER), and §6's send-time gap is closed: a removed, cut, keyless or stranded room holds no write key.

Gate, all green: cargo test -p concord -p community (50 + 32), cargo clippy -p concord -p community -p community_ui --all-targets, cargo +nightly fmt -p concord -p community -p community_ui --check, cargo check -p workspace --all-targets.

Five recorded deviations:

• A one-line strip above the rows, not only an empty state. §7's finding is about the empty room, but the stale case — rows on screen, relays unreachable or history unreadable — is the same lie in a quieter form, and it is the one the original report is actually about ("not full of messages and latest data"). A failed round's strip is transient: the next round that succeeds replaces progress and clears it. An unreadable count is monotone by design, because a wrap no held key opens stays unopened.
• Failed replaces the Error(..) toast on a failed round rather than accompanying it, so the panel is the single place that reports it.
• due() gates the panel's automatic round, not sync_channel. The plan named the interval but not the seam; keeping the gate on the caller means every explicit request (retry, load-older, a rekey's catch-up) stays exact.
• §6's send-time deferral is closed in the same phase. The plan framed it as a wire-level gap to decide later, but it is the same lie in the other direction: a member a rotation excluded could type, press enter, watch the message disappear into a plane nobody reads, and be told nothing. channel_secret refusing is what makes the notice actionable.
• Spawned work is tracked, not detached. Community::tasks and CommunityPanel::tasks hold every fold, round bookkeeping step and publish, so closing a panel or signing out cancels them instead of letting them finish against a client nobody holds. Each push drops the tasks that already finished.

Phase 4 leaves the client honest about what it can see and what it can write. What it does not do is make it see more: the rekey writer, and with it adopting a rotation this client published itself, was still open there (§6, closed in phase 6).

Each phase leaves the client consistent on its own. Phase 2a was invisible; phase 2b is what makes "open a community" a subscription and a database read; phase 3 is what keeps a rekey from stranding history; phase 4 is what makes an empty or unreadable room tell the truth.

Phase 5 — typed time — landed

§10. HeldKey/HeldRoot.retired_at, ChannelCursor, WrapPage, Plane, Window and the Walk bounds are Timestamps; channel_cuts is Epoch; CURSOR_OVERLAP is a Duration; and the cursor map's serde key was retired so no stored millisecond cursor is read as seconds. No behaviour change, no relay contact, no new dependency — the units the read path already compared by hand are now the types it compares.

Gate, all green: cargo test -p concord -p community (51 + 32), cargo clippy -p concord -p community -p community_ui --all-targets, cargo +nightly fmt -p concord -p community -p community_ui --check, cargo check -p workspace --all-targets.

Phase 6 — the rekey writer — landed

§6's writer: cord06::plan_rotation, rekey::{Rewrite, rotate}, carry_heads, and Community::rotate, which publishes a rotation and then adopts it through the receiver phase 3 built. The receiver also keeps the signing root a refounding hands it now, instead of dropping it.

Gate, all green: cargo test -p concord -p community (51 + 32), cargo clippy -p concord -p community -p community_ui --all-targets, cargo +nightly fmt -p concord -p community -p community_ui --check, cargo check -p workspace --all-targets. No test was added for the writer itself: the publish half needs a relay, and the same reason the reference's own rekey paths are exercised by hand applies here — see Tests below.

Phase 1 status (landed)

What phase 1 delivered, and what phase 2 replaces:

• Window, WrapPage, history::page, Walk/Walker, the paged walk with an exclusive page boundary, ChannelCursor + monotonic merge persisted in CommunityState.cursors, Community::sync_channel/timeline, cache_rumor counting what opened, and the panel's load-older/follow-the-tail work. All of that survives; phase 2a moved it and phase 2b swaps its transport.
• fetch_events is gone. Phase 1 already replaced it with subscribe-then-read-the-database: each page subscribed every answering relay to one filter (relay.subscribe(..).close_on(ExitOnEOSE + PAGE_TIMEOUT)), waited for that relay's EndOfStoredEvents(id), then read the page with client.database().query(filter). Revision 2's correction is where that lives (community, not concord) and who watches the notifications (the pump, not a loop inside a page).
• auth-required was already excluded from the failure set in code, but revision 1's prose described it wrongly ("ends that relay's wait as a failure ... the next round retries"). The SDK re-issues the REQ under the same id after AUTH — for auto-closing subscriptions too — so the honest statement is: the relay stays in the walk and the page waits for its resubscribed answer.
• Held epoch handling and rekeys landed in §6 (phase 3); honest empty states remain open in §7. Private planes, the second wrap kind, the expired-row sweep, the stable cache key and the fold cost were open before phase 1 and are now landed (§5, §9).

Tests

Following the existing MemoryDatabase and Walk/serve_page test style. The 2b pieces are covered by unit tests that need no relay; the rows still marked outstanding are the ones that need a GPUI harness or two live accounts.

• The walk: history::page continues past a page whose wraps none of them open; exhausted requires a short page after history; an all-empty round is failed and the next round re-asks the same region; until is exclusive and the walk terminates; a channel that already holds its newest page still pages older history; the bridge heals a hole; history pages across a rekey using retained prior keys; and the walk reports the floor the older pass resumes from — landed in revision 4 (a_walk_pages_back_across_a_rekey asserts page.oldest, the half sync_round resumes from). (The page-REQ half still needs a relay.)
• A Refounding's plane — landed in revision 4 (sync::tests::a_refounding_moves_a_public_channels_plane_to_the_new_root_epoch): with the root at epoch 1, the prior root held, and the channel's material still naming epoch 0, the current root's channel plane is the one subscribed and read, and a message sealed at it folds into the channel. Before the fix the plane was derived at epoch 0 and the test failed on the missing plane.
• A delivered wrap — landed in revision 4 (sync::tests::a_fold_caches_a_channel_wrap_a_relay_delivered): a wrap saved into the database (what the SDK does with what a subscription delivered) and nothing else is opened and cached by the next fold, which is the step a live message depends on. Its unreadable counterpart was already covered.
• The cursor's clock — landed in revision 4 (a_future_stamp_cannot_push_a_cursor_past_now): a round's future stamp is clamped to now while its other findings land, and a cursor already stored past now heals; sync::live_window starts at now - CURSOR_OVERLAP for such a cursor instead of opening the REQ ahead of the present.
• The roster's authority — landed in revision 5 (sync::tests::a_refounders_snapshot_seeds_the_members_it_names): a snapshot sealed to the current epoch's Guestbook seeds a member who has never been seen publishing, and the same wraps seed nobody once the refounder is not in refounders — the authority is the rotation, never the author alone.
• A rotation off a retained root — landed in revision 5 (rekey::tests::a_rotation_past_a_retained_root_is_adopted_and_names_its_refounder): with the root before it retained, a rotation into epoch 2 is adopted from epoch 1 and its rotator comes back as the epoch's refounder. The unit-half of §12c's recovery: what still needs a relay is whether the old chunk is still there to be read at all.
• Retaining what was rotated past — landed in revision 5 (sync::tests::a_list_material_at_a_newer_epoch_keeps_the_root_it_superseded and a_list_that_moved_the_root_on_retains_the_root_of_our_join): material at a newer epoch replaces the current root and retires the one it moved past, and a List whose seed names our join keeps that root held.
• The page a rotated community's history sits on — the same retention is what a_walk_pages_back_across_a_rekey pages across, and revision 5 is what makes a List-learned refounding leave those keys held, not only a blob-learned one.
• The pump — landed in 2b (community/src/lib.rs tests): an EndOfStoredEvents(id) settles exactly the page that owns id; a non-auth CLOSED settles its relay as refused; an auth-required CLOSED settles nothing; a page's event routes to nothing; a burst collapses to one signal per community; a shutdown stops the pump.
• The windows — landed in 2b: Window::opening(default) has no since; Window::opening(saved) starts at newest - CURSOR_OVERLAP; Window::older_than never includes the boundary event; sync::live_window is wide cold and resumes at the oldest held cursor warm.
• The cursor's unit — landed in phase 5: a merge only moves forward and never earns exhausted; a document whose cursors were stored in the old millisecond encoding reads as no cursors at all, while a typed one round-trips (concord/src/state.rs).
• The subscription plan — landed in 2b: a private channel's plane appears when the key is held and is absent when it is not; plane_filter asks for both wrap kinds and addresses every readable plane. The page-REQ half (a warm open's REQ carries a since, a cold open's does not) still needs a dev relay.
• The page registry — landed in 2b: a page that has already unregistered receives nothing.
• The rekey watch and adoption — landed in phase 3 (community/src/rekey.rs tests): a complete base rotation whose prevcommit extends the held root is adopted with the prior root retired at the rotation's publish time; a rotation off a key we do not hold is never adopted; a complete blob-less rotation from a rotator who outranks us, published after we joined, reads as a removal; a channel rotation replaces the key and keeps the prior. The pump's half (community/src/lib.rs) is that a rekey watch's event wakes its community.
• The rekey writer — landed in phase 6, structurally only. No test covers it: the half that could be tested without a relay (that plan_rotation mints two unrelated keys, that Rewrite::authorized agrees with the receiver) would not catch the failures that matter (a blob addressed to the wrong epoch, a chunk set the receiver cannot collect, a refounding that carries no head), and the half that would — publish, re-read, adopt — needs a real relay and a second account. What stands in for it is that the writer cannot take a path the receiver does not: same permissions, same build_rekey_chunks, and adoption goes through rekey::adopt rather than beside it.
• The read path: the side-event budget folds an edit/delete/reaction older than the row window onto its message.
• What cannot be read — landed in phase 4: a wrap sealed after the rotation that retired the key reading it, and a wrap sealed to this plane but bound to another channel, both read as unreadable rather than dropped (community/src/history.rs); a fold counts a wrap addressed to a held channel plane that will not open (community/src/sync.rs).
• The honest states — landed in phase 4 structurally: Snapshot.unreadable and Progress.unreadable are what the panel's notice and the Unreadable event read, and the Failed event is what a failed round emits. The panel's precedence (stranded → removed → missing key → unreachable → unreadable → empty) itself needs a TestAppContext, which the repo still does not have.
• The scheduler — landed in phase 4 structurally: due() is false inside MIN_ROUND_INTERVAL after a round, stale() requires a recorded round older than STALE_AFTER, and tick acts only on the active channel. Driving real time needs the same harness. Revision 4 added the rotation of a quiet community's standing REQ to the same pass, which is structural in the same way: what it needs to be observed is a relay that drops a subscription without saying so.
• The fold: a new live wrap costs one decrypt, and a fold over a community with 5,000 cached rows does not re-open them. (The skip is in place and structurally tested by wrapper_index; counting decrypts needs a harness.)
• A stable cache key: caching the same rumor twice leaves one row (the phase-1 regression that duplicates a community's history per app run). Landed in 2a.
• GPUI (TestAppContext): prepending older rows preserves the scroll anchor; a live message does not scroll a reader who is scrolled up; has_more == false disables the load-older row; the panel's notice precedence; due()/stale() under a driven clock; and — added by revision 5 — that a read carrying history older than the last row lands above it instead of at the end. (No GPUI test harness exists in the repo yet, so the merge is asserted by reading it.)
• Manual runs: two accounts, a channel with more than 200 messages, one account offline long enough to miss a full page, one private channel, one rekey, and one run with a relay stopped so the notice and its retry are visible. The acceptance bar is the reference behaviour: open a channel cold and see history arrive in pages without touching the scrollbar, reopen it and see one REQ with a since instead of a replay, see the other account's message appear without a reload, and see a room we cannot read say so instead of "No messages yet".

Out of scope

Unread badges, notifications, message threads, pins, typing indicators and presence (21059 wraps are wired for routing here, not for those features), file and media rendering, moderation actions, and the community-management surfaces. The rekey writer is the one exception, and only its mechanism: Community::rotate exists to be called, but nothing in the app calls it. Kicking a member, choosing the audience a rotation keeps, and showing any of it stay out. crates/chat's DM path shares none of this code and is not touched; a later change can lift the page walk/cursor into a shared module if DMs grow the same paging.