- Large tap-to-pick cover image at the top (Badge-style): shows an
aspect-16:9 placeholder that opens the gallery, uploads to the user's
chosen media server, and previews via ShowImageUploadGallery.
- Moderators section: lists the current user as pinned "Owner" plus
each added moderator (picture + display name + NIP-05) with a
remove icon. The add field is powered by ShowUserSuggestionList so
names, npubs and NIP-05s all search live.
- Relays section: each row uses BasicRelaySetupInfoClickableRow so
users see the full relay stats (icon, users, event counts, status)
just like the AllRelayList screen. Below each row a FilterChip group
sets the NIP-72 marker (any / author / requests / approvals).
A RelayUrlEditField at the bottom adds new relays with live search
suggestions.
- Reworked NewCommunityModel: dedicated mutableStateListOf for
moderators and relays, proper image upload via MultiOrchestrator,
CommunityRelayEntry data class, publish() now uploads then signs
kind 34550 and follows it (so the new community appears in "Mine").
- Updated strings and localized resources.
Adds a dump_daemon_diagnostics helper (relays per type, wn debug health,
relay-control-state, pending invites, wnd stderr tail) and wires it into
Test 02 and Test 04 on both sides of the poll (pre-invite baseline +
post-timeout). wait_for_invite now prints a ~10s heartbeat with the
pending-invite count and the most recent welcome/giftwrap line from wnd
stderr. On timeout the script also prompts the operator to paste the
Amethyst-side MarmotDbg logcat so both ends of the gift-wrap pipe end up
in one log file.
Adds MyEmojiListScreen under emojipacks/membershipManagement/, reachable
from the "My Emoji List" header row in ListOfEmojiPacksScreen (which
previously had a no-op click handler).
The screen enumerates every pack address referenced by the user's kind
10030 selection event and renders each with title, author name, pack
thumbnail, and a preview of its emojis. A trailing delete icon calls
account.removeEmojiPack(note) which republishes the 10030 without that
pack's `a` tag; downstream consumers (reaction menu, `:` autocomplete in
composers) refresh automatically since they share the same flow.
Tapping a row routes to Route.EmojiPackView(dTag) when the pack is
self-authored, and to Route.Note(addressTag) otherwise. EmojiPackView is
backed by OwnedEmojiPacksState, which filters to the logged-in user's
authored packs, so selected packs authored by other users must use the
generic thread viewer (which already renders kind 30030 via
RenderEmojiPack).
Reordering is intentionally deferred: it would require a new
EmojiPackSelectionEvent.reorder(...) builder in Quartz (none exists
today) and a drag affordance that doesn't conflict with tap-to-view /
tap-to-delete. The header's `openMyEmojiList` callback remains the only
nav entry point, so adding reorder later is a pure follow-up.
Adds a FilterChip toggle to AddEmojiDialog letting users choose whether a
new custom emoji is written to the public `emoji` tags or to the encrypted
`.content` (NIP-51 private tags) of their kind 30030 EmojiPackEvent.
Because the downstream consumers (`:` autocomplete via EmojiSuggestionState
and the reaction menu via RenderEmojiPack) currently read public tags only
through EmojiPackState.mergePack / EmojiPackEvent.taggedEmojis(), private
emojis are NOT surfaced end-to-end yet. Rather than silently shipping a
half-broken surface (which would also only work for self-owned packs since
foreign packs cannot be decrypted anyway), the dialog now shows an honest
explainer describing exactly what "private" means today: stored encrypted,
visible only to the pack owner in this screen.
EmojiPackScreen already rendered both lists; the grid now distinguishes
private entries with a small lock badge overlay and updates the
long-press deletion path to pass isPrivate through so removeEmoji removes
from the correct location (encrypted content vs public tags).
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.
Three-dots menu on an EmojiPackEvent now offers Add/Remove from my emoji
list (kind 10030) and navigates to EmojiPackSelection. The regular
Manage bookmarks row is hidden for emoji packs so they can't end up in
the bookmark list by mistake. Closes#2426.
Add screens under ui/screen/loggedIn/emojipacks/ mirroring the bookmarkgroups
layout:
- list/ListOfEmojiPacksScreen plus EmojiPackItem for the pack feed, with a
"My Emoji List" row at the top that surfaces kind 10030 selection count.
- list/metadata/EmojiPackMetadataScreen(+ViewModel) for create/edit form.
- display/EmojiPackScreen(+ViewModel) rendering the emoji grid, FAB to add,
long-press to delete. AddEmojiDialog validates the shortcode live against
EmojiUrlTag.isValidShortcode.
- membershipManagement/EmojiPackSelectionScreen providing a single toggle
for the user's kind 10030 selection.
New routes EmojiPacks, EmojiPackView, EmojiPackMetadataEdit, and
EmojiPackSelection wired through AppNavigation. A Manage Emoji Packs row is
added to the drawer. English-only strings added to strings.xml.
Mirrors the LabeledBookmarkListsState structure: observes all authored
EmojiPackEvents in the local cache, exposes a sorted StateFlow<List<OwnedEmojiPack>>
for the UI, and provides suspend helpers for create/update/addEmoji/removeEmoji/
deletePack. Pack deletion publishes a kind 5 deletion event. Account gains
pass-through methods so AccountViewModel.launchSigner can invoke them.
Add a unit test for the OwnedEmojiPack data class.
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.
Previously ChatroomListKnownFeedFilter dropped any group whose
newestMessage was null, so groups the user just created and groups
received via Welcome events without any activity yet never appeared
in the Messages list.
Emit a stable placeholder Note (carrying the chatroom as a gatherer)
per empty group, route it through the existing Marmot row path, and
invalidate dmKnown on MarmotGroupList.groupListChanges so newly added
or promoted groups rebuild the feed.
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.
Replaces the comma-separated relay text on the Marmot Group Info
screen with a FlowRow of 55dp relay avatars that open RelayInfo on
tap and copy the URL on long-press, matching the relay-icon pattern
used elsewhere in the app.
To surface whether each configured relay is actually carrying traffic
for the group, MarmotGroupChatroom now tracks the most recent
kind:445 event timestamp observed from each delivering relay and the
info screen renders a green dot when a relay has delivered a group
event within the last 7 days (gray otherwise).
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.
Expose the member list as MutableStateFlow<List<GroupMemberInfo>> on
MarmotGroupChatroom, populated by MarmotManager.syncMetadataTo alongside
the existing memberCount. MarmotGroupInfoScreen and RemoveMemberScreen
now observe it via collectAsStateWithLifecycle, so both remote commits
(already routed through syncMetadataTo in DecryptAndIndexProcessor) and
local mutations refresh the UI without manual re-queries.
Account.addMarmotGroupMember and removeMarmotGroupMember now call
syncMetadataTo right after the MLS state is mutated, mirroring the
pattern already used by updateMarmotGroupMetadata, so the local change
is visible immediately without waiting for the relay round-trip.
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).
Replace LaunchedEffect with LifecycleResumeEffect so the members list
(and chatroom.memberCount) is re-queried every time MarmotGroupInfoScreen
resumes, not just when nostrGroupId changes. Previously, after adding a
member via the AddMemberScreen and popping back, the members count
displayed in the header and chat top bar stayed stale until the screen
was fully recreated.
- LocalCache.consume dispatcher now handles InterestSetEvent via
consumeBaseReplaceable, so the event created by the user is stored
and flows through newEventBundles → interestSets.newNotes → listFeedFlow
refresh. Without this, the just-signed event sat in the sendMyPublicAndPrivateOutbox
call but the UI never saw the update.
- List screen: icon + centered text for the empty state and dividers
between rows.
Vitor Pamplona