Five protocol-level fixes and a batch of harness correctness fixes to get
the headless Marmot/Whitenoise interop harness from 1/13 to 5/13 passing
cleanly, with the remaining failures all rooted in wn's per-account
serial event-processor retry backoff (which drops undecryptable
pre-membership commits after several minutes) rather than amy behaviour.
quartz + commons
----------------
* MarmotGroupData: hold CURRENT_VERSION at 2. mdk-core (the Rust MLS
engine used by whitenoise-rs) strict-rejects v3 payloads with
`ExtensionFormatError("Trailing bytes in NostrGroupDataExtension")`
— our v3 welcomes and GCE commits never apply, so every cross-client
group flow dies at welcome processing. We still parse v3 happily on
the way in; we just don't emit it until mdk publishes the
forward-compat fix MIP-01 mandates.
* MarmotManager.updateGroupMetadata: MERGE extensions instead of
REPLACING. RFC 9420 §12.1.7 says GCE proposals blow away the old
extension list; callers that pass only [marmot_group_data] dropped
[required_capabilities], which peers then reject. Preserve every slot
except the one we're updating.
* MarmotManager.createGroup: new optional `initialMetadata` parameter
that bakes MarmotGroupData into epoch-0 GroupContext.extensions
directly. Without it, creators had to publish a pre-membership
"bootstrap" commit that no later joiner could decrypt — each such
peer then burned their retry budget on an undecryptable kind:445
before seeing the real state. Threaded through MlsGroup.create /
MlsGroupManager.createGroup.
* MarmotManager.mlsGroupIdHex: new translation helper so any code
juggling the MIP-01 nostr_group_id (what amy indexes on) and the
MLS GroupContext groupId (what mdk indexes on) can cross-reference
them without reaching into MlsGroupManager directly.
amethyst module
---------------
* Account.leaveMarmotGroup: self-demote before SelfRemove per MIP-01,
and promote a surviving member to admin first if the caller is the
sole admin (otherwise we'd throw "admin depletion"). Matches the
cli/GroupMembershipCommands.leave flow.
cli (amy)
---------
* Context.syncIncoming: don't advance `giftWrapSince` on empty polls
(so the first-ever sync doesn't bump the cursor past every
past-timestamped wrap we've ever been sent), subtract 2 days lookback
when filtering (NIP-59 randomWithTwoDays gift wraps can have any
createdAt in the last 48h), and only advance `groupSince` for groups
we actually received events for.
* Context.syncIncoming: after ingest, if any Welcome consumed a
KeyPackage, rotate and publish a fresh one immediately. MIP-00
requires this — a KP can only be welcomed once and leaving the
consumed one on relays just means later senders invite us with a
bundle we no longer have private keys for.
* Context.resolveGroupId: accept either nostr_group_id (amy's primary
key) or the MLS GroupContext groupId (what wn emits) on every verb
that takes a group id. Wired through GroupAdd/Remove/Leave/Metadata
/Read, Message send/list, and all the await* verbs so harness
scripts never have to juggle both forms for a single group.
* GroupCreateCommand: bake initial metadata into epoch 0 (see the
quartz change above). Dropped the now-redundant bootstrap commit
publish and tightened the JSON output to include `mls_group_id`.
* GroupMembershipCommands.leave: self-demote admin before SelfRemove;
promote an heir if we're the only admin, otherwise the GCE would
deplete admins and the leave aborts.
* MarmotIngest.ingestGiftWrap: unwrap the sealed-rumor layer. NIP-59
wrap is gift-wrap(kind:1059) → seal(kind:13) → rumor; the old code
only unwrapped once and then checked `inner.kind == 444`, which is
always false because inner is actually the seal. Unseal once more
before the Welcome check. This single fix is what unsticks every
amy-side Welcome ingestion.
wn harness patches + scripts
----------------------------
* whitenoise-defaults-env.patch: honour $WHITENOISE_DISCOVERY_RELAYS in
`Relay::defaults()` (release builds otherwise bake damus.io / primal
/ nos.lol into every new account's NIP-65 / Inbox / KeyPackage
lists, which breaks publishing and prevents the inbox subscription
plane from ever reaching an operational state in a sandbox).
* setup.sh: sleep 2s after amy's initial kind:30443 publish so
nostr-rs-relay has a chance to fsync before wn's first targeted
discovery query. Without it wn's `keys check` races the relay's
WAL flush and intermittently returns NotFound.
* lib.sh: peel wn's `{"result": …}` wrapper in `jq_group_id`,
`wait_for_invite`, `wait_for_message`, `wait_for_member`. Post-v0.2
wn `--json` output nests everything under `.result` (and
`groups invites[]` nests further under `.group.mls_group_id`) —
these helpers were still pattern-matching on the flat shape, so
they returned empty strings for a perfectly good response.
* tests-{create,manage,extras}.sh: track both group IDs per test
(amy's nostr + wn's MLS), pass each CLI the id it understands, and
bump the post-commit wait timeouts to 90–120s so wn's exponential
retry backoff has time to work through the pre-membership commits
it can't decrypt and get to the ones it can.
https://claude.ai/code/session_016kAxdp6ubB5CnF9URhCEzP
On the JVM, Log.d / .i / .w / .e were printing through \`println()\` which
lands on stdout. The amy CLI uses stdout as its JSON contract — any
Marmot/MLS command would restore state, emit a burst of DEBUG lines,
then emit the JSON object, and every caller piping through jq failed
to parse because the first non-empty line was a log line.
Switch to \`System.err.println\` inside PlatformLog.jvm.kt. Conventional
for CLIs (data on stdout, diagnostics on stderr), and the desktop app
already redirects as part of packaging. Callers who want everything
mixed can still \`2>&1\` at the shell level.
Fixes amy marmot group create / group add / message send etc. when
their output is captured by a shell script.
https://claude.ai/code/session_01M6dCKAF5Y1VyHGZPjzwDXq
Five extractions so the Amethyst UI and the new amy CLI share one
implementation for each piece of Marmot/identity behaviour instead of
reimplementing it per platform.
quartz additions:
- MarmotGroupData.bootstrap(..) + withMergedRelays(..): factory for the
metadata shape every inviter stamps on a fresh group and the outbox-
merge rule every admin commit carries forward.
- KeyPackageFetcher: (a) pure fetchRelaysFor union of target kind:10051,
target outbox, my outbox; (b) one-shot fetchKeyPackage; (c) publish-
side resolveKeyPackagePublishRelays.
- resolveUserHexOrNull: single entry point for npub / nprofile / 64-hex
/ NIP-05 identifiers. Uses the existing Nip19Parser + Nip05Client
infra so NIP-05 resolution is live over HTTP.
commons additions:
- MarmotManager.leafIndexOf(..): pubkey -> leaf index lookup used by
every removeMember caller.
- MarmotManager.addMember(nostrGroupId, keyPackageEvent, relays):
convenience overload that lifts the base64 decode into the manager.
- MarmotManager.buildTextMessage(..) returning a TextMessageBundle;
optionally persists the outbound inner event (CLI needs persist,
Amethyst relies on LocalCache loopback).
- MarmotIngest.ingest(event): routes kind:1059 / kind:445 through
unwrap -> processWelcome / processGroupEvent -> persist the decrypted
application message. Deliberately platform-agnostic.
Retrofits:
- Account.addMarmotGroupMember and fetchKeyPackageAndAddMember now take
a KeyPackageEvent directly; Account.keyPackagePublishRelays delegates
to KeyPackageFetcher.
- AccountViewModel.updateMarmotGroupMetadata uses bootstrap + merged.
- AccountViewModel.sendMarmotGroupMessage builds the kind:9 template via
buildTextMessage(persistOwn = false) to avoid double-persisting.
- AccountSessionManager's NIP-05 login branch delegates to
resolveUserHexOrNull; no more hand-rolled Nip05Id / nip05Client.get.
- CLI Context exposes nip05Client and requireUserHex; syncIncoming now
calls MarmotManager.ingest; all command sites use KeyPackageFetcher
+ the shared identifier resolver. Npubs util deleted.
https://claude.ai/code/session_01M6dCKAF5Y1VyHGZPjzwDXq
Answers "can MDK and marmot-ts see and talk to a user whose group was
created on Amethyst?" — yes, after four more spec-conformance fixes:
1. parent_hash chain (RFC 9420 §7.9.2): Amethyst's commit() and
externalJoin() now compute the parent_hash for every parent node on
the committer's direct path and seal the committer's LeafNode with
the correct leaf parent_hash. Amethyst↔Amethyst used to work only
because both sides stored empty parent_hash values; against a
strict peer (ts-mls, openmls) every Amethyst-authored commit was
rejected with "Unable to verify parent hash". processCommit()
now also patches the computed parent_hashes back into its tree so
treeHash() agrees with the sender — otherwise the epoch key
schedule diverges and AEAD tags mismatch.
2. REQUIRED_CAPABILITIES extension type: 0x0002 → 0x0003 per
RFC 9420 §13.3. The old value was ratchet_tree's slot, so Amethyst's
GroupContext.extensions carried a required_capabilities blob
labelled as ratchet_tree, and openmls rejected the GroupInfo
as Malformed (ratchet_tree is not valid in GroupContext). This
completes the extension-ID set from d7114fc (ratchet_tree,
external_pub) now aligned with the IANA registry.
3. verifyParentHash on the receive side now computes the expected
chain top-down from the post-update tree rather than reading
parent_hash fields that applyUpdatePath leaves as empty
placeholders.
4. An explicit parentHash parameter on buildLeafNode so COMMIT-source
leaves include the computed value in their TBS signature.
Test harness — reverse interop (Amethyst → outside world):
- quartz/tools/{mdk,tsmls}-vector-gen/emit-joiner-kp.{rs,mjs}
generate an MDK/openmls and a marmot-ts/ts-mls KeyPackage with
marmot_group_data (0xF2EE) and self_remove (0x000A) advertised in
capabilities so Amethyst's required_capabilities is satisfiable.
- AmethystAuthoredVectorGen.kt (env-var gated JUnit test) takes the
foreign KP, adds it to a fresh Amethyst group, and emits the
Welcome plus three application PrivateMessages as JSON.
- verify-amethyst.{rs,mjs} replay the joiner's private state,
call the foreign MLS library's join + process_message, and
assert the plaintexts match.
Both verifiers now print ALL PASS end-to-end:
* openmls ← Amethyst: joinGroup + 3× process_message ✓
* ts-mls ← Amethyst: joinGroup + 3× processPrivateMessage ✓
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
marmot-ts (the TypeScript Marmot client — browsers, Node, Bun, Deno)
wraps a completely different MLS implementation: ts-mls. That backend
shares no code with OpenMLS, which is what MDK/whitenoise use, so
Amethyst passing on both is a strong signal that the on-wire MLS layer
is spec-correct rather than coincidentally self-consistent.
Add a Node-based generator under quartz/tools/tsmls-vector-gen/ that
uses ts-mls 2.0.0-rc.10 directly to emit:
- Alice's KeyPackage + Bob's joiner KeyPackage
- Alice's Welcome after add_member + commit
- Bob's init/encryption/signature private keys (PKCS#8 Ed25519 unwrapped
to the raw 32-byte seed for parity with the MDK vector shape)
- Post-join MLS-Exporter("marmot","group-event",32) KAT
- Three application PrivateMessages from Alice → Bob with the
expected plaintexts
TsMlsWelcomeInteropTest mirrors MdkWelcomeInteropTest but consumes the
new vector. It proves:
- KeyPackage self-signature verifies under our Ed25519 + SignContent.
- Amethyst.processWelcome unwraps the group secrets, derives the
welcome_key/nonce, AEAD-decrypts GroupInfo, verifies GroupInfoTBS
with signer_pub, decodes the ratchet tree, and binds the joiner's
leaf — end-to-end.
- Post-join exporter secret matches ts-mls byte-for-byte.
- Amethyst decrypt() parses the RFC 9420 §6.3.1 PrivateMessageContent
framing (application_data<V> + FramedContentAuthData.signature<V> +
zero padding) and verifies the sender's FramedContentTBS signature
against Alice's leaf, for all three ciphertexts.
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
Two bugs that surfaced together once FramedContentTBS signing started
being checked at decrypt time:
1. Empty-proposal commits (pure forward-secrecy / self-update) were
skipping the UpdatePath entirely, so the sender's commit_secret
fell back to an all-zero vector while a spec-compliant receiver
would derive a real commit_secret from the path — diverging the
epoch key schedule on the very next message. Per RFC 9420 §12.4.1
the path value MUST be populated when the proposal list is empty.
2. When an Update proposal rotates our own signing key, commit()
rebuilds the committer leaf for the UpdatePath and signs it with
signingPrivateKey (the PRE-rotation key) before the post-commit
promotion step swaps signingPrivateKey for pendingSigningKey. The
receiver then stores our leaf with the pre-rotation signature_key,
while we start minting FramedContentTBS signatures with the new
key — every subsequent decrypt fails signature verification. Use
pendingSigningKey when present to seal the UpdatePath leaf.
Un-Ignore the two empty-commit / multi-epoch tests that documented
this divergence (one in MlsGroupLifecycleTest, one in
MlsGroupEdgeCaseTest). Both pass now, as does the existing signing-
key rotation cross-member round-trip test.
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
MlsGroup.encrypt / decrypt used to pass raw application bytes as the
AEAD plaintext — no PrivateMessageContent framing, no FramedContentTBS
signature, no padding. Amethyst ↔ Amethyst round-trips worked (both
sides skipped it the same way) but every cross-implementation message
was unreadable.
Per RFC 9420 §6.3.1 the AEAD plaintext for an application PrivateMessage
is the serialized PrivateMessageContent:
opaque application_data<V>; // varint-prefixed payload
opaque signature<V>; // FramedContentAuthData.signature
opaque padding[N]; // zero padding (N may be 0)
where the signature is `SignWithLabel(., "FramedContentTBS",
FramedContentTBS)` computed over (version || wire_format ||
FramedContent || GroupContext). This change wires both sides up
end-to-end:
* encrypt now builds FramedContentTBS via the new
buildApplicationFramedContentTbs helper, signs it with the caller's
signature private key, and writes application_data<V> || signature<V>
(zero-length padding) as the AEAD plaintext.
* decrypt parses application_data<V> and signature<V> from the AEAD
plaintext, asserts all remaining bytes are zero padding, rebuilds
FramedContentTBS for the sender's leaf, and verifies the Ed25519
signature against that leaf's signatureKey before returning the
application payload. Non-application PrivateMessages now error
(commit/proposal-inside-PrivateMessage was never correctly handled
by the old raw-bytes path either; leaving that for a follow-up).
Un-Ignore MdkWelcomeInteropTest.testBobDecryptsMdkApplicationMessagesFromAlice
— Amethyst now decrypts and verifies each of the three openmls-authored
application messages against Alice's committer leaf.
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
Add a Rust generator under quartz/tools/mdk-vector-gen that emits a
Welcome, joiner KeyPackage, committer signer_pub, joiner's three
private keys, and a post-join MLS-Exporter KAT, using the same
openmls 0.8 backend MDK / whitenoise use. Commit its output at
quartz/src/commonTest/resources/mls/mdk-welcome.json.
MdkWelcomeInteropTest consumes the vector and proves Amethyst can:
- parse a KeyPackage OpenMLS authored and verify its self-signature;
- run the joiner's processWelcome end-to-end (HPKE unwrap of group
secrets, welcome-key derivation, AEAD GroupInfo decrypt, ratchet
tree decode, signer leaf lookup, GroupInfoTBS Ed25519 verify);
- derive MLS-Exporter("marmot", "group-event", 32) byte-for-byte
identically to openmls — the exact exporter Marmot uses for the
outer ChaCha20 wrap on kind:445 events.
testBobDecryptsMdkApplicationMessagesFromAlice is @Ignored with a
detailed TODO because Amethyst's MlsGroup.encrypt/decrypt skip the
RFC 9420 §6.3.1 PrivateMessageContent framing (application_data<V> +
FramedContentAuthData + padding). Amethyst ↔ Amethyst works (both
sides omit it) but every cross-implementation PrivateMessage fails.
Tracked as a follow-up.
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
Three latent spec divergences that only surfaced once we fed the Marmot
stack with a Welcome authored by openmls 0.8 (the MLS backend under MDK
/ whitenoise):
* ratchet_tree extension type was 0x0001 (RFC 9420 §13.3 assigns 0x0001
to application_id; ratchet_tree is 0x0002). Welcomes and GroupInfos
Amethyst emitted were unreadable to any spec-compliant peer, and
Welcomes from peers couldn't be joined because the tree lookup failed.
* external_pub extension type was 0x0003 (that slot is
required_capabilities; external_pub is 0x0004). External commits would
have failed interop the same way.
* sender-data ciphertext_sample used AEAD.Nk (16 B) bytes of the
ciphertext; RFC 9420 §6.3.2 mandates KDF.Nh (32 B). Every
cross-implementation PrivateMessage would fail sender-data AEAD.
Amethyst ↔ Amethyst round-trip tests passed because both sides were
wrong the same way — the existing MlsConformanceTest hard-coded the
wrong extension IDs, so it even asserted the broken invariant.
Conformance test assertions updated to the spec-correct values.
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
Existing interop tests covered wire-format round-trips but never actually
ran ciphertext from IETF/OpenMLS/mls-rs test vectors through our crypto
code paths. That left two major spec bugs unverified by CI — the wrong
HPKE Welcome-context and the wrong "eae_prk" DHKEM label — because
both sides of every round-trip were wrong the same way.
Tighten coverage with cross-implementation KATs:
CryptoBasicsInteropTest
+ testEncryptWithLabelDecryptsIetfVector: decrypt the IETF
encrypt_with_label vector directly (kem_output + ciphertext), not
just our own round-trip output.
WelcomeInteropTest
+ testX25519Rfc7748Vectors: RFC 7748 §6.1 X25519 KATs.
+ testX25519DhMatchesJavaXdh: compare against JDK 11+ XDH on the IETF
encrypt_with_label priv/kem_output.
+ testWelcomeInitKeyMatchesPrivateKey: init_pub == publicFromPrivate
(init_priv) for every IETF welcome vector.
+ testIetfKeyPackageSelfSignatureVerifies: exercises Ed25519 +
SignContext + LeafNode TLS encoding against OpenMLS output.
+ testIetfWelcomeFullDecryptAndGroupInfoSignature: end-to-end path
through HPKE GroupSecrets decrypt → welcome_key derivation → AEAD
GroupInfo decrypt → GroupInfoTBS Ed25519 verify against signer_pub.
+ testPassiveClientWelcomeDecryptsGroupInfoAndFindsLeaf: same
end-to-end path on passive-client-welcome.json, plus ratchet-tree
leaf lookup and signer-leaf GroupInfo verify. Skips vectors with
external_psks (we don't model PSK secret derivation here) and with
no ratchet tree (delivery-service lookup).
The TreeKEM UpdatePath KAT was considered but needs the full direct
path / copath / resolution / LCA plumbing from MlsGroup.processCommit
to pick which HPKE ciphertext a given leaf should decrypt. Not worth
the duplication in a test — the "UpdatePathNode" HPKE path now has KAT
coverage indirectly via the IETF encrypt_with_label vector above
(same HPKE stack, different label).
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
RFC 9180 §4.1 specifies DHKEM derives the shared secret as:
eae_prk = LabeledExtract("", "eae_prk", dh)
shared_secret = LabeledExpand(eae_prk, "shared_secret",
kem_context, Nsecret)
Hpke.extractAndExpand was using "shared_secret" for both the Extract and
Expand labels, so every HPKE decapsulation produced a key schedule that
disagreed with every spec-compliant implementation (OpenMLS, MDK/
whitenoise, OpenSSL, BoringSSL, Java XDH). Round-trips within Amethyst
worked because both sides were wrong the same way; cross-implementation
Welcome HPKE decryption always failed with AEAD BAD_DECRYPT.
Add IETF-vector interop tests locking in the fix:
- decrypt the crypto-basics encrypt_with_label KAT end-to-end,
- decrypt GroupSecrets from a passive-client Welcome vector,
- X25519 DH matches RFC 7748 §6.1 and Java XDH on a KAT input,
- init_pub in each Welcome vector matches publicFromPrivate(init_priv).
Drop the stale comment in CryptoBasicsInteropTest that claimed the vector
decryption was impossible due to an "X25519 DH discrepancy" — the DH was
always fine; the eae_prk label was the bug.
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
RFC 9420 §12.4.3.1 specifies the HPKE context for encrypted_group_secrets
must be the encrypted_group_info field of the Welcome:
encrypted_group_secrets = EncryptWithLabel(init_key, "Welcome",
encrypted_group_info, group_secrets)
Both our buildWelcome and processWelcome were passing an empty context,
which let Amethyst↔Amethyst round-trips work, but made Welcome messages
sent by RFC-compliant implementations (MDK/OpenMLS, used by whitenoise)
fail with BAD_DECRYPT inside the HPKE AEAD open.
https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr
Private emojis stored in the encrypted .content of kind 30030 EmojiPackEvents
were honest about being private but useless: they never appeared in the `:`
autocomplete or the reaction menu, even for the pack owner. This wires up
async decryption so pack owners actually see their private emojis everywhere
public ones already show.
- quartz: add EmojiPackEvent.publicEmojis() / privateEmojis(signer) /
allEmojis(signer) helpers, mirroring BookmarkListEvent's public/private
accessor split. privateEmojis() returns null for non-author signers, which
preserves the rule that foreign packs cannot expose private entries.
- commons: EmojiPackState.mergePack becomes suspend (mergePackWithPrivate)
and decrypts inside the existing combineTransform hot path; the StateFlow
consumers (account.emoji.myEmojis → EmojiSuggestionState) get private
entries automatically once decryption resolves. The combiner already runs
on Dispatchers.IO so the suspending decrypt does not block the UI.
- amethyst: RenderEmojiPack uses produceState to seed with the public list
immediately and replace with the merged list once allEmojis(signer)
resolves — keeps the reaction-menu gallery responsive.
- AddEmojiDialog explainer + KDoc no longer claim private emojis are
invisible; OwnedEmojiPacksState.toOwnedEmojiPack uses the new accessors.
- Test EmojiPackEventTest covers public/private/all access including the
foreign-signer case.
https://claude.ai/code/session_01SNG3nj8ZZDChggTsg1qznn
Two kinds of noisy warnings appear every time an invitee or a
restarted client catches up with events still sitting on the relays.
Both are actually expected, per-spec behavior — not errors.
(a) Outer ChaCha20-Poly1305 decrypt fails with "current and N
retained epoch key(s)".
A newly-joined member processes the three kind:445s that
advanced the group to their current epoch (add-me-commit plus
any earlier commits). The commits were outer-encrypted with
keys that predate their Welcome, so they never held them — this
is MLS forward secrecy working as intended. No state on the
receiver's side actually needs to update: they're already at
the post-Welcome epoch.
(b) "NO matching KeyPackageBundle for eventId=…" after app restart.
The gift-wrapped Welcome (kind:1059) is still on the relay and
gets redelivered on every subscription refresh. The client's
`processedEventIds` dedup set is in-memory, so after a restart
the Welcome flows all the way to `processWelcome`, which then
fails to find the KeyPackage bundle because it was consumed and
marked during the first processing.
Both of these fire every time a member opens the app, so the logs
currently look like something is broken even when everything is
behaving correctly.
Fix:
- Add `GroupEventResult.UndecryptableOuterLayer(groupId,
retainedEpochCount)`. `MarmotInboundProcessor.processGroupEvent`
and `applyCommit` now call the new `tryDecryptOuterLayer` (which
returns `ByteArray?` instead of throwing) and surface this
variant when every available key fails. `GroupEventHandler.add`
logs it at DEBUG with a one-liner noting "likely from before our
join".
- Add `WelcomeResult.AlreadyJoined(nostrGroupId)`. When
`MarmotInboundProcessor.processWelcome` is called with a
`hintNostrGroupId` we're already a member of, short-circuit
before the KeyPackageBundle lookup and return `AlreadyJoined`.
`processMarmotWelcomeFlow` logs at DEBUG.
- `MarmotManager.processGroupEvent` treats `UndecryptableOuterLayer`
as a no-op for subscription-timestamp updates (same as
Duplicate/Error/CommitPending), so a unreadable past-epoch event
doesn't move the group's `since` forward.
No behavioral changes beyond logging level and the short-circuit of
a Welcome we already processed (which was throwing and returning
Error before). Existing callers that only care about successful
`Joined` / successful `CommitProcessed` / `ApplicationMessage`
branches are unaffected — the two new variants join the
`Duplicate` / `CommitPending` / `Error` quiet side of the sealed
class.
https://claude.ai/code/session_014zfdNeeKAfU1zGGyFw4bUL
After a group creator restarts the app, their own relay-echoed
kind:445 commit events (add-member, updateGroupExtensions, etc.) stop
being filtered by `inboundProcessor.processedEventIds` — that
in-memory dedup set doesn't survive process death. The echo then:
1. Outer-decrypts via a retained epoch key (we still hold those).
2. Gets parsed as a `PublicMessage` with `contentType = COMMIT`.
3. Flows into `applyCommit` → `groupManager.processCommit` →
`group.processCommit`.
`MlsGroup.processCommit` is not atomic: it runs proposal application,
transcript-hash recomputation, epoch advance, key-schedule derivation,
and SecretTree rebuild **in place** before reaching the final
confirmation-tag check. If that check fails — which it always does
for an already-applied commit, because the tag was computed against
the original epoch's confirmation key and we're now several epochs
past — the exception fires after the mutations, leaving the group
context at a bogus "epoch + 1" with a completely new exporter
secret.
Net result on the wire: the creator's next outbound kind:445 is
encrypted with this rogue exporter secret. Every other member is at
the real epoch, so they all log "Outer decryption failed with current
and N retained epoch key(s)" and no one receives the message. The
creator's own self-echo still decrypts because his sentKeys /
self-state are internally consistent; only external observers are
cut off.
Fix: in `MarmotInboundProcessor.applyCommit`, after parsing the
PublicMessage header but **before** calling `processCommit`, compare
`pubMsg.epoch` with the current local `group.epoch`.
- `pubMsg.epoch < current` → commit is from the past (either our own
already-applied echo or a stale relay replay). Return
`GroupEventResult.Duplicate` and don't touch local state.
- `pubMsg.epoch > current` → we're behind; the inbound pipeline
upstream needs to feed us the intervening commits in order. Return
an error describing the gap without touching local state.
- Otherwise → proceed to `processCommit` as before.
Making `processCommit` itself atomic would be nicer, but is a much
larger refactor touching tree mutations, key-schedule state, and
per-sender ratchets. The epoch check catches the production scenario
at the right boundary — we never call into `processCommit` with
bytes that we know won't apply cleanly.
Regression test:
- `testCreatorDoesNotDoubleApplyOwnCommitAfterRestart`: David creates
a group, adds Eden and Fred, persists. Simulates David's app
restart by rebuilding the `MlsGroupManager` from the store. Then
feeds David's own add-Eden commit back through the inbound
pipeline — exactly what a relay echo would deliver. Asserts the
result is `Duplicate`, and that David's epoch and exporter secret
are unchanged afterwards. Before the fix, his epoch advances by
one and his exporter secret drifts, which is exactly what the
production logs showed.
- `testCreatorCanSendMessageAfterRestart`: save/restore round-trip
sanity check that the restored manager's exporter secret matches
what the members still at the same epoch hold, and that the first
post-restart message from the creator is decryptable by an
un-restarted member.
https://claude.ai/code/session_014zfdNeeKAfU1zGGyFw4bUL
Fred (third member of a three-member group, `leafIndex = 2`) crashed
with `StackOverflowError` on ART / NPE on JVM the moment he tried to
send his first application message. The recursion / null is in
`SecretTree.getNodeSecret`, which assumes `nodeIndex` is always a
direct child of `BinaryTree.parent(nodeIndex)`:
val parentIdx = BinaryTree.parent(nodeIndex, BinaryTree.nodeCount(leafCount))
val parentSecret = getNodeSecret(parentIdx)
val leftIdx = BinaryTree.left(parentIdx)
val rightIdx = BinaryTree.right(parentIdx)
treeSecrets[leftIdx] = leftSecret
treeSecrets[rightIdx] = rightSecret
return treeSecrets[nodeIndex]!!
That invariant holds only for power-of-two trees. For Fred (leafCount
= 3, nodeCount = 5), `BinaryTree.parent(4, 5)` walks via
`parentInRange(5, 5)` and returns **3** (the root) — skipping the
virtual intermediate node 5 that would normally sit between node 4
and the root in a 4-leaf tree. But `left(3) = 1` and `right(3) = 5`;
neither is 4. The cache fills entries 1 and 5 from the root's secret,
node 4's entry is never populated, and the final
`treeSecrets[nodeIndex]!!` throws NPE. On Android the error path
instead re-enters `getNodeSecret` until the stack is exhausted.
The fix walks **down** from the root to the target leaf, picking
left or right at each step based on `targetNode < currentNode`
(holds in left-balanced MLS trees) and using `BinaryTree.left` /
`BinaryTree.right` which correctly descend through virtual
intermediate nodes. The node-level cache is no longer needed —
`getOrInitSender` caches the per-sender ratchet state once, so
re-deriving the leaf secret each time a new sender is initialized
costs a handful of HKDF calls at worst.
Side effects (all in the right direction):
- Re-enabled 6 previously `@Ignore`d tests in
`MlsGroupLifecycleTest` and `MlsGroupEdgeCaseTest` that exercised
exactly the three-member / non-full-tree path this fix addresses:
`testThreeMemberGroup_SequentialAdditions`,
`testExternalJoin_ZaraJoinsViaGroupInfo`,
`testExternalJoin_ExporterSecretsAgree`,
`testSigningKeyRotation_EpochAdvances`,
`testEncryptDecryptAfterSigningKeyRotation`,
`testPskProposal_EpochAdvancesWithPsk`. They now pass.
- `testEmptyCommit_AdvancesEpoch` and
`testMultipleEpochTransitions_EncryptDecryptStillWorks` remain
`@Ignore`d — they hit a **different** pre-existing bug where
Alice's and Bob's exporter secrets diverge after a no-proposal
commit (commit with only an UpdatePath). Unrelated to the
non-full-tree fix; tracked separately. I retagged them with an
explanatory note instead of the old "see
testThreeMemberGroup_SequentialAdditions" reference.
- Fixed an unrelated typo in
`testMultipleEpochTransitions_EncryptDecryptStillWorks` that
asserted `7L` and then `6L` for the same epoch value.
Regression test:
- `testFredEncryptsAfterJoiningThreeMemberGroup` creates a
three-member group via the production path (Alice adds Bob, then
adds Fred; Bob processes the add-Fred commit), then has Fred
encrypt an application message and asserts both Alice and Bob can
decrypt it. Without the fix this throws NPE / stack-overflows at
`encrypt()`.
https://claude.ai/code/session_014zfdNeeKAfU1zGGyFw4bUL
The snapshot/restore machinery added in the previous commit
(ca988b7) to implement MDK-style `stageCommit` + `mergeStagedCommit`
introduced a tree-rebuild path (RatchetTree.decodeTls followed by a
fresh SecretTree construction) that, in production, caused a
recursive StackOverflowError in `SecretTree.getNodeSecret` during
encryption after a second add-member cycle. The unit test flow did
not exercise it and couldn't reproduce.
Keep the underlying fix — outer-encrypt outbound kind:445 commits
with the PRE-commit (epoch-N) exporter secret — but deliver it with
far less machinery:
- `CommitResult.preCommitExporterSecret` now carries the
`MLS-Exporter("marmot", "group-event", 32)` value captured inside
`MlsGroup.commit()` BEFORE any state mutation. It's the key
existing members still at epoch N hold, so the outer kind:445
wrap with it is decryptable to them (RFC 9420 §12.4 + MDK parity).
- `MlsGroup.commit()` captures this exporter once at the top of the
function, threads it into the returned `CommitResult`.
- `MarmotManager.addMember / removeMember / updateGroupMetadata`
read `commitResult.preCommitExporterSecret` and pass it to
`MarmotOutboundProcessor.buildCommitEvent(..., exporterKey=...)`.
The eager `group.addMember` / etc. continue to advance the local
epoch immediately — the same behavior as before the previous
commit, which was proven safe under production load.
Removed:
- `MlsGroup.stageCommit` / `mergeStagedCommit` / `stageAddMember` /
`stageRemoveMember` and their snapshot/restore helpers.
- `MlsGroupSnapshot` / `StagedCommit` types.
- `MlsGroupManager.stageAddMember` / `stageRemoveMember` /
`stageRotateSigningKey` / `stageUpdateGroupExtensions` /
`mergeStagedCommit`.
- `tree` back to `val` in `MlsGroup`.
Kept from the previous commit:
- `MarmotOutboundProcessor.buildCommitEvent(... exporterKey: ByteArray?)`
with default falling back to `groupManager.exporterSecret(...)`.
- `MlsGroupManager.processCommit` retains epoch secrets AFTER
successful apply (was a secondary bug polluting the retention
window with duplicates of the current key when a commit failed).
- `pushRetainedEpoch` helper that accepts a pre-captured
RetainedEpochSecrets, used throughout instead of the old
`retainEpochSecrets(nostrGroupId, group)`.
Test updated:
- `testCreatorCanAddTwoMembersAndAllDecryptFollowingMessage` now
uses the eager `addMember` path and asserts that the member still
at the old epoch can outer-decrypt with the pre-commit key shipped
back via `CommitResult`. Also decrypts Alice's self-echo and
sends multiple follow-up messages — this is the scenario that
triggered the production stack overflow before the revert.
- `testAddMemberExposesPreCommitExporterSecret` (renamed) confirms
`CommitResult.preCommitExporterSecret` equals the exporter the
group had immediately before the call, and that the post-commit
exporter differs from it (proves we actually rotated).
https://claude.ai/code/session_014zfdNeeKAfU1zGGyFw4bUL
Per RFC 9420 §12.4 and the MDK reference implementation, a kind:445
Commit MUST be outer-encrypted with the epoch-N exporter secret — the
key existing members still hold — so that they can decrypt, process the
commit, and advance to N+1. Amethyst was instead encrypting with the
epoch-(N+1) key because MlsGroupManager.addMember / removeMember /
updateGroupExtensions applied the commit locally *before* handing the
bytes to MarmotOutboundProcessor.buildCommitEvent, which read the
current (post-commit) exporter via groupManager.exporterSecret.
Observed in a 3-party Amethyst-to-Amethyst test (David creates group,
adds Eden then Fred, sends "Hi"): Eden joined at epoch 1 via Welcome,
then "succeeded" in outer-decrypting the add-Eden kind:445 with her
own post-commit key but failed to apply ("Duplicate encryption key:
leaf 1") because she was already in the tree from the Welcome. Eden
never advanced past epoch 1, so Fred's subsequent join and David's
application message were undecryptable. Fred, joining directly at
epoch 2, saw the Hi message fine — matching the symptom where the
last-added member is the only one who can read new messages.
Fix splits commit creation from commit application on the outbound
path, mirroring OpenMLS / MDK's `create_commit` + `merge_pending_commit`
pair:
- MlsGroup gains stageCommit() / mergeStagedCommit(). stageCommit
captures a full snapshot, runs the existing commit logic (which
mutates in place), captures the post-commit snapshot, then restores
the pre-commit snapshot so the caller observes epoch N until merge.
The returned StagedCommit carries the pre-commit exporter secret
and the framed commit bytes. stageAddMember / stageRemoveMember
are thin wrappers that propose + stage.
- MlsGroupManager exposes stageAddMember, stageRemoveMember,
stageRotateSigningKey, stageUpdateGroupExtensions, and
mergeStagedCommit. The eager addMember/removeMember/commit/etc.
entry points are retained (documented as test-only) so the MLS
unit tests in MlsGroupTest, MlsGroupLifecycleTest, etc. keep
working unchanged.
- MarmotOutboundProcessor.buildCommitEvent takes an optional
exporterKey override; callers pass StagedCommit.preCommitExporterSecret.
- MarmotManager.addMember / removeMember / updateGroupMetadata now
stage → build kind:445 → markEventProcessed → mergeStagedCommit.
- MlsGroupManager.processCommit was also retaining epoch secrets
*before* calling group.processCommit, so a failed commit (such as
the add-me relay echo that the new member can't apply) polluted
the retained window with a duplicate of the current epoch key.
Now retain only on success.
Regression tests:
- testStagedAddMemberUsesPreCommitExporter: asserts stage does not
advance the epoch and that preCommitExporterSecret equals the
pre-stage exporter output.
- testCreatorCanAddTwoMembersAndAllDecryptFollowingMessage: end-to-end
David/Eden/Fred reproduction — creator adds two members in sequence
and publishes an application message; both members must decrypt it.
Fails without the fix, passes with it.
https://claude.ai/code/session_014zfdNeeKAfU1zGGyFw4bUL
- Extract a shared StreamSystemCard composable for the rounded accent
container used by zap, raid, and clip cards so they share one visual
language.
- Unify clip caption rendering through CrossfadeToDisplayComment so
captions get the same NIP-19 / emoji treatment as zap and raid
messages.
- Iterate every `a` tag when routing zap receipts into live-activity
channels so a receipt referencing multiple simulcasted streams lands
in each of them, and fold the host match into the same pass.
- Bucket anonymous and private zaps under a single sentinel key in the
Top Zappers aggregator so an "Anonymous" chip shows once with the
combined total instead of one chip per one-time pubkey.
- Add commonTest coverage for LiveActivitiesRaidEvent marker parsing,
LiveActivitiesClipEvent tag parsing, and LiveActivitiesEvent.goalEventId().
https://claude.ai/code/session_01WJA5PvDABegBYUu6h42YZi
Add a goalEventId() accessor on LiveActivitiesEvent that reads the
zap.stream `["goal", "<hex>"]` tag. When a stream channel's 30311 event
references a goal, fetch the kind 9041 event and its zap receipts
(#e=<goalId>) so the existing goal-progress aggregation works.
Render a compact LiveStreamGoalHeader above the chat feed showing the
goal title, the existing GoalProgressBar, and a one-tap ZapReaction
that targets the goal event so viewers can contribute directly to the
fundraiser without leaving the stream.
https://claude.ai/code/session_01WJA5PvDABegBYUu6h42YZi
Add a Quartz LiveActivitiesClipEvent for zap.stream's kind 1313 clip
convention, parsing the `a` tag (stream address), `p` tag (host), `r`
tag (video URL), and `title` tag. Register it in EventFactory, subscribe
in the live-activity chat filter, and route clips into the source
LiveActivitiesChannel cache. Render clips as an accent-colored card
showing "X created a clip" with the title and an inline video player
for the clip's playable URL.
https://claude.ai/code/session_01WJA5PvDABegBYUu6h42YZi
Add a Quartz LiveActivitiesRaidEvent for zap.stream's kind 1312 raid
convention with root/mention a-tag markers. Wire it into the event
factory, subscribe to it in the live-activity chat filter, and route
received raids into both source and target LiveActivitiesChannel caches
so viewers on either side see the notification. Render raids as an
accent-colored pill showing "X is raiding Y" that navigates to the
target stream when tapped.
https://claude.ai/code/session_01WJA5PvDABegBYUu6h42YZi
addMember/removeMember/updateGroupMetadata were publishing the raw TLS
Commit struct inside the kind:445 outer ChaCha20 layer, so receivers
that started with MlsMessage.decodeTls read the first two bytes of the
Commit as the MLS protocol version and aborted with "Unsupported MLS
version: <garbage>" (e.g. 16704 = 0x4140).
Wrap commits produced by MlsGroup.commit in a PublicMessage carrying
the sender leaf index and confirmation_tag, then in an MlsMessage
envelope, and expose those bytes via CommitResult.framedCommitBytes so
MarmotManager uses them instead of the raw commit bytes. The internal
CommitResult.commitBytes field stays raw so MlsGroup.processCommit and
existing tests that exercise it directly keep working.
Also mark the committer's own published kind:445 as already processed
in MarmotInboundProcessor so that the relay echo of our own commit is
treated as a duplicate rather than re-applied on top of the already-
advanced local epoch.
https://claude.ai/code/session_01NR6JgYRimVb142T2nkChuh
Follow-up to the earlier MIP-spec alignment commit, addressing the
remaining audit items:
- MIP-00 (KeyPackageUtils.isValid): now performs every strict tag-level
check that MDK does — d tag is exactly 64 hex chars, mls_protocol_version
is exactly "1.0", mls_ciphersuite is exactly "0x0001", mls_extensions
contains both 0xf2ee + 0x000a, mls_proposals contains 0x000a, encoding
is "base64", content non-empty, i tag present. Adds
`isCryptographicallyValid` for deep checks: i tag matches the computed
KeyPackageRef (RFC 9420 §5.2), Basic credential identity equals the
event's pubkey, KeyPackage signature verifies.
- MIP-01 (MarmotGroupData): encoder now omits the v3-only
`disappearing_message_secs` field when version < 3, so v2 output
matches MDK's `tls_codec` 0.4 byte-for-byte. Adds byte-level fixture
tests pinned to the Rust reference (encode + decode in both directions).
- MIP-02 (WelcomeGiftWrap): replaces the redundant sign-then-rumorize
step with `RumorAssembler.assembleRumor`, producing a true unsigned
rumor as NIP-59 requires (no wasted secp256k1 signature).
- MIP-05 kind 449 (TokenRemovalEvent.build): no longer accepts a tag
initializer. Per the MIP-05 spec the token-removal event MUST have
empty tags; allowing arbitrary caller-supplied tags risks metadata
leakage and rejection by strict validators (e.g. the MDK reference).
- RFC 9420 §6 PublicMessage framing: encoder/decoder now branch on
`contentType`. Application messages keep the `opaque<V>` length prefix;
Proposal/Commit bodies are emitted/parsed as their typed structs (no
outer length prefix), per the MLS RFC. Previously encoder used
`putBytes` raw and decoder used `readOpaqueVarInt`, so neither could
roundtrip and Proposal/Commit PublicMessages from other MLS clients
would mis-parse.
- KeyPackageUtilsTest fixtures: switch tiny "0"/"1"/"lr" slot ids to
realistic 64-char hex slot ids, since `isValid` now enforces the
MIP-00 d-tag format.
The build DSL was typed as TagArrayBuilder<GitRepositoryEvent>, which made
signer.sign(template) return the wrong event subclass. Retype it to
EmojiPackEvent and add local TagArrayBuilder extensions for title,
description, and image tags. Also add title()/description()/image()
accessors on EmojiPackEvent to match the LabeledBookmarkListEvent pattern.
Quartz (NIP-72 compliance)
- Fix CommunityDefinition image() builder to use the NIP-72 ImageTag
(was wrongly pointing at the NIP-23 ImageTag, which prevented the
builder from attaching `<W>x<H>` dimensions).
- Fix CommunityPostApproval notifyAuthor() to emit a `p` tag for the
post author as required by NIP-72 (was duplicating the `e` tag).
- Add RelayTag.MARKER_AUTHOR/REQUESTS/APPROVALS constants.
Amethyst - Communities screen
- New top-level Communities screen with FeedFilterSpinner TopNav that
supports the Mine option (filters to communities authored by the
logged-in user).
- New Route.Communities + drawer entry.
- New CommunitiesFeedFilter (subclass of DiscoverCommunityFeedFilter
using defaultCommunitiesFollowList + Mine handling).
- New CommunitiesListFilterAssembler/SubAssembler with dedicated
filterCommunitiesMine relay query.
- Account.liveCommunitiesFollowLists + settings.defaultCommunitiesFollowList.
- TopNavFilterState.communityRoutes (includes Mine).
Amethyst - Create Community
- Route.NewCommunity + FAB on the Communities screen.
- NewCommunityModel + Material3 form: name, description, image URL,
rules, moderator pubkeys, relay requests/approvals URLs.
- Signs a kind 34550 CommunityDefinitionEvent and auto-follows it so
it appears under "Mine".
- Account.sendCommunityDefinition helper.
Misc
- Extracted parseTopFilterOrDefault helper in LocalPreferences to keep
the existing inner load method under the JVM method-size limit.
Brings Amethyst's Marmot code into wire-level interoperability with the
reference MDK (Rust) implementation by resolving four spec violations and
tightening the epoch lookback window:
- MIP-01 (NostrGroupData extension): switch to QUIC-style VarInt length
prefixes (RFC 9000 §16) instead of fixed uint16. MIP-01 mandates this
encoding (the one produced by the Rust `tls_codec` crate v0.4+), so
Amethyst's previous uint16 framing could not round-trip with any MDK
peer. admin_pubkeys, relays (outer + each inner), name, description,
image_*, and disappearing_message_secs now all use VarInt prefixes.
- MIP-01: enforce "admin_pubkeys MUST NOT contain duplicates" in the
MarmotGroupData constructor.
- MIP-05 (Push Notifications): token plaintext padded size was 220 (→ 280
encrypted); spec MUSTs are exactly 1024 bytes plaintext (1084 encrypted).
A server expecting MIP-05 tokens would reject Amethyst's frames outright.
- MIP-05: HKDF IKM was sha256(shared_point); spec requires the raw 32-byte
ECDH x-coordinate. The extra sha256 produced a different PRK, so token
ciphertext authenticated only within Amethyst. Removed the hash; ECDH
already returns the x-only compact form via pubKeyTweakMulCompact.
- MIP-03: bump EPOCH_RETENTION_WINDOW from 2 to 5 to match MDK's
DEFAULT_EPOCH_LOOKBACK, so late-arriving GroupEvents whose ChaCha20
outer key was derived from a prior epoch's exporter secret can still
be decrypted after a Commit advances the group.
Hand-crafted MarmotGroupData test blobs were updated to emit VarInt
length prefixes.
Makes the API safer: callers can't accidentally pass an unparsed or
malformed identifier. EmojiUrlTag.emojiSet is now Address?, serialized
via toValue() and parsed via Address.parse() (which rejects anything
that isn't a well-formed kind:pubkey:dTag).
The "h" tag is optional in MIP-02 Welcome events — senders like
whitenoise-rs omit it. Instead of failing when the h-tag is absent,
derive nostrGroupId from the NostrGroupData extension embedded in the
Welcome's GroupContext (the authoritative MLS source). An h-tag hint,
if present, is still validated against the MLS-derived value.
Per NIP-30 the emoji tag is ["emoji", <shortcode>, <url>, <emoji-set-address>]
with the fourth field optional. EmojiUrlTag only exposed the first three.
Adds emojiSet as an optional field, preserves existing positional callers
via default null, and introduces isValidShortcode() so callers can validate
user input against the spec (alphanumeric, hyphens, underscores).
Adds a parallel ThumbHash placeholder everywhere BlurHash is already used.
Remote events now carry both hashes; renderers prefer thumbhash when
available and fall back to blurhash. The MIP-04 `thumbhash` imeta field
that was previously reserved-but-unused is now wired end-to-end.
- New ThumbHash encoder/decoder in commons/commonMain (no new Gradle dep)
- New ThumbhashTag and thumbhash accessors/builders across NIP-17, 68,
71, 94, 95, 99, the experimental profile gallery, and MIP-04
- RichTextParser + MediaContentModels carry a thumbhash field alongside
blurhash so every downstream composable can pick its preferred placeholder
- New ThumbHashFetcher (Android + Desktop) registered with Coil, plus a
small placeholderModel(thumbhash, blurhash) helper centralising the
"prefer thumbhash, fall back to blurhash" rule
- Rename BlurhashMetadataCalculator -> PreviewMetadataCalculator; the
calculator decodes the bitmap / video thumbnail once and runs both
encoders on the same pixels to keep upload cost flat
- DesktopMediaMetadata, MediaUploadResult, and FileHeader now surface
both hashes through the NIP-96, Blossom, NIP-95, MIP-04, NIP-17 DM,
Classifieds, picture, video, and long-form upload paths
- Round-trip unit test for the ThumbHash port
The list event only stores content-discovery feeds (kind-5300 DVMs),
not every DVM, so the old name was misleading. Rename the wire-level
type to reflect what's actually in it.
- Quartz: package nip51Lists.favoriteDvmList -> favoriteAlgoFeedsList;
class FavoriteDvmListEvent -> FavoriteAlgoFeedsListEvent.
- DSL helpers renamed: favoriteDvm/favoriteDvms builder extensions ->
favoriteAlgoFeed/favoriteAlgoFeeds; TagArray.favoriteDvmList/Set ->
favoriteAlgoFeedsList/Set.
- create/add/remove parameter names dvm -> feed, publicDvms/privateDvms
-> publicFeeds/privateFeeds; public/private accessors
publicFavoriteDvms/privateFavoriteDvms -> publicFavoriteAlgoFeeds/
privateFavoriteAlgoFeeds. ALT string updated.
- EventFactory + LocalCache dispatch branches + AccountSettings backup
field type + FavoriteDvmListState + FavoriteDvmListDecryptionCache all
import the new type. Internal amethyst-side classes
(FavoriteDvmListState, FavoriteDvmListDecryptionCache), the top-nav
filter classes (FavoriteDvm*, AllFavoriteDvms*) and the orchestrator
keep their names — they still deal with content-discovery DVMs
specifically, and the narrower rename here is scoped to the Nostr
wire format the user was asking about.
- Quartz test renamed + rewired. Build + tests green on both modules.
Three fixes to the Profile-badges flow:
1. TagArrayBuilder groups tags by name, so calling acceptedBadges() on
the builder scrambled [a1, e1, a2, e2] into [a1, a2, e1, e2] when
serializing. AcceptedBadge.parseAll expects adjacent (a, e) pairs,
so only one mangled badge survived, making each Accept toggle
appear to replace the previous one. Rewrite the build() of both
ProfileBadgesEvent (kind 10008) and AcceptedBadgeSetEvent (kind
30008) to collect the prefix tags (d / alt / initializer) via the
builder, then append AcceptedBadge.assemble(...) verbatim to keep
the pair order intact.
2. Rows in ProfileBadgesScreen were not clickable. Thread nav through
AwardRow / StaticAwardRow and wrap the row body in Modifier.clickable
that routes to the badge definition's thread. The Switch keeps
consuming its own clicks, so toggling still works.
3. Sort accepted badges to the top of the list, then the rest by
createdAt desc, so the user can see at a glance which badges are
currently shown on the profile.
Claude