# Leave this node

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

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.