Two nullable columns and the v5 migration that adds them, ahead of the
code that fills them, so the schema lands on its own and can be reverted
on its own.
MarmotInnerEvent.directMessageRecipientPublicKey is the outbound signal.
The notary reads a queued row and has no other way to know a message is
meant for one member rather than the room -- the plaintext is identical
either way -- so this is what routes it into the gift wrap path. Inbound
rows leave it null on purpose: the recipient is on the wrap's `p` tag,
which is where every member reads it from, so a second copy on the row
would be a second thing that can disagree.
ChatMessage.directMessageRecipientPublicKey is what the transcript reads.
Both lines a direct message can produce need it -- the one its two parties
see, and the "sent a private message to Bob" line everybody else gets --
and holding it on the row keeps the view model off a join for a fact it
already has to render.
MarmotInnerEvent hand-writes equals and hashCode over every field, so both
are extended too. A field missing from those is not a compile error and
not a test failure; it is two rows that differ comparing equal, which
surfaces much later as an upsert that does nothing.
Room generates the migration -- verified as two ADD COLUMNs with no table
rebuild, so nothing is copied and nothing can be dropped:
ALTER TABLE `ChatMessage` ADD COLUMN `directMessageRecipientPublicKey` TEXT DEFAULT NULL
ALTER TABLE `MarmotInnerEvent` ADD COLUMN `directMessageRecipientPublicKey` TEXT DEFAULT NULL
Rows written before this come back null, which reads as "not a direct
message" -- the only answer that is true of all of them.
v5 is an AutoMigration entry rather than a hand-written Migration like
MIGRATION_3_4 next to it, because that one rewrote data without changing
shape and this one changes shape without touching data.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
296011dcd5