39eac61838
mantra had moved on ~30 commits, several of them in exactly this area — and it turns out both branches independently found the same bug and drew the same conclusion about the same filter. **The overlap.**f38a5f1fixed the three kind:1059 filters that named the wrong pubkey, including the two `authors=[userPublicKey]` requests in NostrDao that could never match a wrap signed by a throwaway key. This branch deleted those same two blocks, inverting the same `if` to the `== null` case, for the same reason. The code merged to the same shape; only the comments conflicted, and they are combined. **Nip17Filters wins, and the live subscription now defers to it.**ad3304aextracted the inbox filter to one definition precisely because it had been wrong in three call sites, with the no-`since` reasoning this branch arrived at separately. Keeping a fourth copy inside LiveSubscriptionManager would recreate the problem that commit exists to solve, so: - queueCatchUpSynchronization now calls Nip17Filters.inbox() instead of building an identical SynchronizationFilter with its own limit constant, - Nip17Filters gains liveInbox(), the same shape as a quartz Filter for a REQ rather than a SynchronizationFilter for the queue, and giftWrapFilter() defers to it. Two types for one filter is not duplication worth removing — the queue stores one and hashes it for computeId, a live subscription puts the other on the wire — but they belong side by side, because drift here means one of them quietly stops matching mail. **ChatMessageListViewModel keeps this branch's resolution.** mantra had it refresh our own inbox on open (Nip17Filters.inbox on our DM relays, purpose "chat"); this branch removed that call entirely. Both were right when written, and the merge is where the second becomes true: LiveSubscriptionManager holds exactly that filter open on exactly those relays for the whole account and reconciles it on every foreground, so opening a chat has nothing left to ask for. The redundancy is now recorded in the comment where the branch used to be, so it reads as superseded rather than dropped. Discovery — the kind-10050 lookup for a participant we cannot yet address — is untouched, and the purpose is no longer a conditional now that only one case reaches it. The commonTest coroutines-test dependency arrived on both sides; the comment gives both reasons. Verified: 154 tests pass, both branches' suites included — Nip17FiltersTest and the marmot direct-message suites alongside this branch's 46. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
21 lines
1.9 KiB
Markdown
21 lines
1.9 KiB
Markdown
# mantra docs
|
|
|
|
Notes on the parts of this app whose behaviour is not recoverable by reading the
|
|
code alone — where the reasoning lives in a protocol, a failure mode that is
|
|
silent, or a decision that looked arbitrary and was not.
|
|
|
|
| document | covers |
|
|
|---|---|
|
|
| [shared-key-ceremony.md](./shared-key-ceremony.md) | ChillDKG over NIP-17: the rounds, the approval gates, the chat transcript, participant ordering |
|
|
| [shared-key-derivation.md](./shared-key-derivation.md) | deriving further keys from the group's threshold key with FROST tweaks — why not BIP32, why no chain code, and the one rule that must not be broken |
|
|
| [marmot-membership.md](./marmot-membership.md) | how members join an MLS group, and the epoch race that makes a missing member look like a successful invite |
|
|
| [marmot-direct-messages.md](./marmot-direct-messages.md) | a one-to-one message inside a group as a stock NIP-59 gift wrap — what its MIP-03 carve-out costs, why the sender cannot read their own, and the one query that would broadcast it |
|
|
| [mls-skipped-keys.md](./mls-skipped-keys.md) | why a group event that arrives a moment late is dropped for good, which flows trigger it, the quartz fix, and the partial mitigation in this app |
|
|
| [long-running-sync.md](./long-running-sync.md) | the chat subscriptions that stay open instead of pulling once per screen — why the request queue could not simply hold one, and how the group filter follows the room list |
|
|
| [dead-code.md](./dead-code.md) | code in the sync and relay stack that nothing calls, why each piece is still there, and which of it is a bug rather than a leftover |
|
|
|
|
Start with the ceremony if you are new to this area; the Marmot notes all assume it.
|
|
Read the skipped-keys note before debugging any "the other device never got it"
|
|
report — it is silent, and it looks like every other kind of delivery failure. The
|
|
sync note stands alone, and the dead-code inventory reads as a follow-up to it.
|