Users can now pick any subset of drawer items, in any order, to appear
in the bottom bar. If zero items are selected the bottom bar is hidden.
- NavBarItem enum + NavBarCatalog: every drawer destination gets an id,
label, icon, and route resolver so items can be looked up by id.
- UiSettings gains bottomBarItems: List<NavBarItem>; persisted in the
existing UiSharedPreferences DataStore as a comma-separated enum list.
- AppBottomBar reads the list from UiSettingsFlow and renders a zero-
height spacer (preserving nav-bar insets) when the list is empty.
- New Navigate section at the top of the drawer exposes Home, Messages,
Media, Discovery, Notifications as drawer destinations.
- New BottomBarSettingsScreen under All Settings lets users pin/unpin
entries and drag to reorder (same UX as ReactionsSettingsScreen).
Introduces a dedicated "Live Streams" screen that mirrors the Shorts
architecture (FeedContentState + FilterAssembler + SubAssembler) and
reuses the Discovery/LiveStreams rendering (ChannelCardCompose) and
relay filter builders (makeLiveActivitiesFilter) for the same top-nav
filters available on Shorts: Following, Global, Hashtag, Location,
Authors, Community, etc.
Refactors LocalPreferences.innerLoadCurrentAccountFromEncryptedStorage
to extract follow-list pref reads into a small helper so the method
stays under the JVM 65KB method size limit after adding the new
defaultLiveStreamsFollowList setting.
Introduces a dedicated Public Chats screen accessible from the left drawer,
mirroring the architecture of the Shorts screen. It reuses the existing
Discover public-chats renderer (ChannelCardCompose + RenderPublicChatChannelThumb)
and its relay-filter helpers (makePublicChatsFilter), but with its own feed
content state, filter assembler/sub-assembler, and top-nav follow-list filter
setting so the selection is independent from Discover.
- New Route.PublicChats, drawer entry, screen/top-bar/feed composables
- PublicChatsFeedFilter scans LocalCache.publicChatChannels
- defaultPublicChatsFollowList persisted in AccountSettings / LocalPreferences
- Live per-relay follow list flow on Account for relay subscription
Introduces a standalone Follow Packs screen (Route.FollowPacks)
accessible from the drawer, rendering FollowListEvent (kind 39089)
entries from LocalCache with the same top-nav filter as Shorts and
the Discovery tab. Reuses the existing defaultDiscoveryFollowList
setting and DiscoverFollowSetsFeedFilter logic so the two surfaces
stay in sync. Item rendering goes through ChannelCardCompose pinned
to FollowListEvent.KIND, matching the Discovery follow-packs tab.
Move topic chips below the author meta row and shrink them
(10sp gray text on a subtle fill, no border, tighter padding)
so the title, summary, and author are the primary focus.
CollapsibleSectionPreview shows two sections with representative rows so
header styling, expand state, and chevron alignment can be verified
against light/dark themes. ListContentPreview wires mockAccountViewModel
and EmptyNav to render the whole reorganized drawer body.
CollapsibleSection was re-allocating a Modifier chain, uppercasing the
title String, and formatting an accessibility label on every
recomposition. Move the static padding/fillMaxWidth into
DrawerSectionHeaderModifier in Shape.kt, use the section title as-is,
and rely on the chevron's contentDescription instead of a per-frame
onClickLabel format call.
Separates personal lists (profile, bookmarks, my emoji packs, drafts,
wallet, etc.) from discovery feeds (pictures, videos, emoji packs feed,
communities, etc.) so the two uses of an emoji icon and the general mix
of ownership vs. browsing are no longer visually merged into one flat
list.
Each section is collapsible via a chevron header but expanded by default
for quick access.
Three debug-level log lines for verifying the HLS caching and
resolution-policy plumbing on a real device. Easy to revert as a single
commit before merging if the noise is unwanted.
- VideoCache: one line at app start with computed size, available, total disk
- CustomMediaSourceFactory: one line per MediaSource creation, CACHE or BYPASS
- InitialVideoQualitySelector: one line per applied policy, with selected
resolution and the rendition list
Tail with: adb logcat -s VideoCache CustomMediaSourceFactory VideoQuality
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Live streams routed through the Live Streams tab go through ShowVideoStreaming
→ ZoomableContentView, not LiveActivity.kt. ZoomableContentView is generic
and was calling VideoView without isLiveStream=true, so live stream segments
ended up in SimpleCache. The cached HLS manifest then went stale (live
manifests roll constantly) and playback stopped after ~30 seconds.
Plumb the flag through the data model: add isLiveStream to MediaUrlVideo,
set it true when ShowVideoStreaming constructs the model, and pass it from
ZoomableContentView into VideoView. URL heuristic (.m3u8) wasn't viable —
that would also bypass cache for on-demand NIP-71 multi-rendition videos
and defeat the original feature.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
With multi-rendition HLS renditions in the tens-to-low-hundreds of MB
each, the previous 1 GB fixed budget held only ~10-20 videos and
evicted everything not currently on screen. A Nostr timeline is
append-only so LRU degenerates to FIFO here, which is actually fine —
the bottleneck was the budget, not the policy.
Mirror the image cache pattern: target 20% of currently-available disk,
clamped between a 256 MB floor (low-storage devices) and a 4 GB cap.
That typically lets the evictor keep an order of magnitude more videos
without notably affecting disk pressure on modern devices.
https://claude.ai/code/session_01W8yGieuEyMKeKY9vU9zjKH
Previously any URL containing ".m3u8" was routed through the non-caching
MediaSource factory under the assumption that HLS meant a live stream.
That was correct for kind-30311 live events but wrong for on-demand
NIP-71 videos with multi-rendition fMP4 segments: their .m4s files are
immutable and a perfect fit for SimpleCache's byte-range caching, yet
they were being re-downloaded on every scroll.
Plumb an explicit `isLiveStream` flag from the caller (LiveActivity sets
it to true; everything else keeps the default of false) down through
GetMediaItem / MediaItemData and stash it in MediaItem.mediaMetadata
extras. CustomMediaSourceFactory now reads that flag to decide whether
to use the caching or non-caching factory, falling back to the old URL
heuristic only if the flag is absent (e.g. a MediaItem built outside
the MediaItemCache path).
Also persist the flag through PiP's IntentExtras bundle and use the new
constants in MediaSessionPool for the callback URI key.
https://claude.ai/code/session_01W8yGieuEyMKeKY9vU9zjKH
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
Critical:
- EmojiPackScreen delete dialog: swap plus icon for Delete
- EmojiGrid: switch emoji AsyncImage from Crop to Fit so non-square
artwork and transparent backgrounds render correctly
- AddEmojiDialog: wrap Address.parse in runCatching; a malformed
user-entered address no longer crashes the app
- BrowseEmojiSetsSubAssembler: use the query scope, not the account
scope, for the feed-freshness collector so the subscription lives
only as long as the query
High:
- Drop descriptive kdoc from AddEmojiDialog and EmojiPackViewModel
- EmojiPackCard takes an optional author; Browse feed always shows
it, MyEmojiList shows it only for foreign packs
- EmojiPackScreen: helper line 'Long-press to remove' above the grid
so the interaction is discoverable
- AddEmojiDialog: private toggle is now a Switch (correct control
for a boolean form value) instead of a FilterChip
Medium:
- EmojiPackState: distinct, accurate error messages on the add/
remove-to-selection paths (was copy-paste)
- OwnedEmojiPacksState: import NameTag/TitleTag rather than using
fully qualified names inline
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
Claude