From 661adb5f65cce613a80737b2e00fef440db2ae84 Mon Sep 17 00:00:00 2001
From: spaced4ndy <8711996+spaced4ndy@users.noreply.github.com>
Date: Wed, 14 Oct 2026 17:32:03 +0000
Subject: [PATCH] docs: channel multi-owner overview: deleting the chat after a
 leave stopped before step 5 sends DEL for any owner

R3-1: the creator's through its link connection, a promoted owner's with its credentials, matching the destroy paragraph and the implementation plan.
---
 plans/2026-07-15-channel-multi-owner.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plans/2026-07-15-channel-multi-owner.md b/plans/2026-07-15-channel-multi-owner.md
index e680769ab3..73c55d897b 100644
--- a/plans/2026-07-15-channel-multi-owner.md
+++ b/plans/2026-07-15-channel-multi-owner.md
@@ -240,7 +240,7 @@ It cannot see, verify or promote a silent subscriber who joined earlier (§11).
    - every leaver erases its member private key. A later load of the group generates an unrelated key, so the erased one is gone.
 
 **Repeating a leave.** A crash or a failed step leaves the leave half done. What happens next depends on where it stopped:
-- **Before step 5.** The membership stays current, because applying `revokedOwners` never changes this device's own membership (below). The app keeps offering Leave. A repeated leave that finds its memberId already in `revokedOwners` continues at step 4, and an `AUTH` error at step 4 counts as done. Until then, the device keeps its key, and devices that have not read the link data since still treat it as owner. Deleting the chat in this state is still a current owner's destroy: it sends `x.grp.del` and, for the creator, `DEL` on the link queue.
+- **Before step 5.** The membership stays current, because applying `revokedOwners` never changes this device's own membership (below). The app keeps offering Leave. A repeated leave that finds its memberId already in `revokedOwners` continues at step 4, and an `AUTH` error at step 4 counts as done. Until then, the device keeps its key, and devices that have not read the link data since still treat it as owner. Deleting the chat in this state is still a current owner's destroy: it sends `x.grp.del` and `DEL` on the link queue, the creator's through its link connection, a promoted owner's with its credentials (below).
 - **After step 5.** The chat is left. Deleting it completes step 6's link deletion locally, never with `DEL` (below).
 
 **Why no `DEL`.** Today `APILeaveGroup` deletes the link connection with `DEL` on the shared queue (`deleteGroupLinkIfExists`, `Commands.hs:3246`, `Internal.hs:1739-1748`). After step 4 the creator's key is normally no longer authorised, but a concurrent `RKEY` by another owner can authorise it again (§3), so the deletion is local.