The consent-first archive

Two gates stand before the open web

Nothing a member posts appears on the public archive unless two independent conditions hold. The first belongs to the community: an operator self-hosts the software, points capture at their own group, and stands up a public archive page for it. There is no hosted service quietly collecting groups, and where no public page exists there is no public surface at all.

The second gate belongs to the member, one person at a time, and it cannot be operated from above. The consent write path uses the member id of whoever sent the message and has no parameter for acting on somebody else's behalf. Ask the bot to publish another member and she refuses and does nothing. Administrator rights change nothing, because this path contains no concept of an administrator at all.

So the asymmetry is deliberate. An operator can end publication for everyone by taking the public page down. An operator cannot begin it for anyone.

An operator can switch the archive off for everybody. Nobody, operator included, can switch a single member on.

/publish, /unpublish, or just say so

Sending /publish opts you in. Sending /unpublish opts you out. Both are exact commands, and both take effect immediately.

You can also just talk to her. Address the bot by the name its operator gave it and say that you want to be published, and the natural-language route reaches the same decision. It is deliberately slower than the command: spoken, a consent change never happens on a single message. She proposes, and waits for an affirmative answer inside a short follow-up window. A bare keyword in the middle of a sentence is not enough, and a request that names somebody else is refused before anything else is considered.

Both routes call one function. The dialogue engine holds no consent SQL of its own, so the spoken path cannot drift away from the command path over time. The only thing that differs is a stamp recording which route the decision came in through. Either way the decision is appended to a journal that also stores the consent record exactly as it stood beforehand.

One write path. The spoken route and the slash command are the same decision, recorded the same way.

Forward only, and what that means on the day

Opting in stamps the timestamp of the message that carried the opt-in. A message can be published only if it was sent at or after that moment. Everything said before is not published: not later, not by the operator, not by any command. There is no route in the system that reaches backwards.

In practice: you joined in March, you opt in today, and today is where your public archive begins. If you revoke and later opt in again, the clock restarts at the new opt-in, so a second opt-in does not by itself bring the earlier period back. Bringing that back is a separate, explicit restore, and you have to ask for it instead of opting in again: a fresh opt-in clears the revocation and closes the restore route for good. It is also only available if you chose to hide rather than delete.

Consent binds to the stable group member id, never to a display name. Leave the group and rejoin and you are a new member id, so consent does not carry over. That is intended. Rejoining asks the question again.

Published means the open web

This deserves to be said plainly, because members deserve it plainly. Published content sits on the public internet. It is server-rendered so search engines can index it, it is full-text searchable on the archive itself, it appears in the sitemap and in the RSS feed, it has a permanent link, it produces a preview card when somebody shares that link, and it carries your display name.

That is exactly the point of the feature, and it is exactly the risk. Withdrawal removes content from the archive and from every route the archive serves. It cannot recall what a search engine has cached, what a feed reader already downloaded, or what somebody saved as a screenshot. Nothing that publishes to the open web can promise otherwise, and copy that suggests otherwise would be lying to you.

If you opt in, strangers can find your words through a search engine. That is what opting in is for.

Publication is a question, not a stored flag

There is no published column on a message, and nothing is marked at capture time. Publication is a database view, re-evaluated on every single read.

It is true when all of the following hold: the message was not deleted by its author, was not deleted inside the group, was not rejected by moderation, is not under quarantine, its sender has a consent record that is not revoked, it was sent at or after that member's opt-in, it does not fall inside an interval the member spent hidden, its category has not been switched off by the operator, and, if it is one of the bot's own replies, the member message it answers publishes too.

This is why withdrawal is instant everywhere instead of a background job. There is nothing to backfill, no cache of published ids to invalidate, and no state in which a stale flag keeps something visible after the consent behind it changed. It also means a mistake can only ever be a mistake in one predicate, rather than in whichever of the public routes forgot to check.

Withdrawal: one word, everything at once

Send /unpublish, or say it to her. The revocation is recorded, and because publication is derived, every message you ever published leaves the public set on the next read. Page, search results, filters, media, feed, sitemap, embed. All of it, at the same moment, with no per-route work and nothing to wait for.

Her replies to you go with them. A bot answer publishes only if the member message it answers publishes, so withdrawing your question also withdraws the answer that was written to it.

The withdrawal itself is never deferred. Not by a report, not by a review, not by an evidence hold. Hiding is always immediate for the member. Only physical erasure can ever wait.

Then you choose: hide or delete

