chatmail-core/draft/relay-removal.md

Make relay and mailbox removal immediate (after keyupdates land)

Today "remove" only unpublishes a relay (set_transport_unpublished()): the transport keeps its IMAP loop and is garbage collected only after 90 days without incoming messages, which senders control and which can therefore mean never. The removal delay is unpredictable and invisible, contradicts what the UI suggests, and what a good privacy policy wants: the profile keeps logging into a relay the user asked to remove, and on top the relay keeps the mailbox active for 90 days after the last login, storing incoming messages etc.

Once keyupdates (https://github.com/chatmail/core/pull/8621) lands, I suggest switching to a "remove means remove" approach:

• set_transport_unpublished() triggers remove_transport directly, and syncs to our own devices through the removed_transports tombstone (which old cores already apply), and drops its entry from context.metadata so calls and iroh stop using it.

• Migration determines unpublished relays and removes them, locally per device.

• The whole "unpublished" machinery vanishes: the 90 day collection, last_rcvd_timestamp, the eviction branch of try_make_space_for_new_relay(), and is_unpublished in the UI-facing APIs. set_transport_unpublished() gets renamed to remove_transport.

• A new core/relay METADATA protocol to remove a mailbox and all its content on a relay, causing immediate NDNs to any contacts trying to send there still, therefore completing the "remove means remove" approach proposed by this issue.

  Note that handle_ndn() fails the whole message on one bounce so a message delivered through a surviving relay would be marked failed by the removed relay's NDN. It's a pre-existing problem but immediate relay-removal may increase its occurrence, but then again keyupdates may mitigate it in real life.

Known problems

In multi-relay setups removing a relay loses messages during the replacement gap: if the removal is replacement-shaped and one of our contacts sends us a message while they knew only removed relays we already don't listen to anymore. This happens for example with single-relay profiles when you add a relay, then remove the previous. Keyupdates minimize the replacement gap often to under a minute but do not eliminate it. To help reduce lost/not-received messages during the "replacement gap" we may only terminate the active scheduled IMAP tasks some minutes after removal. Right now, we don't terminate them at all, and rely on a restart cleaning removed relays up which is fine only for mobiles.

Replacement-shaped relay changes also invalidate invite links that point to already removed relays that we don't listen to anymore.

Both problems are acceptable because the relay-list is still in "advanced options" and we could provide a warning if we discover a replacement-shape: We can record a transports.published_since column which is written once, and synced also to old cores (i.e. no wire changes), and can help deciding about posting a warning to users by helping to answer the question "is there an older surviving relay if I delete this one?" and "is there a non-expired invite link that points to since-removed relays?" and basing a future warning to users on the answers. Independently from a warning, recording relay age is also useful for any automated add/remove decisions later.