Revocation

Membership in a Sync Group is never permanent. Any current member can remove another. Any current member can blow up the whole group.

There are two removal operations, and which one you want depends entirely on why you’re removing a device.

TL;DR

Soft removal

Use it when a device is no longer wanted but isn’t a threat. Any current member calls removeMember() with the target’s noise public key. trueseal-sync issues a new Group Manifest that excludes the target and pushes it to every remaining member.

What happens:

• Remaining members get the new manifest and start filtering anything the removed device sends — if the sender isn’t in the manifest, the blob is dropped on the floor.
• Remaining members stop addressing future blobs to the removed device.
• The removed device, when it eventually gets the new manifest, fires onRemovedFromGroup().

What doesn’t happen:

• No keypairs rotate.
• Nobody has to reconnect.
• The removed device’s keypair is still technically valid. It can keep pushing blobs to the relay and the relay will accept them, but every remaining member silently discards them because the sender isn’t in their manifest anymore.

The honest limit. Soft removal is cooperative, not cryptographic. It works because legitimate clients respect the manifest. A compromised or adversarial client on the removed device can bypass the filter. For routine cleanup, that tradeoff is fine. For a real security incident, it’s not enough.

Destroy Group

Use this when a device is stolen, compromised, or otherwise untrusted — when you need a cryptographic guarantee that nothing future ever lands on it, no matter what software it’s running.

Any current member calls destroyGroup(). trueseal-sync pushes a Revoke message to every known member, then every device — including the initiator — wipes its local state and rotates its keypair on next launch.

What happens:

• Every device fires onGroupDestroyed() and wipes its local database: identity, manifest, outbox, all of it.
• Every device generates a fresh keypair on next launch.
• No legitimate device ever addresses anything to any of the old keypairs again. The compromised device’s old address is just a dead end.

The cryptographic guarantee. Exclusion works by key rotation, not by key blocking. The relay never blocks any key — it stays zero-knowledge. The compromised device stops receiving blobs because nobody is encrypting to its old public key anymore. The relay isn’t part of the guarantee at all.

The cost. Every member has to re-pair. The group is fully torn down. That’s the price of a cryptographic guarantee, and it’s intentional.

What revocation can’t do

Past blobs are gone — for them. A device that already received and decrypted blobs before removal still has that data. Revocation stops future leakage; it can’t reach back in time. That’s a fundamental limit of any system without a central authority that can enforce deletion.

Soft removal can’t become cryptographic without rotation. In a zero-trust system with no key revocation server, the only way to cryptographically exclude a device is to rotate keypairs so that its old address stops being valid. Without rotation, enforcement is cooperative. Full stop.

A future version may add targeted key rotation — rotate everyone except the removed device, without nuking the whole group. That would give you cryptographic single-device removal without forcing a full re-pair. It’s deferred on purpose: it needs a distributed key agreement sub-protocol, and that’s a real jump in complexity for this primitive.

No permission hierarchy

Any current member can remove any other member. Any current member can destroy the group. There’s no admin, no owner, no privileged device.

If your application needs an admin layer — only admins can remove members, only the group creator can destroy — implement that policy above trueseal. What trueseal enforces is much narrower: the issuer of a manifest update has to have been a member at the time of issuance. That’s the whole rule.