Skip to content

Leave this node

View as Markdown

When you have moved an identity to another host, tell this one to forget it:

hdtp-gateway account leave -slug me # shows what it would erase, erases nothing
hdtp-gateway account leave -slug me -yes # erases it

It refuses an identity this node serves at its own address for it right now — which is what “delete it at the old host” would name after a move to another address on this same node — unless you add -force-current.

It erases every record of the identity at once: its contacts, chats, media no other identity here uses, invites, integrations and their OAuth client credentials, tokens scoped to it, its settings, and every leaf key this node held for it. The live node stops answering for it straight away, as for an address it never served.

The audit trail is the one thing the erase does not reach at once: it is append-only (by trigger) and hash-chained. HDTP §9 asks a host to “keep nothing beyond what law compels”, so the rows that name the identity by its account id — with its slug and its contacts’ fingerprints as they wrote them — stay in the live trail for audit_archive_after (90 days unless you set it: HDTP_AUDIT_ARCHIVE_AFTER=30d, or audit_archive_after in the config file), long enough to review the leave on the portal’s audit page. Then the hourly sweep moves every one of them to <data_dir>/audit-archive/<account-id>-<first>-<last>.jsonl (mode 0600) and writes one audit_archive row that names the segment and its hashes, not the identity. (Rows you had already moved to the head archive with audit archive -through N stay in that file.) hdtp-gateway audit verify (node stopped) checks the table and the archives as one chain and reports a changed or missing archive as broken. The archive is kept. If law requires its rows to go, hdtp-gateway audit erase-archive -file <name> keeps only each row’s seq and hashes, so the chain still verifies, and records that it did (SPEC §3.11, §11.6).

On SQLite the leaf keys are destroyed, not only deleted: the node zeroes deleted rows (secure_delete) and truncates its write-ahead log after the leave. On Postgres it cannot: a deleted row stays as a dead tuple until VACUUM reuses its space, in the write-ahead log until the segment is recycled, and in every backup — sealed under the node’s keyring, but not destroyed. SPEC §3.9 names this divergence.

The address stays reserved until the last leaf issued for it expires (HDTP §9): until then no identity can be created under that slug here, and no signing request can name that address. The command prints each address it reserved and until when. It is refused while a move campaign for that identity is running (account announce -slug me says when it has finished). There is no undo, and no portal or owner-MCP button: like import, it needs shell access on the host.