Withdrawal hides. What happens to the hidden content afterwards is a second question, and she asks it right away. Until you answer, the state is explicitly open: hidden everywhere, and consent to destroy nothing. A destructive decision gets no default.

Hide keeps everything. Your content is out of the public archive and out of search, it is retained, and it can be restored by you and by nobody else.

Delete erases. Rows and files go, and with them the extracted links, the mentions, any reports including the reporter's own free text, and the bot's paired reply. The search index hangs off the row and goes with it, so there is no separate index left to purge. Deletion also erases the SimpleX core's own copy on the server, which used to survive everything.

The two answers are deliberately not equally easy. The word hide keeps them, and so does saying no. Only a destruction word standing on its own as a single word does it: delete, or destroy, or the equivalent in the language the bot is configured for. Only a destruction word standing on its own as a single word does it: delete, or destroy, or the equivalent in the language the bot is configured for. A phrase like yeah delete everything does not do it, and neither does a near miss or a typo.

While you are withdrawn, the choice is not a one-way door. Someone who chose hide can come back later and ask for deletion, and it is carried out. Someone whose deletion was deferred by an evidence hold can switch back to hide and call the deferred destruction off. Exactly one thing is final: deleted is deleted.

Hiding is reversible. Deleting is not. Everything else about the choice can still be changed while you are withdrawn.

Restoring, and the gap you spoke into

Restoring is available only after hide, only to the member themselves, and never after delete. It clears the revocation while keeping your original opt-in timestamp, so your archive comes back as it was instead of being stranded behind a new forward-only cutoff.

Because restoring increases your public exposure, it is confirmed like an opt-in rather than acted on from a single word.

Everything you said while hidden stays unpublished, permanently. Each hide-and-restore cycle records the interval it covered, and messages sent inside such an interval are excluded from publication forever. You can hide and restore any number of times, and every gap keeps excluding its own messages.

A restore brings back what was public. It never publishes what you said while you were hidden.

What is captured, and why that is not the same as published

Within the group the operator has scoped, the bot captures text, images, video, voice messages, files and links. It follows edits, and it honours deletions made inside the group: a message deleted in SimpleX is never published from the archive.

Capture is not publication, and it is worth being exact about that. Messages are stored in the operator's own database whether or not you have opted in, because publication is decided at read time from your consent. If you never opt in, your messages exist in a database on the operator's server and on no web page anywhere. The archive is self-hosted, so this is the same trust you already extend by being in the group at all.

Media lives on disk, never as bytes in the database. Originals are encrypted at rest under a separate key. What the public archive serves is a stripped derivative with the metadata removed, so a published photograph does not carry the camera and location data the original had.

What deletion honestly does not reach

Deletion removes content from the live archive immediately and through every path the application serves, and it now reaches the SimpleX core's own copy on the host as well. It does not reach the operator's database backups, which keep fourteen generations and age out on their own schedule. It does not reach what a feed reader or a social scraper already fetched. And it does not reach anything anybody saved for themselves.

The member-facing wording therefore speaks of removal plus backup expiry, and deliberately avoids the word unrecoverable, because overwriting does not guarantee that on modern storage. A promise nobody can keep is not a privacy feature.

Reports, evidence holds and quarantine

The public archive accepts content reports from anyone, and the operator's review and takedown decisions are audited.

An open report can place an evidence hold on an item. A hold defers destruction and nothing else. It never blocks hiding and never changes what is published, because reporting must not become a way to push somebody out of public view. There is at most one live hold per message, so repeated reports cannot compound or extend it, and report holds expire on their own so an unreviewed report cannot become a permanent block through neglect.

If a member asks for deletion while some of their items are held, the unheld items are destroyed at once, the held ones stay hidden and are queued, and she says so rather than pretending the whole request completed. The intent is recorded durably, so it survives a restart and the member never has to ask twice.

Quarantine is the exception that also withholds. An operator escalation or a screening match makes an item unservable to everyone, and the files are moved out of the media tree entirely rather than merely dropping out of a query.

Hash screening for known illegal material In development

The custody half is built and verified: encryption at rest, quarantine outside the media tree, holds, the deferral path and the operator's review surface. Detection is not built. No screening provider is connected, and the null provider transmits nothing to anyone.

When a provider is connected, the limits stay what they are and will be stated as such. Hash matching finds known material only, never new material, and a no-match result is not a statement that anything is safe. A match preserves and quarantines, it never deletes. Screening results are never shown to members. Reporting duties, retention periods and the point of contact are legal questions for a lawyer and are deliberately absent from the code.

No screening provider is configured. The mechanism is built; the detection is not.