Three kind:1059 sync filters named the wrong pubkey.
ChatMessageListViewModel asked for `#p:[peer]` with no author constraint,
which subscribes to every wrap anyone has ever sent that peer. None of it is
decryptable by us, and it is the direct source of the Invalid Mac saves fixed
in the previous commit. It now asks for `#p:[us]` on our own DM relays — the
only shape of gift wrap filter that can return something we hold a key for.
The peer's relays were the wrong place to look regardless: under NIP-17 a
sender publishes to the *recipient's* DM relays, so our mail lands on ours.
The two in NostrDao asked for `authors:[userPublicKey]` + `#p:[participant]`,
commented "messages from this relay that were sent by us". A gift wrap is
signed by the throwaway key from GiftWrapEvent.create, never by the sender's
identity key, so no author value we could know will ever match one. These
requests were queued once per participant and always reconciled to empty —
failing silently rather than loudly, which is why they outlived the bug that
made the third filter visible. Both `if (chatMessageRelayListEvent != null)`
branches held nothing else, so each is inverted to the `== null` case that
does the real work: warn, and queue a profile sync for the participant whose
DM relay list we are missing. Nothing is lost; neither filter ever returned
an event.
Two things worth recording about what a filter can and cannot express here.
A wrap discloses only its recipient, so "the messages in this conversation"
is not askable — `#p:[us]` pulls the whole inbox and that is the narrowest
correct request. That is the privacy property being paid for, not a
limitation to work around.
Sent-message recovery is likewise not a filter problem. It needs a second
wrap addressed to ourselves at send time, which giftWrapAndBroadcast does not
yet emit; the `#p:[us]` filters already in place would pick those up with no
new subscription.
purpose on the chat message request changes from "sent-messages" to "chat",
matching the now-identical filter in ChatRoomListViewModel. Since computeId
buckets by minute and NegentropySynchronizeRequestDao upserts, the two
collapse into a single request rather than racing as separate rows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
f38a5f12f3