← back to overview

How Cove decides who sees what.

The visibility, membership, and history rules that govern threads. Written for the people using Cove — board members, keymasters, curious skeptics — not the people writing it.

Who’s in the directory.

Everyone participating in a Cove hub is a keypair — an Ed25519 public key attested by the group’s root, plus the private key that lives on their device and nowhere else. The attestation is a signed record in the directory manifest: it names the person, their affiliation, their role, and the pubkey those things belong to.

You’re not a “user” with a username and password. You’re an attested keypair. Every message you post is signed by that private key on your own device before it leaves. The hub can prove you wrote it. Nobody can post in your name without your private key.

Rule. One member = one keypair. If you use Cove on your laptop and your phone with different keys, they’re two attested identities, even if they have the same display name.

Public and private threads.

Threads come in two visibility shapes:

Public — every attested member of the hub can see the thread and every message in it. This is the default. When you type a new thread name in the sidebar and just start posting, that’s a public thread.
Audience-scoped (private) — only listed pubkeys can see the thread. A signed kind=’audience’ entry establishes the list. Anyone not in the list will not see the thread in their sidebar, their inbox, or their /sync response — the hub filters them out at every surface.

Rule. If a thread has ever had an audience entry, it’s private. The audience is the pubkeys named in the most recent valid audience entry.

The audience-entry-establishes-visibility rule is enforced hub-side. A member who isn’t in the audience can’t just guess the thread name and read it — /sync returns an empty list to them, same as if the thread didn’t exist. The hub doesn’t 404 on private threads (that would leak existence); it just looks empty from the outside.

Joining and leaving a group thread.

Adding someone to an existing thread

Anyone currently in the audience can rewrite the audience. To add Amy to a group thread you’re in, you tap the audience chip at the top of the thread, check her name, and save. Cove signs a new audience entry with the updated list.

The rule is anyone currently in the audience can grow (or shrink) the audience, not only the creator can. Cove doesn’t treat the creator as a permanent custodian of the group. If the group is you and two others, any of the three can add a fourth.

Rule. A new audience entry is honored only if its author was in the audience at the time. Anyone outside the group signing an audience entry into it gets rejected by the hub.

Removing someone

Same mechanism. Anyone in the audience opens the audience chip, unchecks the person, and saves. That signs a new audience entry with the shorter list. From that point forward, the removed person’s /sync requests return an empty list for that thread and it disappears from their sidebar.

Everything they saw before their removal stays visible to them locally — Cove can’t reach into their client and yank prior messages. But no new entries flow to them, and the hub won’t serve the thread’s history to them again if they clear their cache.

Leaving yourself

Not yet a first-class action — the UI currently guards against accidentally unchecking yourself in the audience-edit dialog. The intended way to leave today is to ask another member of the group to remove you. For a group of three that’s a text message; for a group of two, archiving the thread is usually the honest signal.

A proper “Leave this thread” button is on the roadmap. When it lands, it’ll respect the same rule — you sign an audience entry with yourself removed — just without the click-through required to talk another member into doing it.

History and what a new member sees.

When Cove decides whether to hand you a message, it consults the current audience — not the audience at the time the message was posted. This has a consequence people don’t always expect:

Rule. A member added to an audience-scoped thread sees the thread’s entire history, from the first message onward — not just messages posted after their addition.

That’s deliberate. A board that adds a new officer to a private “board only” thread is welcoming them into the ongoing conversation, not into a walled section of it. Cove doesn’t make you re-explain last month’s decision every time somebody new joins.

If you need “only-from-here-onward” visibility for a specific member, use a fresh thread instead. That’s the honest signal: this is a different conversation.

Public threads follow the same logic. Every newly-attested member automatically sees every past public thread from the beginning. Notices posted before someone joined the group are readable by them the moment they authenticate.

Ephemeral threads.

Ephemeral threads carry a TTL — a delete-by date declared at creation. Everything works exactly like a permanent thread while it’s alive: signed messages, signed receipts, tamper-evident per-thread log, verifiable inclusion proofs. At expiration, the hub deletes the entries and publishes a signed tombstone in the main log that pins the thread’s final signed tree head.

Rule. Ephemeral threads can carry an audience. A private ephemeral thread — a recital discussion for just three people that expires in 30 days — is a valid, first-class configuration. The audience entry lives in the ephemeral log and dies with the thread.

Anything you can do in a permanent thread you can do in an ephemeral one, except: notices, membership entries, supersede entries, revocations, branches, archives, and reopens. Those are governance actions and don’t belong in a container that’s going to disappear. Ephemeral threads carry conversation and audience, nothing structural.

Deleting a thread.

Only ephemeral threads can be deleted. Permanent threads are permanent by definition — the whole point of the tamper-evident log.

An ephemeral thread ends in one of two ways:

Auto-seal at TTL. The hub’s background task notices the thread’s deadline has passed and runs the seal ceremony automatically. Uses a pre-signed tombstone entry the creator provided at open time.
Manual seal. The creator opens the thread, taps the … menu in the banner, and confirms Delete this thread now. Only the creator can seal early — if you want the board to have that power, the way to get it today is to revoke the creator, which is a governance act.

Rule. Once sealed, a thread accepts no further writes — not from the creator, not from anyone in the audience. The hub rejects them. The tombstone entry is durable and public in the main log; the sealed final STH is durable in a separate table. Members who kept a local copy of an entry can still prove it existed against the sealed STH.

Revoking a member.

Revocation is a governance action, signed by the root key. It says “this pubkey is no longer a valid participant on this hub, as of this timestamp.”

From that moment:

The revoked member can’t authenticate — their session token is rejected, they can’t post, they can’t /sync, they can’t /stream.
They stop appearing in the delivery-status card on future messages. The card lists currently-attested members only.
Anything they signed before revocation stays verifiable. Their receipts stay durable in the log. Their past posts remain readable. Cove doesn’t retroactively erase history when someone leaves.
They stay in the directory manifest as a revoked entry with a timestamp — the record of their tenure survives, even though their access is cut.

Rule. Revocation is by timestamp. Entries signed before the revocation are still valid; entries signed after are rejected by the hub.

Delivery and receipts.

Every notice, post, and reply generates a signed receipt from each recipient when they read it. The receipts are entries in the log — verifiable, timestamped, tamper-evident. They’re what makes “did Alice read this” a factual question with an audit trail, not a matter of trust.

The delivery-status card you can tap on any message answers “who has ack’d this?” against the current membership:

The author of the message is treated as ack’d by construction — they signed it, they saw it.
Currently-attested members are partitioned into acked / not-yet.
Revoked members are filtered out entirely — their historical receipts are still in the log for auditors, but the delivery card is a “who’s this been delivered to now” surface, and a revoked member can’t ack anymore anyway.
On audience-scoped threads, the card partitions only the audience, not the whole hub. Non-audience members are not “behind” on a message they were never a recipient of.

The receipt log is what makes “I never got the email” a claim that can be examined. The delivery card is what makes the examination cheap.

Rules can change — the shipped code is authoritative. If something on this page disagrees with what the current hub actually does, the hub wins and this doc is out of date. Ping the source repo with the discrepancy and we’ll fix it.