feat(chat): create and join balance-gated public group chats

[bmc08gt]

Public groups gate on a balance, so a chat the user has not joined still has something to show: a title, a picture, a member count, and the rule they are short of. That makes creating and joining one screen apart from each other but one destination — which is also where a push for an unjoined group has to land.

Sections 10153:22901 (creating) and 10153:22902 (joining).

Creating

NewGroupFlowScreen hosts the draft: the currency sheet (node 10127:118100) and the custom-amount keypad edit it and return. StartChat succeeding ends the flow and drops into the conversation — the invite is offered from inside the group rather than on the way out of creating it. The shared CreateGroupViewModel is scoped to the flow rather than to a step, which is also what gives one create attempt's idempotency key a lifetime long enough to survive a retry.

The 0.8.0 semantics the form honours:

• The 16-byte idempotency key is minted when the user taps Create, not when the call is made, and the same key goes out on every retry of that attempt. A picture already uploaded for that attempt is reused rather than re-uploaded. Both are pinned by tests.
• All six StartChatResponse.Result arms are handled. TITLE_MODERATED reads its flagged_category through the app's existing moderation-category mapping.
• The creator has to satisfy the rule they are setting. GroupAccess.evaluate — the same predicate the join gate uses — decides whether Create is enabled, and RULES_NOT_SATISFIED from the server reads the same as that pre-call check. While that check fails, the caption under the requirement card says so in the error color rather than describing what the rule does to everyone else: a rule the creator is short of otherwise looks like a finished draft under a dimmed button.
• The picture is uploaded first and reaches GroupChatParameters.picture as a blob.v1.BlobId for the original. The response's chat carries the server-derived renditions, so nothing is refetched.
• Rules go out as a single listener MinimumBalanceRequirement: a fiat amount plus exactly one mint. speaker is left unset.

The heading switches from "Minimum Balance Required" to "Balance Requirement" when the creator picks the mint. Node 10127:118057 still asks, with the title typed and the form's opening mint untouched; node 10127:118194 has flipped on the changed mint with no amount yet. Because the form opens with a mint already named — the largest holding, so the creator starts on a rule they can satisfy — the heading reads a mintChosen flag set by the currency sheet rather than mint != null. Create is a capsule painted with the wallpaper accent, the same treatment the currency creator's bill step gives its Next action; below API 31 it falls back to the theme's action colors.

Joining

GetChat serves a non-member the title, picture, roster_summary and rules, so the gated preview (node 10127:117171) is built from real metadata. GroupGateBar states the group's requirement above the button in both states — node 10127:117120's eligible viewer reads the same line as a blocked one — because it is the chat's standing rule rather than this viewer's shortfall; the gate decides only whether the button joins or sends you to buy more. It reads that rule the same way the info card at the head of the transcript does, so the two lines about one group cannot disagree. The token is named rather than tickered, matching the create form and the balance list a requirement is satisfied from, and the reserve drops out of the requirement line altogether — "$100 of Dollars" says dollars twice, though Buy More still names it. That branding rule moved out of a private composable in LinkCardView into :apps:flipcash:core so one place decides it. A staff-only group is stated the same way, on the gate and on the info card, and a chat may set both rules, so both get a line. Staff-ness is UserFlags.is_staff — the field the rule is written against — rather than a bar the client treats as unsatisfiable; reading it as unsatisfiable meant a staff member who left such a group could not rejoin it. A refused join is reported: RULES_NOT_SATISFIED, DENIED and NOT_FOUND each say something different, and the button spins until the call returns, because membership arrives from the roster rather than from the join's own reply.

Roster updates arrive on event.v1.ChatUpdate.roster_updates and are convergent rather than sequenced, so they are applied by roster_summary.version — greater applies, lesser-or-equal drops, unreconcilable refetches. MemberJoined.metadata is set only when the joining member is the recipient, so that is what inserts the chat into your own list. The member count comes from RosterSummary.member_count.

Handing out the link

Node 10127:118315 is a wrap-content sheet on the chat flow carrying two rows, share and copy. Two things put it up: the empty transcript's CTA, and an "Invite People To Join" row on the group's profile. Both read the one url ChatViewModel builds, which is also what gates them — a DM, or a group this viewer has not joined, has no link and neither row appears.

Leaving

A second profile row, below the invite, sends LeaveChat behind a destructive confirmation. NotFound counts as success — a chat you are not in is the state the call was asking for. The row's condition is the roster's isMember, not the gate, so it goes away as the leave lands rather than when the balance rule next re-decides. A completed leave exits the chat flow to the list; closing back onto the transcript would leave the user reading a conversation from behind the gate they had just stepped outside of.

The design has no group-profile frame, so the row's placement and its confirmation follow the app's own conventions: MenuList offers no destructive style, and the red weight comes from the BottomBarManager alert.

One destination, two entry points

The invite link is https://app.flipcash.com/chat/<uuid>, built and parsed from common.v1.ChatId.value as the 16-byte UUID group chats carry. There is no invite-link RPC. Note the host: tipcard links use bare flipcash.com, and this is app.flipcash.com, which needed its own verified intent filter with a /chat/ path prefix.

A push tap for a group the user has not joined resolves to that same gated preview. ChatTapTargetPlanner makes that decision from push.v1.ChatMetadata.chat_type; the sender is read from message.sender_id rather than the deprecated sending_user_id, and hasMessage() keeps the fetch fallback for pushes that carry no message.

There is no roster push. The contract cannot deliver an "X joined your group" notification reliably, so none is built.

Two things to look at

The blurred transcript is decorative. No RPC returns a transcript to a non-member — GetChat is metadata only. The messages behind the blur in node 10127:117171 are a static placeholder layer, not a fetch. If the gate is meant to preview real content, that needs a contract change first.

The … preset has no specified destination. Nodes 10127:118014 through 10127:118237 show the chip but not what it opens; it opens a custom-amount keypad sheet that writes back to the draft.

Merge note

NotificationService.kt is also edited on the local feat/push-silent-sync-spike branch, which adds PushHandlingPlanner around the receive path. This PR only changes the chat tap-target branch of the tap handler, so the two edits are adjacent rather than competing, but whichever lands second should rebase rather than resolve by hand.