@bobfrankston/rmfmail 1.2.292 → 1.2.294

package/.commitmsg

@@ -1,29 +1,23 @@
-Trusting a sender must not turn on their tracking pixels
+A union merge cannot express a removal — so removals are now stated
 
-Bob 2026-08-28, on a newsletter he subscribed to: "I don't need the spam
-reminder but I don't want to say show remote content in order to prevent
-tracking." He was right, and the shape of the bug is that the allowlist was
-answering two different questions with one list. The only gesture in the whole
-app that said "this correspondent is fine" was the remote-content banner's
-"Always: …", which buys a tracking pixel with every vote of confidence.
+Toggling the new trust entry back OFF exposed the other half of yesterday's
+merge bug: the IPC returned `{trusted: false}`, the entry left the local list,
+and the union with the cloud copy handed it straight back. The same has been
+true of `flagSenderOrDomain` since it was written — "unflag this sender" has
+always been a no-op whenever a cloud copy existed.
 
-Two lists now, both in allowlist.jsonc:
+`mergeAllowlists(local, cloud, removals?)` now takes the values this write is
+deleting on purpose, per key, and subtracts them after the union. Everything
+not named stays additive, so a second machine's entries are exactly as safe as
+before — the property that saved this file in the 2026-07-23 wipe is
+untouched. `saveAllowlist(list, removals?)` passes it through, and both
+toggles name what they removed.
 
-  senders / domains                 load their images, and I trust them
-  trustedSenders / trustedDomains   ONLY stop warning me about them
+Inference was never going to work here: a value missing from the local copy is
+indistinguishable from a value another machine just added, which is precisely
+why the union was written that way. Stating the removal is the only thing that
+tells the two apart without a tombstone log.
 
-Both feed `senderTrusted` in the store; only the first feeds `allowRemote`, and
-that line carries a comment saying why it must never be widened to the second.
-
-The trust note gains the action it was missing: **"Stop warning about
-‹address›"** and **"Stop warning about *@‹domain›"**, naming the sender rather
-than saying "this one" so the choice is checkable afterwards. New IPC
-`trustSenderOrDomain` (toggle, like flagSenderOrDomain) wired through all six
-places — service, jsonrpc, web-service, web-jsonrpc, android-bootstrap,
-api-client + mailxapi.js; the bridge-contract guard passes at 110 client calls.
-
-The buttons appear only where the server's own verdict is the WHOLE finding and
-the sender is proved. A forgery banner gets no such button: no list should be
-able to silence "this message is not what it says it is", and there is nothing
-to trust when identity is the thing in doubt. A failed write reports itself on
-the button rather than looking like it worked.
+Two more tests in tests/allowlist-merge.test.ts: a stated removal sticks while
+its neighbours stay, and removals match case-insensitively like every other
+address comparison in this codebase.

package/client/android-bootstrap.bundle.js

@@ -4122,7 +4122,9 @@ var init_web_settings = __esm({
       domains: [],
       recipients: [],
       flaggedSenders: [],
-      flaggedDomains: []
+      flaggedDomains: [],
+      trustedSenders: [],
+      trustedDomains: []
     };
     PREV_KEEP = 5;
     SHARED_REFRESH_MS = 5 * 6e4;