Three additions.
The decision the inbound path makes now has a name and a home --
MarmotDirectMessage.classify -- and the doc says why it is separate from
the filing of it: only the filing needs a database, so splitting them is
what lets the check that replaces MIP-03 be tested at all.
A security property found while writing those tests, which I had asserted
backwards. Relabelling a seal with another member's pubkey does not get as
far as the signature check: NIP-44 derives the conversation key from the
pubkey being claimed, so a relabelled seal is undecryptable by the person
it was encrypted for. The label is bound to the key rather than asserted
alongside it, and the outcome is a message the recipient genuinely cannot
read. verify() catches the narrower case of a seal altered after signing
in a way that survives decryption.
An honest list of what has no automated test and why -- the recipient
validation and the outbound id lookup (both need a database), the two
transcript renderings (no Compose UI test dependency in this project), and
anything touching a real MlsGroup. Better written down than rediscovered
by someone assuming a green suite means the path is covered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The reasoning behind this is not recoverable from the code, which is the
bar docs/README.md sets for having a document at all. Three things in
particular would otherwise have to be rediscovered by whoever changes this
next, and two of them are traps.
Why the wrap uses a throwaway key rather than the sender's own -- and what
that does not buy. It does not hide the sender from the group: MLS
authenticates every application message to a leaf, so the identity is
there regardless. What it costs is a carve-out in MIP-03's pubkey check
and the sender's ability to ever read their own messages back.
Why the check that carve-out removes is not a hole. The authorship claim
moves from the wrap's plaintext pubkey to the seal's verified signature,
bound to the MLS leaf that sent it -- strictly harder to forge than what
it replaced.
The one query that would broadcast one of these. What this builds is a
genuine, correctly signed NIP-59 gift wrap, indistinguishable from what
the NIP-17 path would be right to publish, and the only thing keeping it
off a relay is that it never becomes a GiftWrapPayload.
Written against what shipped rather than what was planned, so it records
two deviations. senderIdentity is resolved in NostrDao rather than added
to GroupEventResult.ApplicationMessage, because quartz is a binary
dependency here and the local checkout is a reference copy, not a build
input. And a failed validation drops the message and logs rather than
throwing, because the caller is inside storeNostrEvent's transaction.
The unbuilt parts are listed as absences rather than left implied: there
is no member picker, so a private message can only be a reply to one
somebody already sent, and nothing in the UI yet tells a user in words
that the group can see who they messaged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
