dandri/simplex-chat
1
0
Fork 0
mirror of https://github.com/simplex-chat/simplex-chat.git synced 2026-10-15 19:50:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: channel multi-owner overview: deleting the chat after a leave stopped before step 5 sends DEL for any owner

Browse Source 
R3-1: the creator's through its link connection, a promoted owner's with its credentials, matching the destroy paragraph and the implementation plan.
This commit is contained in:
spaced4ndy
2026-10-14 17:32:03 +00:00
parent 0ffa85aa7a
commit 661adb5f65
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plans/2026-07-15-channel-multi-owner.md
+1 -1
View File
@@ -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.