diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-15 00:50:05 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-15 00:50:05 +0200 |
| commit | f4d04741379e77d2ef86cccc93856e590bfe1082 (patch) | |
| tree | e3a094f9a8778cfcb8b3bd49ca422a28e2434104 /docs | |
| parent | 76724252d08162d4df39090af19796054bf4add8 (diff) | |
| download | meshbay-f4d04741379e77d2ef86cccc93856e590bfe1082.tar.gz | |
feat(logs): keep the username on records the account no longer answers for
The connection log took the name from a join on `users`, and deletion
tombstones that row — so every record belonging to a deleted account
reported `deleted-3f9a1c`, which is the one answer that helps nobody. The
log is kept for a legal retention period precisely so it can say who did
what; losing the name at deletion kept the data and lost the point of it.
`ip_logs.username` is written as the account is erased, and stays NULL
while the account is alive, where the join is better because it cannot go
stale. The admin view prefers the stored name when there is one: the join
still answers after deletion, just with the tombstone.
Releasing the username for re-registration and keeping it in the log are
separate things, and the guide now says so.
On the node side, the pre-proof audit line records the username the
session already knew, instead of leaving the column empty.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/USERGUIDE.md | 5 | ||||
| -rw-r--r-- | docs/meshbay-draft-v5.md | 3 |
2 files changed, 6 insertions, 2 deletions
diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md index a8991b1..214b6e9 100644 --- a/docs/USERGUIDE.md +++ b/docs/USERGUIDE.md @@ -176,7 +176,10 @@ What deletion does **not** do: ask the operator — `meshbay-node member unpin <user>` and deleting your files are their commands to run (§4). - **It does not erase the connection log.** IP records are kept for their legal retention - period and stay attributable; that is what they exist for. + period and stay attributable: the username is copied onto those rows as the account is + deleted, so the log still says *who*, and does not answer `deleted-3f9a1c` for exactly + the records anyone would be asking about. Releasing the name for re-registration and + keeping it in the log are separate things. Deletion is refused while you still own a group. Hand the group over or delete it first — otherwise its members would be stranded. The error names the groups blocking you. diff --git a/docs/meshbay-draft-v5.md b/docs/meshbay-draft-v5.md index 68f6843..a8b7e4b 100644 --- a/docs/meshbay-draft-v5.md +++ b/docs/meshbay-draft-v5.md @@ -358,7 +358,8 @@ password hash cleared, node linking key dropped, memberships, notifications and tokens removed, active access tokens refused at once by status check rather than left to expire. Two things survive on purpose. The IP log is kept for its legal retention period and stays attributable, since detaching it would keep the data and lose the only thing it -is for. And **nothing on a node is touched**: files, the pinned identity and the keypair +is for — the name is copied onto those rows as the account goes, since the join that used +to supply it would answer with the tombstone. And **nothing on a node is touched**: files, the pinned identity and the keypair bundle live on machines the hub does not command, which is the same sovereignty that makes §5.5 work. Deleting the hub account is not an erasure request to the operators who host you — the operator interface (§5.3) is where that happens. Deletion is refused outright |