mirror of
https://github.com/block/buzz.git
synced 2026-11-02 15:31:27 +00:00
cfcaef4e9fb562ff0acd4ed749464bdd733fdfc8
247 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
klopez4212
|
cfcaef4e9f |
Update mobile toast animations (#8855)
Updates mobile toast animations and styling. | Sign in | Retry | Copied | | --- | --- | --- | |  |  |  | --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
klopez4212
|
4de1b6aeac |
Simplify mobile Solo and DM empty states (#8851)
Replace the embedded Solo onboarding block with “No chats yet.” Give Solo and DM empty states matching left alignment and spacing below their headings, with softer text at 65% opacity. Validated with mobile formatting, analysis, the full mobile test suite, and a Flutter widget preview measuring equal 16-point gaps below both headings. ### Preview Actual Flutter widgets with sample data; not a device capture.  --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Logan Johnson
|
547de61aa5 |
fix(mobile): show channel posts before a burst of join notices (#8798)
## Summary When many people join a channel at once, the mobile app could open that channel and show only a "… joined" line, with none of the channel's posts. You had to scroll up before any messages appeared. With this change, the posts always show first, and the join lines appear among them in the right places. The cause: the app loads the newest 50 timeline rows when a channel opens, and join notices counted toward those 50. A burst of 50 or more joins filled the whole first page. The app combines a run of joins into one line only when it draws the screen, so the user saw a single "Guest 10 joined … and 48 others" line. The app loads older rows only after the user scrolls. This is the mobile port of the desktop app's fix, https://github.com/block/buzz-app/pull/1983, which has already merged. It needs no relay change. - History pages no longer include join notices, so the first page is all posts. - The app reads join notices with a separate read, newest first, 500 per read. It reads down to the oldest post loaded so far, and continues after each older page loads. Like desktop, it stops after 2,000 notices. - Each notice read also reads the reactions on those notices, and any removals of those reactions. A page brings these back for its own rows, but notices are no longer on the pages, so they need their own read. These reads name the channel in `#h`, so a system channel, or an unlisted channel opened by a non-member, still returns them (NIP-CL). Deletions are also read without `#h`, because a deletion can be stored with no channel. Each read names at most 500 target ids, so it stays under the relay's 1 MiB request limit. A notice's reactions show even when they sort below the oldest loaded post. - Posts show as soon as their page loads. The notices follow and are merged into the timeline, so they do not replace rows that arrived live in the meantime. - A notice that is older than the oldest loaded post waits until its page loads. This prevents a join from showing at the top of the timeline with a gap of missing posts below it. - If a notice read fails, the posts still show. The next page load tries the notices again; if a page loaded while the read was running, the read runs once more right away. - The same applies to every system notice (joins, topic changes, channel created or archived), as they share one event kind. ### Related issue AIDA-2328. Desktop fix (merged): https://github.com/block/buzz-app/pull/1983. ### Testing Before (left, older build) and after (right, this branch) on the Android emulator, against a local relay. #general and #4things each have 4 posts followed by 60 joins: https://github.com/user-attachments/assets/53b80942-d8c3-4604-8b95-cc5ca7ab6946  - New `channel_messages_provider_test.dart` cases run against the real channel provider, with only relay responses faked: - A burst of 500+ joins does not hold posts back. If the first notice read fails, the posts still show. A later page read retries the notices and continues the descent. - Notices in the same second as the oldest loaded post follow the post's position within that second. - The descent stops at 2,000 notices. - A notice keeps its reactions, and a removed reaction stays removed. Reactions are read past the relay's 1,000-event page. The fake relay applies the NIP-CL rule, so a read without `#h` finds no channel reactions. - A page that loads while a notice read fails still gets its notices. - `just mobile-check` and the full `just mobile-test` pass at `7a38763af`. Not yet tested on a physical device, or on iOS. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Logan Johnson
|
aa5f3e7bde |
feat(mobile): show conversation activity by the composer, as buzz-app does (#8765)
## Summary Stacked on #8754. This brings the rest of buzz-app's conversation activity to mobile. buzz-app shows who is active in a conversation in one place, just above the composer (`src/features/messages/TypingIndicator.tsx`). Mobile had its own design: a typing bubble at the end of the timeline that turned into the agent's reply (the "handoff"). This change replaces that design with buzz-app's indicator in channels, DMs, Me and threads. What the indicator shows, as in buzz-app: - **On the right: your agents working here.** Up to four agent avatars, then "+N". "Your agents" are your agent inventory (kind 30177), as in #8754. Tapping the avatars opens the "Working now" list. - **On the left: everyone else typing here.** Typing dots and buzz-app's text: "Alice is typing", "Alice, Bob are typing", "Alice, Bob and 1 others are typing". - **"Working now" list.** Each row shows the agent, "Working" and, in a channel view, where it works: "Channel conversation", or "Thread · <first 60 characters of the root>", with "+N more" after two places. - If the agent works in exactly one thread, the row opens that thread. A thread whose root is not loaded opens by its ID, as buzz-app's link does. A button at the end of the row opens the agent's activity. - Otherwise (in a thread view, in Me, in the channel only, or in several threads), the row opens the agent's activity. As in buzz-app, work in the channel does not count as a thread: an agent in the channel and one thread opens that thread. - "Activity" is mobile's existing `AgentActivitySheet`. - The list closes when the last agent stops. - **Scope** (`current-activity.ts`: "Channel views include threads; thread views do not"): | View | Your agents | Everyone else | |---|---|---| | Channel or DM | Here and in any thread | Here only | | Thread | This thread only | This thread only | | Me | Anywhere | Anywhere | - **Me** works like buzz-app's Solo chat: with one agent working, tapping the avatars opens its activity directly. - **Spoken status:** buzz-app's live status, for example "Jerry, Morty, Summer are working. Alice is typing". The button says "Activity: Morty working" or "Activity: 3 agents working". Changes you will notice compared with #8754 and main: - The typing bubble at the end of the timeline and the bubble-to-reply handoff are removed. #8754's channel typing row goes with them. The root message's reply row from #8754 stays. - In DMs, other people's agents typing in a thread no longer show at the DM level. Only your agents do, as in buzz-app. This reverses part of #8731. - With no composer, there is no indicator. This applies when you are not a member or the channel is archived, as in buzz-app (`ChannelsPage`, and `ThreadPanel`'s `composerRoot`). Before, mobile showed typing in those threads. Less than buzz-app, not in this PR: - Status is always "Working". buzz-app also uses lifecycle evidence (local agent state, kind 24200) and tool labels. Mobile uses typing only, as in #8754. - No hover preview and no keyboard path (Down arrow) into the list. - The indicator sits in the composer dock, so it moves the timeline up a little. In buzz-app it floats over the history. Code: - `conversation_activity_state.dart` holds the scope rules, read from typing and the inventory. - `conversation_activity.dart` is the indicator. `working_now_sheet.dart` is the list. - `channel_detail_page/composer_activity.dart` puts it in the channel composer dock and opens threads. The thread page puts it above its composer. - Removed: `inline_agent_typing.dart`, `agent_reply_handoff.dart`, `agent_typing_bubble.dart`, `typing_avatar_cluster.dart`, `typing_motion_preview.dart`, `channel_typing_indicator.dart`, and their tests. ### Related issue N/A. Reported in Buzz #buzz-bugs (on iOS you cannot tell whether an agent is down or typing). Searched issues and PRs for duplicates: none found. ### Testing Android emulator, local relay, debug build of `8362d46af`. **Channel and thread.** Demo User mentions Morty. Morty, Summer and Jerry (in Demo User's agent inventory) type in the mention's thread. Rick (not in the inventory) types in the thread and in the channel itself. In the video: 1. The channel shows three agent avatars on the right and "Rick is typing" on the left. Rick's thread typing does not show. 2. Tapping the avatars opens "Working now". Each row reads "Working" and "Thread · …". Tapping Morty's row opens the thread. 3. In the thread, the same three agents show, with "Rick is typing" (his thread typing). Rows there open activity: tapping Morty's opens his activity sheet. 4. Back in the channel, Summer, Jerry and Rick stop. Only Morty's avatar is left. Then Morty replies and the indicator goes away. No typing bubble shows at any point. https://github.com/user-attachments/assets/b300e16e-8bec-4489-9ee4-a68c5c2dc30d **DM.** A DM with Morty (in the inventory) and Rick (not). Demo User posts. Both type in its thread, and only Morty's avatar shows. Then Rick also types in the DM itself, and "Rick is typing" shows. Morty replies, and his avatar goes away. https://github.com/user-attachments/assets/3614be5f-3a69-4a1a-9290-d1fad16a5445 The UI tree confirmed each state, for example "Summer, Jerry, Morty are working. Rick is typing", "Activity: 3 agents working", "Morty is working" (agents only), and "Morty is working. Rick is typing" (DM). - Widget tests in `channel_detail_page_test.dart` (Typing indicator group): - Scope table: Me, channel and DM, for a person and for your agent. While the inventory loads, an agent never shows as a person. - The journey from #8754, extended: the composer status and button, the list's places, opening the thread, thread-view rows opening activity, and the list closing when work stops. - Six agents in several places: four avatars and "+2", "+1 more", scrolling to the last row, opening a thread that is not loaded, and opening activity. - Me opens a lone agent's activity directly. People typing: 1, 2 and 3. - Each new check was made to fail on purpose by removing the code it guards. - `just mobile-check` and the full `just mobile-test` passed on `3480ad238` (3983 passed, 28 skipped). - Typing names use the full foreground, so they stay readable in dark themes (review feedback). A test checks the color. - Auto and Cerveau reviewed it adversarially against buzz-app origin/main. Their findings are fixed: the list did not scroll, unloaded threads did not open, the Me behaviour, the non-member indicator, and a double-tap pop. Their last pass on `2c45f3ec0` found nothing. The device run then showed that, with only agents working, the spoken status had no size and Android dropped it. `8362d46af` fixes this, and their review of that fix found nothing. - Not yet tested on iOS or by a human. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Logan Johnson
|
851250524e |
feat(mobile): show your agents working in a thread on its root message (#8754)
## Summary When you mention one of your agents in an ordinary channel on mobile, nothing in the channel showed that the agent was working until its reply landed. The agent answers in the mention's thread, so its typing (kind 20002) is thread-scoped, and the channel timeline hides thread typing. The header working dot that used to cover this was removed in #8052, #8075 and #8082. This change brings buzz-app's behaviour to mobile. In buzz-app, the thread summary under a message shows the viewer's own agents while they type in that thread (`MessageRow.tsx` `useThreadAgents`, described in `docs/agents.md`). Mobile now does the same. The root message's reply row shows the working agents' avatars and the typing dots, and the row appears even under a mention that has no replies yet. It then reads "View thread". Tapping it opens the thread. When the reply arrives and the typing ends, the dots go away and the row reads "1 reply". The details follow buzz-app: - Only your agents count. buzz-app's "your agents" (`agentChoices.identities`) are your agent inventory, which is the kind 30177 records you author with archived agents included, plus your local agents. It does not read the NIP-OA owner tag. Mobile uses the same inventory. An agent that only names you as owner in its profile does not count. People and other agents typing in a thread stay inside the thread view. - Working agents leave the participant stack for their own group: up to two agent-shaped avatars side by side, then "+N", then the dots. - The curved reply branch shows only when the message has replies. - buzz-app's channel indicator by the composer also includes your agents working in any thread ("Channel views include threads" in `current-activity.ts`). Mobile's channel-level surface is the typing row at the end of the timeline. In ordinary channels, that row now also shows your agents that are typing in a thread, with the agent avatar shape. It goes away when the agent's reply arrives. - The spoken labels use buzz-app's strings: "View thread: Morty is working", "View thread: 3 agents are working" and "View thread: 1 reply. Morty working". - Me and DMs already show thread typing inline, so they are unchanged. Code changes: - `TypingDots` is extracted from `AgentTypingBubble`, so the reply row and the bubble share one animation. It respects reduce motion. - `ReplySummaryLink` accepts a nullable summary and a list of working agents with their names. `SmallAvatar` gains an `agent` flag for the working group, and `InlineAgentTyping` a `knownAgents` set so the channel typing row gives inventory agents the agent shape. - `meAgentInventoryProvider` holds the inventory keys. It is read only while a thread in the channel has typing. Each read, failed ones included, is reused for 30 seconds, then read again if still watched, or dropped. So the inventory refreshes every 30 seconds while it is watched, and a short gap between an agent's messages does not query again. - The page selects a "pubkey root" key from channel typing, so typing expiry refreshes do not rebuild it. Less than buzz-app, not in this PR: - buzz-app prefers lifecycle evidence (local agent state and kind 24200 observer turns) and falls back to typing. Mobile uses typing only. So when an agent stops without replying, mobile keeps its dots until the typing expires (8 seconds). A second buzz-app device without that evidence behaves the same way. I found no 24200 publisher in buzz-app itself. buzz-app publishes typing (kind 20002) for the agents it runs. - The channel typing row reads "Morty is typing" where buzz-app's indicator says "working". It has no popover that names the thread and no tap action. It sits after the newest message, so it scrolls away with the timeline, while buzz-app's indicator stays by the composer. ### Related issue N/A. Reported in Buzz #buzz-bugs. Searched issues and PRs for duplicates: none found. ### Testing Android emulator, local relay, build of `3caa17a20`. Demo User mentions Morty. Morty, Summer, Jerry and Rick send thread typing: - Morty is a channel bot in Demo User's agent inventory. - Summer and Jerry are in the inventory but are ordinary members, so only the inventory gives them the agent shape. - Rick names Demo User as owner in his profile but is not in the inventory. In the video: 1. The root message shows Morty and Summer, "+1", the dots and "View thread", with no reply branch. The channel typing row reads "Morty and 2 others" with three agent avatars. Rick does not show. 2. Tapping "View thread" opens the thread before the first reply. Back to the channel. 3. Summer and Jerry stop. Their typing expires, and only Morty is left on both rows. 4. Morty replies. The typing row goes away, the reply branch shows, and the root row reads "1 reply". The UI tree confirmed "View thread: 3 agents are working", "Morty and 2 others are typing", "View thread: Morty is working", "Morty is typing" and "View thread: 1 reply". https://github.com/user-attachments/assets/2237e565-aa48-405a-84ca-39ab9a06b7a6 - The widget test "an agent working in a thread shows on its root message" (`channel_detail_page_test.dart`, Typing indicator group) covers these cases: - A person, and an agent outside the inventory that names you as owner, show no row and no channel typing row. - Inventory agents also show in the channel typing row ("Morty and 2 others are typing", checked in the semantics tree), with the agent shape. That row goes away when the reply arrives. - Three inventory agents show two avatars with the agent shape, "+1", "View thread", no branch, and "View thread: 3 agents are working". - The row opens the thread before the first reply. - After the reply, Morty shows once, the branch shows, and the label is "View thread: 1 reply. Morty working". - With Summer still typing, Morty removed from the inventory stops counting after the 30-second refresh. - Each check was made to fail on purpose by removing the code it guards. - `just mobile-check` and the full `just mobile-test` passed on `3caa17a20` (3996 passed, 28 skipped). - Auto and Cerveau reviewed it adversarially against buzz-app origin/main. Their findings are fixed, and their last pass found nothing. - Not yet tested on iOS or by a human. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
klopez4212
|
c0c606e2e3 |
Polish mobile navigation and restore community switch animation (#8732)
Removes aggregate unread dots from mobile filters, Inbox, and Solo
section headings. The aggregate-dot removal is an explicitly requested
product change. Solo and Team names match the current `block/buzz-app`
sidebar’s light/dark colours and 400/600 read/unread weights (not this
repository’s older `desktop/` implementation); Solo rows show
owned-agent working dots with reduced-motion support.
Restores the community-switch loading and avatar flight with a leftward
arc to the community menu in its current top-right position.
Mobile uses one fixed light/dark application palette; legacy catalog
theme names do not select navigation palettes. The 600 unread weight
follows [the current desktop sidebar
override](
|
||
|
klopez4212
|
aae0081a90 |
fix(mobile): show agent DM typing and balance reply bubble padding (#8731)
Messages with a reply footer now keep even vertical text padding unless they have actual overlapping reactions. Agent typing indicators are now visible in both one-to-one and group DMs when the response is thread-scoped, regardless of Bestie selection. The typing fix originated in #8665 and now applies to every agent DM using the existing agent classification. It retains main's `visibleTypingProvider` filtering. Ordinary channels and human thread-typing signals retain their existing scope; voice recording is not included. Validation: required pre-push hooks passed, including mobile formatting, analysis, tests, native crypto package tests, and file-size checks. Flutter analysis and the full mobile suite pass (3,995 passed, 28 skipped). Widget coverage compares bubble heights with and without a reply footer and checks typing across Solo, ordinary channels, agent DMs, human DMs, and group DMs with agents. Marked ready for review at the owner’s request. Device verification remains pending. To try: open a DM with any agent, including one not selected as Bestie, while it handles a thread-scoped response and check for its avatar and three dots; repeat in a group DM with an agent; compare equal text in messages with and without a reply footer, with no reactions, and confirm equal bubble heights. The broad `just ci` check was stopped during the unrelated desktop Rust dependency build after the mobile pre-push checks passed; no full-repository CI pass is claimed. ### Before / after Flutter widget-harness snapshots with identical synthetic data; not native device captures. Before: the reply-footer bubble has excess bottom padding and the thread-scoped Bestie typing signal is hidden. After: both text bubbles have equal height, and Bestie’s avatar and three dots are visible. | Before | After | | --- | --- | |  |  | --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Tom Brow
|
4b21a10c4b |
fix: don't notify workflow owners through their attribution tag (#8694)
A workflow message names its owner in a marked p tag, ["p", owner, "", "owner"], for attribution. #p live, history and push matching, operator listeners, desktop, mobile and the iOS NSE treat that tag as attribution rather than a mention. A workflow that mentions its owner adds a plain p, so the owner is notified only when actually mentioned. NOSTR.md records the #p exception. Co-authored-by: studio <dc2fc481343672df31a689840c09299972e704dac592e0da6f18486646a7ee3e@buzz.block.builderlab.xyz> Signed-off-by: Tom Brow <tomb@squareup.com> |
||
|
Tom Brow
|
050d545264 |
perf(mobile): skip unchanged message footer layout (#8433)
Rebuilding an unchanged message footer currently schedules another layout even when its overlap value is identical. Only invalidate footer layout when that value changes, preserving layout updates for actual geometry changes. ### Stable release recommendation Exclude from `mobile-release/conference-2026-10`; defer to the following release. The regression test demonstrates eliminated redundant layout, but the effect on navigation latency has not been quantified. ### Validation The added widget regression checks that unchanged footer rebuilds do not repeat layout and changed overlap still updates geometry. The independent footer build passes the full mobile suite, analysis, and native iOS Simulator build. Channel scrolling, opening an existing reaction list, and thread navigation were exercised on iOS 26.5 Simulator. The full local repository gate previously encountered an unrelated, unchanged desktop subprocess timing test failure; that test passed in isolation. All PR CI checks pass, including the native iOS suite. <!-- buzz-review-completed --> Signed-off-by: Tom Brow <tomb@block.xyz> |
||
|
Tom Brow
|
be1ac392e8 |
perf(mobile): render inbox and search previews as plain text (#8675)
### Summary Inbox rows and search results show each message as a 2-line preview. That preview was a capped `MessageContent`, so gpt_markdown parsed and laid out the whole source (syntax-highlighted code blocks and measured tables included), even though only two lines are painted. A native trace on an iPhone 12 mini attributed a 102 ms inbox-open frame mostly to this work. Previews now skip Markdown entirely. `messagePreviewSource` takes only the leading lines a preview can show, and at most the first 4,000 characters of a single long line, so link normalization, mention binding and emoji lookup never scan the rest of a long message. `messagePreviewPieces` is then a linear pass over those lines, similar to desktop's `getMarkdownPreviewText`. It drops block syntax (headings, quotes, list markers, rules, table dividers, code fences) and unwraps inline emphasis and `<u>`, honoring backslash escapes and keeping inline (including multi-backtick) and fenced code as literal text. It also replaces links with their label. The new `MessagePreview` widget renders the result as a single `Text.rich` with `maxLines` and an ellipsis. Tokens keep the look they have in the thread view: - A bound mention is the same `MessageMentionPill` chip, with the bot icon for agents. An ambiguous mention stays as text. - `#channel` tokens and `buzz://channel/...` links are the same channel token chip. - A `buzz://message`, repo, PR or issue link that shows its own URL previews with the thread view's short label, such as `general · abcdef01`. Both use the shared `buzzLinkLabel` helper. - Custom emoji render as inline images. Only shortcodes the message names are looked up in the palette. - Media links show as "Image", "Video" or "Audio". Chips in previews are not tappable, and tapping the row opens the message. Bold, italic, inline code and link styling are no longer shown in previews. The timeline and thread view are unchanged, and so is the profile status line, which still uses `MessageContent`. This replaces this PR's earlier approach of cutting the Markdown source before parsing. That approach needed delimiter-balance heuristics, and a security review found a real case (`**` inside a link label) where the heuristic misfired. ### Validation - `preview_text_test.dart` is a table test of the parser: block syntax, emphasis that must and must not unwrap (`snake_case`, a lone `*`), inline and fenced code, unpaired backticks, links, tables, the line limit and the long-line cap. It also covers mentions (bound, ambiguous, inside emphasis, link labels and code), custom emoji (including adjacent `🅰️b:`), channel tokens and links, message and repo link labels, and media. The long-line row also asserts that `messagePreviewSource` returns a bounded prefix. - `message_preview_test.dart` checks the widget: no `GptMarkdown`, one capped and ellipsized paragraph, mention chip, custom emoji image, channel chip, media label and empty content. - Existing inbox and search tests updated to find `MessagePreview`, including the agent-chip test in search. - `flutter analyze` and the full mobile test suite pass at |
||
|
Wes
|
fffd8ca957 |
fix(mobile): recover Solo sync silently instead of showing a retry banner (#8701)
## Problem The mobile Solo section could display "Live updates stopped. Your saved chats are still available." with a **Retry live updates** button. Any failed Solo head refresh raised this banner. That includes the refresh that runs on app resume before the relay has reconnected, and an 8s history timeout. In those cases the live subscription itself was still healthy. A later successful refresh did not clear the banner, so it stayed up until someone tapped Retry. ## Change - Remove the banner along with `MeSync.syncClosed` and `meSyncWarningProvider`. Saved chats stay visible the whole time. - `meGroupsProvider`: on app resume, an interrupted reader (terminal CLOSED or a failed read) resubscribes on its own while the relay is connected. Before the relay reconnects, the existing rebuild-on-reconnect still owns recovery. A healthy reader keeps doing a plain head refresh. - Home's pull-to-refresh (`ChannelsPage` with the Solo sliver) now also restarts the Solo reader. Before this change, that path refreshed channels only, so in the shipped layout the banner was the only manual recovery. - The no-snapshot `_MeRetry` state and the offline-save warning are unchanged. ## Validation - `flutter analyze` is clean. - The pre-push `mobile-checks` passed. - The journey step in `offline_save_page_test.dart` closes the subscription, cycles background and foreground, asserts a new subscription, and checks that a newer event delivered on it is saved. Removing the `subscriptionClosed` recovery branch fails it. - The new `channels_page_test.dart` case drags to refresh with a Solo sliver and asserts the Solo reader restarts. Removing the invalidation fails it. - Not yet exercised in the running app. That is checklist steps 2 and 3. Reviewed by the Royal Court agents (provider lifecycle, recovery/UX, independent challenge); the one blocker (Home pull-to-refresh) is fixed here. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz> |
||
|
Tom Brow
|
ff284d00d3 |
mobile: stop typing prune ticks from rebuilding channel pages (#8695)
### Summary Typing in the mobile composer felt slower than a native iOS text field. A device trace on an iPhone 12 mini showed the cause: while anyone in the channel is typing, the whole channel page rebuilds once per second, including the visible message list. - `ChannelTypingNotifier._prune()` runs on a 1 s timer and assigned a new list to `state` on every tick, even when nothing had changed. - `_ResolvedChannelDetailPage` watched the whole list and only filtered out the current user afterwards, so every tick rebuilt the page and its `PositionedList` (12 to 35 ms per frame, 8 to 19 ms for the message list alone). - Your own typing indicator echoes back from the relay, so the timer kept running the whole time you typed. In a 30-key trace, 33 of the 35 frames over 12 ms were these rebuilds, 1.00 s apart. ### Fix - `_prune()` publishes only when the visible entries change. `TypingEntry` now compares by value. - The channel and thread pages watch `visibleTypingProvider`, a `VisibleTyping` value that already excludes the current user and applies the page's scope. Your own echo refreshes its expiry every 3 s, which used to rebuild the page. Now it doesn't. Other `channelTypingProvider` consumers are unchanged. ### Related issue None found. ### Testing - Provider tests: a typing entry held across five prune ticks notifies listeners once, and the pages' shared `visibleTypingProvider` is not notified by the user's own refreshed echo but is by another user. Breaking either guard fails its test. - `just mobile-check` and `just mobile-test` pass at |
||
|
klopez4212
|
e922dc08ff |
Unify mobile onboarding and community entry screens (#8687)
## Summary Use consistent fullscreen screens for identity setup, community selection, joining, and Add Community. Restore all memberships and open the selected community; share the community grid with the switcher. Add QR-first choices, animated link entry with 12px keyboard clearance, a two-finger double-tap pairing toggle, and the centered reversing bee loader. Preserve cancellation, Back, and reduced-motion behavior. Add intentionally omits community creation and Builderlab sign-in: this route follows sign-in and the existing-community picker. ### Related issue Related: #8628 (native profile setup). No duplicate fullscreen onboarding PR found. ### Testing - Full standard and hosted-authentication mobile suites, static analysis, and required push checks passed. - iPhone preview iterated with Kenny; final simulator walkthrough below uses synthetic data and does not authenticate or save account changes. - Independent review completed; regressions cover cancellation during loading, Add recovery after failed/conflicting memberships, retrying skipped communities, and explicit picker stages. Walkthrough recorded before the copy and recovery followups: https://github.com/user-attachments/assets/bfea3ad3-1dde-40c4-8748-44c84226c292 --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Tom Brow
|
8161a7cad0 |
perf(mobile): derive public keys with native libsecp256k1 (#8655)
Follows #8654. Deriving an x-only public key from a secret key with `nostr.Keys(secret).public` costs about 5.6 ms in pure Dart on an iPhone SE (2nd gen, Profile). The app does it in 10 places, including relay config, the signed-event relay's `pubkey` getter, push lease checks, status updates, and the settings identity row's `build` method. This routes all of them through `derivePublicKeyHex` from #8654, which takes 16.5 µs on the same device. Behavior is unchanged for valid keys: output is the same lowercase hex. For a malformed or out-of-range key the thrown type changes from nostr's `InvalidKeyException` to `ArgumentError`; every affected site either catches all errors or rethrows its own `FormatException`/`StateError`, and nothing in `lib` or `test` matches on the old type. Sites that need a full `nostr.Keys` object (key generation, `AccountIdentityStore`) are unchanged. ### Validation - `derivePublicKeyHex` is checked against `nostr.Keys` for 64 random keys in #8654's `event_signing_test.dart`. - Full mobile analyze and test suite pass on this branch after rebasing onto main, including the package's own tests. - iPhone 12 mini, Profile build of this stack (with #8656 and #8657 on top): paired to the internal Buzz community through Desktop; relay auth, identity row, avatar, and channel/DM/inbox loading all worked under the derived key. buzz-review-completed (agent review, Codex and security review clean; device validation above; human app test not applicable under the mobile testing exception) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Tom Brow <tomb@block.xyz> Co-authored-by: george <973be878edd6d4f79692a3827f20a6f7fe0ed0362f269ff6b6ba8867033d7d8e@sprout-oss.stage.blox.sqprod.co> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Tom Brow
|
a7e65c91da |
feat(mobile): choose remote agent models and gate agents on Builderlab sign-in (#8650)
Follow-up to [#8626](https://github.com/block/buzz/pull/8626). Mobile remote-agent creation now matches desktop. - **Model and reasoning effort:** Create agent has Model and Reasoning effort menus. Their options come from the remote service's catalog, and nothing is preselected (same as desktop). The server checks the selection against the catalog again before registering, and saves it on the agent. - **Builderlab gate:** creating a remote agent requires a hosted community and Builderlab sign-in. The Agents directory, community bots and the Bestie chooser stay available without it. Signing out closes an open Create agent sheet; the Agents sheet stays open. - **Enrollment:** `attest-agent` enrolls the agent in the requested community, as on desktop, so the separate `add-buzz-subscription` call is gone. - **Quieter progress:** spinners replace the progress bars and the "Working…" label. Status and success text ("is ready", "Remote agent deleted.", setup steps) is gone, and only failures show text. Refreshing an already-loaded agent list no longer blanks it. - **Shared setting menu:** `BuzzSettingMenu` is a bordered setting row that opens a Material 3 menu spanning the row's width. Opening it dismisses the keyboard. The channel-TTL setting in Create channel uses it too. Agent avatars and QR/link-based creation follow in stacked PRs. Editing existing agents comes later. | Agents | Create | Model menu | | --- | --- | --- | | <img src="https://raw.githubusercontent.com/block/buzz/d0bee87c45d30b9bdd2163a75966ccd5d64f322a/pr-8650--1-agents.png" width="240"> | <img src="https://raw.githubusercontent.com/block/buzz/d0bee87c45d30b9bdd2163a75966ccd5d64f322a/pr-8650--2-create.png" width="240"> | <img src="https://raw.githubusercontent.com/block/buzz/d0bee87c45d30b9bdd2163a75966ccd5d64f322a/pr-8650--3-model-menu.png" width="240"> | ### Validation - Checked on the staging iOS simulator with a Builderlab account: the Agents list, the Create sheet, and the model and effort menus (including with the keyboard open). - Added tests: catalog-gated model selection (including switching models clears an unsupported effort), the Builderlab sign-in gate, controller creation and resume with a model, a failed listing reported instead of an empty registry, and create sheet busy and failure states (including the catalog reload after a rejected create). - The hosted-only agent tests are skipped without Builderlab defines, which `mobile-test` doesn't pass. They pass locally with the staging defines (20/20). - Not covered: Android. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: Tom Brow <tomb@block.xyz> Co-authored-by: george <973be878edd6d4f79692a3827f20a6f7fe0ed0362f269ff6b6ba8867033d7d8e@sprout-oss.stage.blox.sqprod.co> |
||
|
klopez4212
|
39b8b2b6a6 |
feat(mobile): unify Messages navigation with Solo and Team filters (#8649)
## Summary Unify mobile conversations in Messages with All / Solo / Team filters, a collapsing header, and separate Search, New, and default-agent shortcuts. Move workspace actions into the community menu and keep collapsed sections intact across filters. Align Inbox and list typography, spacing, and muted controls. Preserve native glass layering through navigation and give every filtered list enough clearance above the footer. The default-agent shortcut reads the shared encrypted preference and opens an existing chat immediately. When unset, it opens Agents; a star action selects the default through a production signed, self-encrypted preference writer. Save failures remain visible and retryable. Android now uses rounded navigation controls and filters, optically balanced search icons, and expanding New/community menus with leading Tabler icons matching iOS. Preset avatars retain transparent WebM animation through an Android WebView renderer, with lifecycle pausing and poster fallback. ### Related issue None found in searches for mobile navigation issues and open PRs. ### Testing - Android follow-up: ARM64 debug build, Dart analysis, and emulator checks passed for menu placement, selection, icon alignment, search, and avatar playback/pause/resume. The avatar implementation passed 3,840 Flutter tests and native Android tests before subsequent styling iterations. Automated tests for the later menu/icon iterations were skipped at the author’s request; those earlier results do not cover the final styling changes. - Mobile formatting/analysis and full test suite (3,838 passed, 23 skipped, plus 4 push-configuration tests); regression journey covers filtering, collapse retention, and scrolling the last Solo row above the footer. - iPhone 18 Pro simulator (Honeycomb): filters, menus, Inbox, Invite/Back, Switch Community, and default-agent chat/Back exercised. iOS release build and Pairing Preview install/launch passed during iteration, preserving the saved profile. - P1 follow-up: production writer-to-reader widget journey covers selection, publish failure/retry, and the unset footer opening Agents. Simulator Agents open/close passes; its saved community has no selectable agents, so live selection was not verified there. - Independent agent review completed; its Solo footer-clearance finding is fixed. The final clearance adjustment is covered by widget tests; physical-device acceptance of that adjustment and hosted CI remain pending. Final Messages layout:  Switcher layering during iteration (before → after): | Before: filter edge showing through | After: Home hidden behind switcher | | --- | --- | |  |  | --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Tom Brow
|
4ff02bf03b |
perf(mobile): sign events with native libsecp256k1 on iOS and Android (#8654)
Mobile signs every Nostr event (sends, relay AUTH, media auth headers, preference writes) in pure Dart on the UI isolate. On an iPhone SE (2nd gen, Profile build) one BIP-340 signature costs about 10.7 ms and deriving the public key another 5.6 ms, so a burst of signed writes drops frames. This adds `mobile/packages/buzz_secp256k1`, a small FFI package that builds vendored bitcoin-core/libsecp256k1 v0.8.0 (ecdh, extrakeys, schnorrsig modules) through a Dart build hook, so the same C and the same Dart API ship on iOS and Android with no platform bridge code. All 13 `nostr.Event.from` signing sites now go through `signNostrEvent`, which keeps the `nostr` package's event-id serialization and moves only key derivation and signing to native code. Calls stay synchronous. The package also exposes `schnorrVerify` and `ecdhX`; follow-up PRs move verification and the NIP-44 conversation key over. Incoming relay events are still not verified, unchanged by this PR. Safety: the signing context is randomized once per isolate, secret keys and keypairs are wiped from the native scratch buffer after each call, aux randomness comes from `Random.secure()`, and the static verify context runs libsecp256k1's self test before first use. ### Validation - Added tests: BIP-340 official vectors and native-vs-pure-Dart differential tests in the package; `event_signing_test.dart` signs with 64 random keys and checks pubkey, event id and signature against the existing `nostr` builder and verifier, plus malformed-key rejection. - Full mobile analyze and test suite pass locally. - Builds: iOS release (framework ~1.3 MB) and Android debug APK with the library for arm64-v8a, armeabi-v7a and x86_64 (~1.2–1.3 MB each). - On-device (iPhone SE 2nd gen, Profile, median per op): sign 10,736 µs → 41 µs, derive pubkey 5,580 µs → 16.5 µs, full signed event 10,744 µs → 65 µs. Event-id JSON and SHA-256 are 23 µs, so they stay in Dart. - Device, iOS (iPhone SE 2nd gen, Profile): `buzz_secp256k1.framework` embedded; the signed-in app authenticated to a real community relay, loaded channels and history, and paged older messages. No native-asset or secp256k1 errors in the console. - Device, Android (emulator, debug): APK contains `libbuzz_secp256k1.so` and loads it. Against a local mock relay that verifies with the pure-Dart `nostr` package, the app's NIP-42 AUTH, NIP-98 `POST /query` headers, and kind 20001/30078 events all verified. - Blossom GET auth, iOS: the dev relay returns 401 for unauthenticated `/media/` GETs. From inside the running app, the production `MediaGetAuthService.headersFor()` header for a nonexistent hash got 404 (accepted, file missing), compared with 401 without it. The community has no relay-hosted image, so none was rendered. buzz-review-completed (agent review, Codex and security review clean; device validation above; human app test not applicable under the mobile testing exception) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Tom Brow <tomb@block.xyz> Co-authored-by: george <973be878edd6d4f79692a3827f20a6f7fe0ed0362f269ff6b6ba8867033d7d8e@sprout-oss.stage.blox.sqprod.co> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Tom Brow
|
b310fea05b |
mobile: find DMs opened ahead of the list everywhere (#8646)
## Summary This follows up [#8638](https://github.com/block/buzz/pull/8638) and covers the optional review notes from that PR. - **Shared lookup.** A new `channelByIdProvider` returns the channel from the list, or the copy remembered from a fast DM open when the list doesn't have it yet. The mention picker, mention search failure state, compose bar DM check, thread page, and message unread action all use it. Before this change, those surfaces only searched the list, so a DM opened before the list loaded was treated as an unknown channel. For example, the mention picker skipped directory search and never labeled anyone "not in DM". - **Eviction and scope.** Opened-ahead DMs live in a notifier scoped to one relay and identity, and `channelByIdProvider` watches it. Once the list includes a remembered DM, its opened copy is dropped. Remembering also skips a DM the list already has, since the open's background refresh can list it first. A DM hidden or left later, or one from another community or identity, is no longer found through a stale copy. - **Call-site tests.** Search, the profile Message button, and the New message sheet now assert that they open the DM with `waitForChannelList: false`. ## Validation - `just mobile-check` and `just mobile-test` pass. - The journey test "a DM opened before the channel list loads sends mentions" now also checks the outside-person picker in a DM that isn't in the list yet: a failed directory search shows Retry, then the result appears labeled "not in DM". Mutation checks: reverting the lookup in `mentionCandidatesProvider`, `mentionSearchFailedProvider`, or the compose bar fails the test. - New tests "a DM opened ahead of the list is not found after it is left" (including the refresh-before-remember order) and "a DM opened ahead of the list stays in its community" (a mounted lookup across community and identity switches). Mutation checks: removing the eviction, the listed check in `rememberOpened`, the relay or identity watch, or the lookup's reactive watch each fails a test with `Expected: null, Actual: <Instance of 'Channel'>`. - Call-site assertions. Mutation check: flipping any of the three call sites to `waitForChannelList: true` fails its test with `Expected: [false], Actual: [true]`. - Simulator (iPhone 17 Pro, local relay): I started a fresh DM with Sim Tester from the New message sheet. It opened at once, and typing `@Pat` showed Pat Peer from the directory, labeled "not in DM". <img src="https://github.com/user-attachments/assets/0fe68178-00b5-4533-99f8-fe5d03e8ed88" width="300" alt="Fresh DM with Sim Tester: typing @Pat shows Pat Peer labeled not in DM"> buzz-review-completed 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Tom Brow <tomb@block.xyz> Co-authored-by: george <973be878edd6d4f79692a3827f20a6f7fe0ed0362f269ff6b6ba8867033d7d8e@sprout-oss.stage.blox.sqprod.co> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Tom Brow
|
9e18d17a36 |
fix(mobile): open new DMs without waiting for a full channel reload (#8638)
## Summary
Starting a DM from the mobile **New message** sheet could look broken:
after picking a person and pressing Done, the sheet kept spinning, so it
seemed like the picker could only add people. The DM was being created,
but `openDm` reloaded the whole channel list (memberships, metadata,
hidden DMs, huddles, names, latest messages) before returning. On a
large account or slow connection that can take many seconds.
Interactive opens (New message sheet, Search, profile sheet) now open
the DM from its own metadata and roster, the same targeted read Solo
chat creation uses, and refresh the channel list in the background. The
sidebar still picks up the DM once that refresh lands. When the open
reopens a hidden DM, the fast path also reads the caller's visibility
snapshot in the same round trip and fails visibly if the relay accepted
the open but didn't unhide it, so Done can retry instead of opening a DM
the sidebar keeps hidden. Search and the profile sheet now push the DM
as an ordinary route, as New message already did, so it doesn't sit on a
spinner while Solo groups load. Hidden-DM resurfacing from Activity
keeps the old behavior (wait for the full list), because that reload is
what clears its hidden state and its retry coalescing depends on it.
The fast open also records the DM it read on the channel list notifier,
which falls back to it until the list catches up. Both composers
(channel and thread) look the DM up through it, so a selected mention in
a just-opened DM doesn't wait on, or fail against, the list, and thread
replies there keep their DM recipients.
`findJoinedChannel` now also carries the DM's participant pubkeys so the
opened DM gets its proper title ("Pat Peer", not "DM") before the list
catches up. It also queries metadata and roster separately instead of
under one shared limit, so a lingering pre-backfill metadata revision on
an older DM can't crowd out the roster.
### Related issue
N/A (reported in Buzz #buzz-mobile).
### Validation
- Added tests: `dm_open_latency_test.dart`, a regression test with the
full channel-list load stalled. The interactive open finishes within 2s
with the right channel id, DM flag, membership, and participants. It
publishes exactly one kind 41010, then the background list refresh runs
once the stall clears. The fake serves events like a relay (newest
first, one limit across kinds) and keeps a stale metadata revision
around; the shared-limit read fails it. The test also covers: a DM the
caller can't read fails visibly, a reopen whose unhide snapshot failed
fails visibly, the default (resurfacing) path still waits for the list,
and a community switch mid-read cancels the open.
- Added test (compose bar journey): with the channel list still loading,
a fast-opened DM sends a selected participant mention as a recipient
instead of failing "could not check who is in this channel". It fails if
the composer ignores the opened DM.
- Added test (thread): a thread reply in a DM opened ahead of the list
sends with the DM channel, so it keeps DM recipient semantics. It fails
if the thread page ignores the opened DM. The latency test also checks
the open records the DM before the list has it.
- Mutation checks: the test fails if the background refresh is removed,
if the default path stops waiting, if the interactive path waits, if
participant pubkeys are dropped, or if the still-hidden check is
removed.
- Added tests (Search and profile journeys): with Solo groups still
loading, tapping a person result or the profile's Message button opens
the DM with its composer, not a placement spinner. Each fails if its
call site drops the ordinary placement.
- Full mobile suite: `just mobile-check` clean, 3847 tests passed (23
skipped), plus the unconfigured-push suite.
- iOS simulator (iPhone 17 Pro) against a local relay: New message, pick
Pat Peer, Done. The sheet closed and the DM opened titled "Pat Peer" in
about 1s. Reopening the existing DM took about 0.8s. The DM appeared in
the sidebar after the background refresh. With 400 ms of added one-way
latency (800 ms RTT) through the local proxy, the same flow opened the
DM in 2.5s.
- Re-ran on the simulator at the final head (
|
||
|
Tom Brow
|
d4a07063c8 |
feat(mobile): manage Builderlab remote agents (#8626)
Adds Builderlab remote agents to mobile: a member signed in to Builderlab can list, create and delete their own hosted agents from the channels header, and active remote agents show as Online. Everything is gated by `HostedEnvironment.enabled` (the build-time `BUZZ_AUTH_DOMAINS` define). App Store and internal release builds do not set it, so they render and fetch nothing new. ### Behavior - **Agents** button in the channels header (native iOS bar and Material header) for hosted communities only. It opens a sheet listing the community's agents; tapping one pushes its profile inside the same sheet. - **Create**: for the member's own agents (the NIP-OA owner is the member, not the community). Registers the agent with Beekeeper, attests it to the community, saves optional private instructions, subscribes it to the relay, then publishes the kind 30177 registration with a NIP-OA owner proof. A failed step resumes with the same agent identity on retry; instructions stay in secure storage, never in preferences. - **Delete**: removes the relay registration, confirms it is gone, then deletes the Beekeeper agent. A partial failure keeps a retry row in the list. - **Presence**: an ACTIVE agent with a live kind 30177 registration on the active relay shows Online in profiles, channel rows, DMs and mentions, since remote agents wake on messages. Local presence data is unchanged. - Sign-in reuses the shared hosted flow. The account's saved Buzz key must match the server binding; nothing is adopted or rewritten. - `BuilderlabAccountClient` gains an allowlist for the six Beekeeper routes desktop already uses. Not included from the prototype: the separate entrypoint and second sign-in, test-community creation, staging-only hosts, QR-code agent links, and the USB proxy. ### Validation - Added tests: build-time gate, account/key binding before listing, setup resume with private instructions, deletion contract and retry, owner-proof verification, status parsing, presented presence requiring a live registration in the active community and following registration publish and removal (mutation-checked), account-change clearing, load retry, recovery of a pending setup whose instructions were lost, a lost registration response that can only resume with the same idempotency key (from any community), an HTTP-rejected registration that can be discarded, deletion of other agents while a setup is unfinished, rejection of owner proofs whose signed conditions or profile signature fail, registration publish and removal over a loopback WebSocket relay for an `http://`-saved community, and widget tests for in-sheet detail navigation, creation overlay with failure then resume, and delete confirmation. - The new tests also run in the CI lane with `BUZZ_AUTH_DOMAINS` configured, so the enabled path is covered. - Full mobile format, analyze and test suite pass locally. - Independent agent review: no gate leak or key-handling issue found; its robustness findings (discarding a setup that never got a server identity, clearing registry state on account change, retrying a skipped load, guarded notifications) are fixed; discard and account change have added tests. - Simulator: a `BUZZ_AUTH_DOMAINS` debug build launches to Builderlab sign-in. The signed-in flow was not re-run on this branch. - Codex Security Review: an earlier head received a published review, and its two findings were fixed. On |
||
|
Tom Brow
|
b77ad2ed10 |
fix(mobile): align Solo agent policy and labels with the owner's inventory (#8616)
## Summary
`main` now discovers Solo agents from the owner's kind 30177
managed-agent inventory. This PR aligns two remaining parts of that path
with desktop's agent library.
- **Unsupported policies fail closed.** Desktop parses each agent's
latest 30177 record as `ManagedAgentEventContent` and drops records it
can't parse. Mobile only checked `name`. It now also requires an integer
`parallelism` in `u32` range, a `respond_to` of `owner-only`,
`allowlist` or `anyone`, an allowlist that is absent or a list of
strings, and string-or-null optional text fields. A newer unsupported
record hides the agent instead of falling back to an older one. Records
written by the apps always carry these fields.
- **The owner's name labels the agent in Solo's selection, header and
creation surfaces.** The directory already used the 30177 `name`.
Message authors and the typing indicator still use the agent's profile
name. The existing-chat header, pending-change label, fallback avatar
initials (header, native header action, new-chat row) and the resumed
native creation's saved agent preferred the agent's self-published
kind:0 name. They now use the owner's name first and fall back to the
profile. Profile artwork is unchanged.
### Validation
- Added tests: a table of 11 unsupported policy shapes that must hide
the agent, accepted policy shapes, and journeys where the owner's name
("Owner Name", "Alpha") differs from the cached profile name
("Confusable …"). The journeys cover the new-chat row's title and
initial and the existing-chat header tooltip, initial and pending label.
They also assert the native new-chat payload and picker row, which
already used the inventory name.
- Mutation checks: removing the policy check fails 10 tests; preferring
the profile for the header name, header initial or new-chat initial
fails the matching journey. The saved-agent name on resumed native
creation has no dedicated test.
- The full mobile suite passes (3,806 tests), and `flutter analyze` is
clean.
- The human-testing requirement does not apply under the mobile client
testing exception.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Signed-off-by: Tom Brow <tomb@block.xyz>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
|
||
|
Logan Johnson
|
a4e83dfb50 |
fix(mobile): open message links to public channels the user has not joined (#8518)
🤖 ## Summary - **Problem:** On mobile, tapping a link to a message in a public channel did nothing if you had not joined that channel. The app showed a brief "Channel not found in this workspace" notice and dropped the link, although you are allowed to read that channel. - **Now:** The app asks the relay for that one channel. If the channel is public, it opens as a channel you can read but have not joined, the same as opening it from Browse channels. Private channels and DMs still open only when you are a member. ## Details - Before, the link handler looked for the channel only in the app's loaded channel list. That list holds the channels you joined. It holds other public channels only after Browse channels has loaded them. - When the channel is not in that list, the app now reads that channel's metadata from the relay (kind:39000, the event that names and describes a channel). The relay returns it only if you may see it. The app then refuses private channels and DMs, as Browse already does. - If the lookup fails, the app shows "Could not open the channel". If the relay returns no channel, it still shows "Channel not found in this workspace". - Links are handled in arrival order. While one link is being looked up, later links wait, including links to channels you already joined. When the lookup ends, the app handles the next link. A slow relay can therefore delay later links by up to the lookup timeout (8 s). The app shows no loading indicator during the wait. - A link to a channel already in the list opens at once, even while the app reconnects to the relay. A link that needs the relay lookup waits until the relay connection is signed in, then opens without a second tap. If the connection drops during the lookup, the app keeps the link and tries again after it reconnects. - During hosted setup the app turns link navigation off. If a lookup ends during setup, the link stays queued and opens when setup closes. It does not open a channel over the setup screen. ### Related issue None found. #8292 covers a different part of message links. ### Testing - New dispatcher tests cover a public channel you have not joined, a private channel you have not joined, and a failed lookup. All three fail on main and pass here. - Delayed-lookup tests hold the relay response open. They cover navigation turning off during the lookup (the link opens only after navigation turns back on; this test fails without the fix), a queued link behind a slow lookup, and the dispatcher closing during the lookup. - Reconnect tests start with cached channels and a reconnecting session. An unlisted-channel link sends no lookup and stays queued, then opens after the session connects. A listed-channel link opens at once while reconnecting. A session drop during the lookup keeps the link and retries it, both when the session returns after the cancelled lookup ends and before it ends. The three reconnect cases fail on the previous head. - `flutter test test/features/channels test/features/onboarding` (1990 tests) and `flutter analyze` pass on the rebased head. - End-to-end on an Android emulator (API 36) against a local relay. Alice made a public channel `#launch-notes` and posted in it. In a private channel `#team`, she posted a link to that message. The phone user is a member of `#team` but not of `#launch-notes`. The same install was upgraded in place from a main build to this branch's build. | Before (main): tap the link | After: tap the same link | After: link to a private channel you are not in | | --- | --- | --- | | <img width="300" alt="Tapping the message link shows 'Channel not found in this workspace' and stays in #team" src="https://github.com/user-attachments/assets/aa4341aa-8d87-4a78-a805-ef71f4bd6cc5" /> | <img width="300" alt="Tapping the message link opens #launch-notes with Alice's message and a 'Join this channel from Manage to participate' footer" src="https://github.com/user-attachments/assets/267930ab-b723-4d97-bb7f-960fe1497e63" /> | <img width="300" alt="Tapping a link to a private channel still shows 'Channel not found in this workspace'" src="https://github.com/user-attachments/assets/10780121-c3a4-4cf4-a8d1-a6994cac0101" /> | --------- Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> |
||
|
klopez4212
|
b14884980e |
Speed up mobile Solo chat creation and agent discovery (#8547)
## Summary Solo compose now opens before agent discovery finishes, and chat creation avoids full channel-list reloads while overlapping independent reads. Durable retries, ownership checks, and relay confirmation remain intact. The agent picker uses the owner's saved inventory, excludes known archived identities, verifies profiles off the UI thread, and reuses avatar artwork. ### Related issue No matching issue found. Related: #8546 adds project selection to the same compose surface. ### Testing - Full mobile suite: 3,755 passed, 19 skipped; four additional artifact tests passed. - Analysis, formatting, file-size checks, and iOS Release build passed. - Regression tests fail when the old blocking paths are restored. - Installed on a physical iPhone with existing profile/community settings preserved. Owner tested the earlier creation/picker improvements; final compose timing awaits device feedback. No timing recording captured. --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Wes
|
8ceca8ac46 |
perf(mobile): batch initial channel read-state seeds (#8607)
## Summary Opening an uncached community seeded each previously unseen channel's read marker separately. Every seed copied and serialized the full read-state snapshot, started three preference writes, and notified listeners. Home now collects those seeds and saves/emits once, using the existing monotonic marker admission rules. For a 400-channel fixture with one existing marker, initial seeding falls from 399 full snapshot saves to one. Existing unread frontiers, local-only seeds and explicit read publishing keep their behavior. No transport, cache, relay or unread eligibility changes. This is independent of #8580 and #8490. ## Validation - `just mobile-install mobile-check mobile-test`: clean analysis; 3,779 tests passed, 19 skipped, plus four checks for builds without push configuration. - Real Home/channel-provider/read-state journey covers 400 channels, preservation of an existing unread highlight, persisted marks, no seed publication, and no repeated seed save on refresh. It replaces the earlier fake-notifier seed test. - Restoring the old per-channel loop makes the new journey fail at the single-snapshot assertion. - Diff and file-size checks pass. - Merged current main (`209fcd217`) at `d34d29627`; retained both the cold read-seeding and cached-community landing test registrations. The production diff is byte-for-byte unchanged from the version reviewed by the Court at `6a232ed37`. The complete mobile gates above passed again on the merged tree. Device latency is unmeasured. The Court source review found no blockers at `6a232ed37`; app/device testing and human acceptance remain unconfirmed. To try: open a community without a saved channel list, confirm its channels load and existing unread highlights remain correct, then refresh and reopen it. The performance claim here is reduced save work, not a measured end-to-end speedup. Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Star Lord <b89298dbe87c6b3fd8a425b535d9d161f23c88d555a47925ae0b04dfe02b201e@buzz.block.builderlab.xyz> |
||
|
Wes
|
ab73cd9fb5 |
perf(mobile): restore cached channels before community sync (#8580)
## Summary Returning to a previously visited community shows its saved channel list immediately, including offline, while membership and unread state refresh in the background. Initial revalidation failures keep the list visible and retry every 60 seconds without overlapping background attempts. After successful history revalidation, ordinary reconnects use metadata-only refreshes. A reconnect arriving during a background request queues one follow-up attempt; timer ticks never queue overlapping work. History deadlines retain the full-revalidation retry until history succeeds. Snapshots are disposable, versioned and scoped by canonical relay URL and signing identity, capped at 2 MB / 2,000 member channels. They include hidden-DM IDs and prefer fresher in-memory state. Community removal and identity replacement retire outstanding writes; re-adding unchanged credentials preserves the current cache and writer. Startup sweeps orphan snapshots without waiting for disk acknowledgement; community mutations also sweep orphan snapshots, including data restored without secure community records. Cache-delete failures do not block sign-out or strand push revocation; deletion is attempted before journaling and retried by orphan cleanup. Successfully persisted unchanged snapshots skip disk writes; failed writes remain retryable. The cold path reuses fetched membership rosters, overlaps profile/latest-message requests, shares verified DM profiles with avatars, and fetches the own profile once per authenticated connection. Community connection work overlaps the switching animation; avatar hydration no longer gates landing. Full channel refreshes also revalidate cached DM participant profiles so relay-side name changes reach labels and avatars; metadata-only reconnects and background refreshes reuse admitted profiles. Me-chat and invite starter recovery use an explicit fresh membership fetch that propagates errors while leaving the cached list visible. Cached layout/read preferences permit immediate landing; newer cross-device preferences may update ordering or badges after reveal. Integrated with main’s #8490 idle/resume changes: hidden chats detach live subscriptions, background membership polling stays quiet, and each resume reconciles once. Chat history follows main’s live-admission-first ordering to avoid missing messages committed during relay admission; cached community landing remains immediate. ## Validation - `just mobile-install mobile-check mobile-test`: clean analysis; 3,778 tests passed, 19 skipped; four checks for builds without push configuration passed. File-size and diff checks passed. - Provider/storage journeys cover offline startup, failed initial revalidation recovering live delivery, bounded retries, lightweight reconnects, scope isolation, default-port URLs, padded/mismatched stored credentials, credential replacement, backup-restored orphan data, removal races, failed platform deletes and failed writes. - Follow-up regressions cover interrupted native Me-chat lookup, invite failure propagation, retry after an initial list failure, history deadlines, queued reconnects, escaped-path keys, unchanged credential re-adds and non-blocking startup cleanup. Reverting each of the eight behavior/caller/cleanup-order fixes fails its corresponding regression. - DM-name regression changes only the relay profile, verifies a full refresh updates the channel label and shared profile cache, and confirms ordinary reconnects avoid another profile request. The original cache-only implementation fails this regression. - Original signed-in iPhone 18 Pro debug simulator measurements: Buzz's 413 channels went from 6.26–6.30 s to approximately 1.5 s on returning; all three warmed communities switched in 1.47–1.54 s. Real socket pause restored the cached list offline and retained it on reconnect. These are debug simulator observations, not release-device benchmarks. - Integration with current main also passes the real-session resume/background/AUTH and live-admission/detach journeys. - Follow-up failure paths were exercised with deterministic provider/storage tests and widget journeys; the running simulator was not modified during this follow-up. Human acceptance remains pending; this PR stays draft. Try switching among previously visited communities, opening a channel, restarting and repeating. First visits and oversized snapshots require network loading. Cached metadata can be stale until refresh; it lives in ordinary preferences without additional application-level encryption. The snapshot contains no message bodies or credentials. Persistent disk-deletion failures can leave metadata until a later cleanup succeeds. --------- Signed-off-by: Star Lord <b89298dbe87c6b3fd8a425b535d9d161f23c88d555a47925ae0b04dfe02b201e@buzz.block.builderlab.xyz> Co-authored-by: Star Lord <b89298dbe87c6b3fd8a425b535d9d161f23c88d555a47925ae0b04dfe02b201e@buzz.block.builderlab.xyz> Co-authored-by: Rocket <0c41329ade659e01801116549bc617351689892a382bc864a1186dc9191293a7@buzz.block.builderlab.xyz> Co-authored-by: Groot <f4c08302591916fb4b80926bf7e18d22eef8aa0c877e4e841acc46405a45700b@buzz.block.builderlab.xyz> Co-authored-by: Mantis <530af7635ef7d0e1a5189d234338db88cb4ef1ede7119b4ebb4fb05c3eafe3b1@buzz.block.builderlab.xyz> |
||
|
Wes
|
d090ac24bb |
perf(mobile): cut idle and resume sync churn (#8490)
## Summary Mobile does background work nobody sees, and it waits on round trips it doesn't need. This PR fixes four things: - **Chats you've left let go.** A chat with no listener for 30 s drops its live and typing subscriptions. Coming back shows the cached timeline right away, then resubscribes and catches up. - **No requests before AUTH.** The relay rejects any REQ that arrives before NIP-42 AUTH completes. History requests are now held until the socket authenticates, and they flush after the rate-limit gate. Live subscriptions skip their REQ, and the replay on connect sends it. `auth-required` is terminal for a live subscription, so a pre-AUTH live REQ could be dropped for good. - **Resume reconciles the channel list once.** `resumed` is published before the session hears about it. So the channel list now decides one microtask later: if the session is reconnecting, the connect does the reconcile. - **The 60 s backstop only runs in the foreground on a connected session.** After an OS suspension, the missed tick fires at unfreeze, about 450 ms before the app hears `resumed`, while the session still looks connected. Without this, that tick triggered a second full sync. Scope note: while the app is in the foreground, the backstop still re-downloads membership every 60 s. That matches desktop, which refetches every 60 s while focused. To drop it, mobile would need to subscribe to the live membership notices (44100/44101), as desktop does. That would be a follow-up. ### Related issue N/A. This is follow-up work from the mobile perf dive. None found. ## Before and after Simulator setup: iPhone 18 Pro simulator, debug build, a local relay behind a proxy that adds ~120 ms RTT, and a seeded account with 120 channels. I scripted one identical run against each build: 1. Open 5 channels. 2. Visit 20 more channels. 3. Wait 40 s. 4. Stay idle in the foreground for 3 min. 5. Go to the background for 3 min. 6. Resume. `main` is `ca3be5501`; the branch is `d77c4e86f`. The last amend changed only test names. Since then, chat history waits for the live EOSE again (see the note below), so channel open is back to `main`'s order. | | `main` | this PR | |---|---|---| | Live subscriptions after visiting 20 chats | 61 | 11 | | Resume: membership reads | 2 (244 kB) | 1 (122 kB) | | Resume: websocket REQs | 36 | 31 | | Resume: REQs sent before AUTH | 9 | 0 | | Resume: REQs rejected as `auth-required` | 2 | 0 | | Idle foreground, 3 min | 3 membership reads, 12 REQs | same | Notes: - **Channel open:** an earlier revision requested history without waiting for EOSE, which cut the median open from 297 ms to 197 ms. Review showed it can lose a message. The relay registers the live REQ only after its access checks, so a message committed in between reached neither the window read nor the subscription. A timestamp overlap only covers messages signed within it. Keeping that speedup safely would mean a second window read on every open, so it's left out. - **Idle foreground is unchanged by design.** See the scope note above. - **Background traffic:** the simulator suspends the app shortly after it leaves the foreground, so both builds sent almost nothing during the 3 minutes in the background. The backstop fix shows up at unfreeze instead, as the missing second membership read. - **Resume inbound events:** in this one run, events received over the websocket on resume were 247 kB on `main` and 338 kB on the branch. I haven't attributed the difference. ## Test These extend the existing journeys, plus one new journey: - **`channel_messages_journey_test`:** - The window read waits for the live REQ's admission, and a message signed a minute earlier but committed before admission shows up. - After the listener leaves, the chat keeps following for 29 s and stops at 31 s. - Coming back shows the cached rows immediately, then catches up on a message sent while away. - **`relay_session_test`:** a stale-connected resume sends nothing before AUTH. Then exactly one history REQ and one live REQ go out after AUTH. - **New `channels_sync_journey_test`:** drives the real lifecycle, session and channel notifier against `FakeRelay`: - A backgrounding just before a backstop tick sends nothing. - A resume after the session paused syncs once. - An OS-suspension resume with AUTH held syncs once, after AUTH, and sends no REQ before it. - **`FakeRelay`:** gained `holdReq`, `holdAuth`, `before_id` pagination and an injectable clock. Each guard was mutation-checked, and every mutation failed its test: - live REQ sent before AUTH - history sent before AUTH - resume refresh not deferred - backstop without the lifecycle check - history read alongside the live REQ - a 30-day detach delay Follow-up, not in this PR: a history REQ already in flight on a socket that gets replaced still waits for its 8 s timeout. Princess Donut found this in review; it predates this change. ## Validation - `flutter analyze`: clean - Full mobile suite at `678617b`: 3,696 passed - Court review (Princess Donut on the relay session, Mongo on chat subscriptions, Mordecai on the channel list plus a challenge pass): no blocking findings. The rate-limit flush ordering came from that review. **Human test:** Wes ran `da5077d` on the simulator with his real account and confirmed it works. `460dc35` then fixed a review blocker: a chat rebuilt while detached stayed detached. A retest of that path is pending: leave a chat for more than 30 s, background the app for more than 5 s, resume, then reopen the chat. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
klopez4212
|
dc25198d53 |
Add project selection to new Solo chats on mobile (#8546)
New Solo chats can optionally choose a project in the Flutter form and native iOS sheet. Project appears above the agent picker with matching neutral text, and the choice survives retries and restarts. Validation: full Flutter suite passed; analysis and iOS builds passed. Installed in Pairing Preview on iPhone Air and visually approved, preserving saved preferences. Successful live chat creation remains unverified because no agents were available. --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
klopez4212
|
8260b6ef4c |
feat(mobile): group typing avatars into one animated indicator (#8543)
## Summary Replace stacked mobile typing rows with one animated avatar cluster and one typing bubble. People and agents share diagonal, triangle, and four-corner layouts, with a circular +N badge for overflow and reduced-motion support. Includes an opt-in local demo (`BUZZ_TYPING_PREVIEW=true`) with mixed human/agent avatars and count controls; it never publishes typing events. ### Related issue Follow-up to #8505. No duplicate found in the typing-avatar PR search. ### Testing - 3,736 mobile tests plus four unconfigured-push tests passed; analysis and file-size checks passed. - Installed and iterated on a physical iPhone with the existing profile/community preserved; owner reviewed the motion and badge sizing. Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
klopez4212
|
e8781caa6f |
fix(mobile): remove Browse channels from channel list (#8539)
## Summary Remove the “Browse channels” action above the mobile channel list. The list now starts with its channel sections or empty state. Remove the unreachable browse sheet and its obsolete tests; keep channel directory providers and the create-channel/direct-message actions. ### Related issue No duplicate removal PR found. Related: #6243 introduced mobile channel browsing. ### Testing - `just mobile-check mobile-test`: formatting and analysis passed; 3,729 tests passed, 16 skipped, plus all four unconfigured-push tests. - Release iOS build succeeded. Installed and launched in place on a physical iPhone Air in Pairing Preview; existing preferences retained except channel read-state updated after launch. - Existing quick-action test asserts the browse button is absent. - `git diff --check` passed. - Pre-push hooks passed on commit `269df8b3e` (full mobile checks and tests plus file-size gate). The first attempt timed out in the unrelated iOS push-gateway validator test; the unchanged-commit retry passed. - Full repository `just ci` remains in progress through native desktop checks; not claimed green. Draft pending owner visual confirmation and review. Screenshots have not been captured; installation/launch is not visual acceptance. Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Mohammad Asfour
|
1a54eec3db |
fix(mobile): keep token labels visible in authored Markdown links (#7545)
## Summary On iOS, an authored Markdown link renders as blank when its label is recognized as a Buzz channel, mention, or custom emoji. For example: ```markdown [#2959](https://example.com/) ``` The surrounding text remains visible, but the link has no visible label or tap target. Buzz's `_ChannelLinkMd`, `_MentionMd`, and `CustomEmojiMd` components return `WidgetSpan`s. `gpt_markdown` also renders an authored link through a `WidgetSpan` and reparses its label through the registered components. Because the Buzz components were allowed to run inside link labels, the result was a placeholder nested inside another placeholder, which does not paint on iOS. This PR adds the same scope restriction used by `gpt_markdown`'s built-in link component: ```dart @override Set<MarkdownScope> get scopes => MarkdownComponent.allScopesExceptLinkLabel; ``` The override is applied to all three widget-based components. Authored labels such as `[#2959](url)`, `[@Alice](url)`, and `[👋](url)` therefore remain ordinary link text, while the same tokens outside links continue rendering as Buzz pills and custom emoji. The PR also updates the shared test helpers to find `RichText` subclasses. Since the upgrade to `gpt_markdown` 1.2.1, body paragraphs can render through `BidiRichText`; `find.byType(RichText)` does not match that subclass and could allow an absence assertion to pass without inspecting the message text. The handling of unknown bare `#tokens` is deliberately unchanged. Whether those should remain non-interactive pills or become plain text is a separate product decision. ### Related issue Fixes #6124. This supersedes #6135. That PR solves the same issue by maintaining a custom fork of `gpt_markdown`'s link component; this PR instead uses the scoped-component API already available in `gpt_markdown` 1.2.1. ### Testing Focused suites: ```bash flutter test \ test/features/channels/message_content_test.dart \ test/features/channels/message_content_custom_emoji_test.dart ``` Result: 95 tests passed, 0 failed. Additional checks: - `just mobile-check` — passed; analyzer reported no issues. - `just mobile-fmt` — passed; 549 files formatted with 0 changes. - Six new regression tests cover channel, mention, emoji, plain-link control, and outside-link behavior. - Removing the `_ChannelLinkMd` override causes two regression tests to fail; removing `_MentionMd` or `CustomEmojiMd` causes one test to fail in each case. - Three tests in `message_content_test.dart` directly assert that the nested-placeholder structure is absent. The custom-emoji tests separately verify literal text and the absence or presence of `CustomEmojiImage`, depending on whether the shortcode is inside or outside a link. The complete local mobile suite reports 15 failures that reproduce identically on a clean checkout of `main` at `44316ff7`. In [CI for that same commit](https://github.com/block/buzz/actions/runs/34238736818), `Clients / Mobile`, `Mobile`, and `Mobile Swift Domain / Mobile Swift` all passed. No native-device screenshot is included. The nested-placeholder fix was verified through the rendered widget structure, but an iOS simulator build was blocked by the existing `MLImage.framework` arm64-simulator incompatibility. Signed-off-by: Mohammad Asfour <masfour700@gmail.com> Signed-off-by: Samin Yeasar Sohag <sssohag172@gmail.com> Co-authored-by: Samin Yeasar Sohag <sssohag172@gmail.com> |
||
|
klopez4212
|
0768397092 |
feat(mobile): show inline human typing and outgoing avatars (#8505)
## Summary People typing in a mobile channel now appear beside their avatar in an inline three-dot bubble, using the existing agent typing animation instead of the separate composer status strip. Human avatars stay round; agent identities retain their agent shape. Reduced Motion keeps the dots still, and thread-scoped typing remains inside its thread. Restore the viewer’s avatar on the right of their own messages in channel and Me timelines. Grouped messages show the avatar on the final bubble, with reactions and reply footers aligned to the bubble. ### Related issue No duplicate found. Related: #3668 tracks observer-backed agent working status; this PR changes presentation only and does not add observer lifecycle behavior. ### Testing - `just mobile-install`; final pre-push `just mobile-check && just mobile-test` passed (3,728 tests passed, 16 skipped; 4 unconfigured-push tests passed). Repository file-size gate and commit formatting passed. - Regression checks fail against the original channel typing and outgoing-avatar implementation. - Pixel 10 / Honeycomb Studios: the recording build exercised inline human/agent typing, avatar shapes, own-message avatars, and message arrival. That build predates this fresh-main PR; the PR additionally uses the shared agent identity lookup. - Before/after widget-rendered previews use generic sample messages. No recording identity, app-package override, or demo scripts are included. ### Before / after Rendered from the production channel widgets using generic sample messages; Reduce Motion enabled for the stills. | Before | After | | --- | --- | |  |  | ### Manual check Open a channel and have another person type: their round avatar and animated dots should appear at the bottom of the conversation and disappear when the message arrives. Send two consecutive messages: your avatar should appear once beside the final bubble. Repeat with Reduce Motion and larger text. Draft pending human testing of this PR snapshot. Do not merge based on the earlier recording alone. --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Tom Brow
|
93114b4279 |
fix(mobile): lazily lay out new-DM recipients (#8435)
The new-message picker laid out every recipient inside an outer scroll view. Searching or changing selection could therefore mount the whole directory in one frame. Use a bounded sliver viewport so offscreen recipients stay lazy while the search field and selection chips still scroll above the keyboard. ### Validation - Current-head CI passed, including all Flutter test shards, Android, and native/release Swift jobs. Code and security reviews found no issues. After merging main and retaining both test imports, all 81 channel-page tests and the full mobile check/test suite passed. - Added a 200-person widget regression: the original mounts all 200 rows; the fix keeps fewer than 30 mounted through open, search, selection and removal, and can scroll to the final recipient. Covers no-match and closing too. - Strengthened the keyboard/chip test to verify the eight-recipient limit and that removing a chip makes the ninth recipient reachable. - All 79 channel-page tests passed; the strengthened limit test and Flutter analysis passed. - Native iOS simulator build passed. On a separately cloned paired simulator, verified populated directory/search, eight selected recipients, limit message, removal, no-match, scrolling to the final recipient and close without creating a conversation. Debug/AX instrumentation and a newer Flutter baseline make this functional validation, not a controlled release-speed benchmark. - Normal pre-push mobile checks passed, including formatting, analysis and the full Flutter test suite. Required CI exposed existing formatting in `message_carousel_preview_cases.dart`; a separate formatter-only commit corrects it. - The full local repository gate hit an unrelated Rust failure in `buzz-acp::signals_cancel_startup_turn_and_pending_stdin_without_hanging` (exit status `None` rather than `Some(143)`). No Rust code changed. The gate stopped at unit tests, so later build stages did not run. ### Related issue No duplicate recipient-layout fix found in the existing issue/PR search. ### Before and after The synthetic 200-person picker renders identically before and after (with a reserved keyboard inset). One image represents both; mounted-row assertions establish the performance mechanism separately.  --------- Signed-off-by: Tom Brow <tomb@block.xyz> |
||
|
Tom Brow
|
bf4a163510 |
fix(mobile): lazily lay out channel member groups (#8437)
Opening a large channel member sheet mounted and laid out every person in a grouped column. A captured Debug simulator entrance spent 242 ms in the UI callback, including 223 ms in layout. Build each person and agent as a lazy sliver row while preserving the grouped cards, names, statuses, management menus, and activity actions. Screen-reader row indices continue across both groups. A separate formatting-only commit fixes an existing carousel-test formatter discrepancy. No duplicate member-sheet performance PR or issue found. ### Validation - Added a 200-member widget regression: the original mounts 100 people initially; the fix mounts fewer than 20 nearby rows and reaches the final person and agent. - Added grouping, compact sizing, empty state, member tap identity, accessible indices, and scrolled member/agent menu checks. Existing channel-details “See all” navigation test passes. - Mobile formatting, static analysis, and the full mobile test suite passed on the committed tree. - Synthetic before/after rendering is pixel-identical at the same viewport. - Populated native iOS 26.5 simulator workflow: open members, scroll through people and agents to the end, then close. Final installed build passed this workflow. Debug, accessibility automation, profiler overhead, different Flutter versions, and shared-host load limit timing conclusions. This removes eager offscreen layout; it does not establish a controlled end-to-end speedup or release-device performance. ### Visual check Synthetic member sheet; before and after are pixel-identical at this viewport.  --------- Signed-off-by: Tom Brow <tomb@block.xyz> |
||
|
Tom Brow
|
a93f3282cc |
perf(mobile): retain preference crypto across reconnects (#8442)
Foreground reconnects rebuild preference managers and repeatedly derive the same NIP-44 keys on the UI isolate. Retain the six crypto objects in providers scoped to relay configuration and identity while preserving manager refresh, subscription, and publication behavior. Community changes, key rotation, and sign-out invalidate the retained objects. RelayConfig normalizes the signing key once at its shared accessor, so identity, theme encryption, event signing, and NIP-42 authentication receive the same value, including when an active configuration key has surrounding whitespace. The identity-export authorization snapshot uses the same normalized key for the active-identity check and the outgoing recovery payload. The branch incorporates main's relay-scoped preference managers. ### Validation - Regression exercises six production crypto providers across reconnects, configuration/key changes, and sign-out. Reintroducing a session dependency makes it fail. - Added a loopback WebSocket regression that exercises actual RelaySocket NIP-42 authentication with a padded key and verifies its challenge, relay, pubkey and signature. It fails before shared key normalization. - Added a connected-theme regression for whitespace-padded keys, encryption round-trip, and a valid published event signature. It fails before the normalization fix. - Added padded-key identity export coverage through authorization, SAS confirmation, exactly one normalized payload, and successful completion. Separate relay-change and key-rotation tests verify both fresh and expired grants fail closed. The padded-key regression failed before the fix. - Current head: all 48 focused pairing/crypto/auth tests and mobile analysis passed. All [CI checks](https://github.com/block/buzz/actions/runs/39497098787) passed, including mobile test shards, Android, native Swift tests and release builds. Codex feedback is addressed; Jude approved this exact head after independent regression and mutation checks. Fresh [Codex security review](https://github.com/block/buzz/pull/8442#issuecomment-6300273942) found no concrete issues. - Previous head: 122 config/socket/crypto/theme tests, 44 read-state tests, and all [GitHub CI checks](https://github.com/block/buzz/actions/runs/39491550425) passed, including mobile test shards, Android, native Swift tests and release builds. - Original implementation: native iOS Debug build and full local repository checks passed. A paired simulator background/resume capture had no samples in the targeted crypto constructors or key derivation; an 82 ms UI frame remained. Debug/JIT, profiler overhead and shared-host activity prevent an overall speedup claim. The later normalization change is covered by the production-provider regression above. - Two image decode timing failures occurred in the initial local full suite; direct baseline/patch runs, the subsequent full repository run, and the latest full mobile suite passed. Cold-start credential validation is unchanged: padded persisted keys are rejected by AuthNotifier before RelayConfig is constructed. The normalization regressions cover active configurations and identity export, not broader persisted-key acceptance. <!-- buzz-review-completed --> --------- Signed-off-by: Tom Brow <tomb@block.xyz> |
||
|
klopez4212
|
ca35114209 |
fix(mobile): simplify and refine the quick actions menu (#8491)
Keeps the mobile + menu focused on Create channel and New direct message, with 8-point facing corners, a 6-point gap, and the active Home/Solo tab fill on iOS. Moves Browse channels directly above the channel list, including its empty state, preserving open-channel discovery, retry, and Join. Adds a cold-start journey through the real channel loader and join action with relay boundaries faked. Validation: mobile formatting/analysis and full mobile test suite; mutation check confirms the new journey fails when directory loading is removed. The original menu styling was tried on a physical iPhone; the replacement Browse entry has widget-journey coverage and has not yet been tried on device. --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Tom Brow
|
cdc2b129c0 |
fix(mobile): resolve DM display labels once per sort (#8488)
Home's DM sort resolves participant identity names again for every comparator call. This work appeared in a captured 82.163 ms UI frame after foregrounding the full app (Debug/JIT iOS simulator, shared host). Resolve each lowercase display label once per sort, retaining the same label ordering and channel-ID tie-breaker. Sort keys are invocation-local, so later viewer, profile, owner, participant, and community changes cannot reuse stale labels. No matching open mobile sorting PR or issue found. ### Validation - Added synthetic regression coverage for bounded contextual resolution and ordering parity across identity/name/channel changes, ties, unnamed DMs, and empty/singleton lists. The 80-DM fixture performs 80 contextual resolutions instead of the original comparator’s 982; restoring that comparator makes the regression fail. - 133 focused tests passed, including existing Home scrolling/reconnect widget tests and identity-name tests. - Mobile static analysis passed; 3,697 tests passed with 16 existing skips, plus four no-gateway configuration tests. - No new full-app or hardware capture. The existing trace establishes repeated synchronous work, not its release-build magnitude or the cause of every scrolling stall. Signed-off-by: Tom Brow <tomb@block.xyz> |
||
|
klopez4212
|
5fefec604f |
fix(mobile): restore channel icons and align chat colors with desktop (#8478)
## Summary - Restores `#` and lock icons for public and private channels on Home, with matching loading placeholders. - Updates the dark-mode navigation colors to the desktop design-system tokens (read and unread text, section headings). - Replaces the chat color picker with the seven desktop accents (Gray, Chartreuse, Flame, Magenta, Iris, Cobalt, Jade). Saved legacy colors map to the closest one. - Uses white text in your own bubbles, and black where white falls below 4.5:1 (Chartreuse, dark-mode Gray). Links (underlined), quotes, tables and code use the same text color. - Insets code blocks in bubbles evenly, with corners concentric to the bubble and even inner padding. - The swipe-to-reply indicator uses the chosen chat color. ## Testing - `flutter analyze` and `dart format` are clean. The full mobile suite passes (3,705 tests). - Installed and checked on a Pixel 10 and an iPhone Air against a real community. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> Co-authored-by: Queue <874bf2d815c2c4b459b90438c669c57f2702f3a76bb6e16fa97184259aac3e9e@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
klopez4212
|
c9e35f8ac7 |
fix(mobile): restore Solo chats from channel labels (#8466)
Restore Solo chats and project placement on mobile using `buzz.solo`
labels and creator metadata. Invalidate stale channel details when
identity changes so opening and sending preserve refreshed Solo
identity; shared chats retain ordinary sending. New mobile Solo chats
publish the discovery label, and the personal send guard enforces
ownership even when route hints or legacy placement suggest Solo.
The current desktop producer lives in `block/buzz-app`. [Contract
documentation](
|
||
|
Wes
|
3ec6327618 |
fix(mobile): keep cached state with its community (#8349)
## Summary One identity can be paired with several communities, but mobile keyed several caches by pubkey only. Mobile keeps a single `ProviderScope` and doesn't remount on a community switch, so one community's data showed up in another, and some of it was published to the other community's relay. - **Channel groups**: the second community showed the first community's groups. - **Read marks** (contexts, publishable set, NIP-RS client and slot IDs): the first community's context IDs were merged into, and published to, the second community's read-state slot. - **Inbox done/unread rows and thread follows**: one shared 500-entry cap, so activity in one community evicted another's entries. - **Channel stars and mutes**: union-merged across communities and published to every relay. Every one of these is now keyed by pubkey + normalized community relay, the same way channel sort already is. **Switching communities.** The relay session rebuilds for the new community before the previous community's managers are retired. Each manager (groups, read state, stars, mutes) now checks that the session still serves its own community before it publishes, merges a fetch, or handles a live event. Previously, a pending publish flushed on dispose, or an in-flight fetch, could cross into the next community. **Old pubkey-only entries.** Channel IDs can repeat across communities, so nothing tells us which community an old channel-keyed entry belongs to: - **Groups, stars, mutes and read marks** are dropped on upgrade, and each community restores its own from its relay. Any change that never reached a relay is lost, and a read mark the relay doesn't hold shows as unread once. That's an accepted tradeoff: such changes would be very old by now. - **Inbox, thread follows, and read-state slot and client IDs** seed every community, and the old entry is kept. The inbox and follows entries are event IDs, which only ever match their own community. The slot ID keeps each community publishing to the slot it already has on its relay. This PR also removes the **Pulse** feed (`features/pulse/` and the Nostr filters only it used). Nothing in the app navigates to it anymore, and its providers were among the community-unscoped caches. ### Related issue None found. ### Testing - Each affected store has a regression test through the real provider that switches A → B → A. For groups, read marks, stars and mutes, the test sets a value in A, switches to B while A's change is still pending, and checks two cases: B's data arriving live and B answering A's in-flight fetch. It asserts that nothing sent to B contains A's IDs, B shows only its own value, and A comes back unchanged. Each guard was removed in turn to confirm a test fails without it, except two that the current switch order never reaches: the groups merge guard and the read-state live-event guard. - Upgrade tests cover each kind of old entry: dropped for groups, stars, mutes and read marks, seeded for inbox, follows and slot IDs. - `flutter analyze` is clean, and the full mobile suite passes in the pre-push hook at `89ebfcc12`. - Not yet exercised in the app. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Wes
|
52aa37a929 |
perf(mobile): stop an open chat rebuilding on other channels' events (#8456)
## Summary While a chat is open, a message in any other channel rebuilt every built row of that chat. There were two causes: - **The chat watched the whole channel list.** `channelsProvider` republishes the list on every live event in any channel. The chat page, its message list and the thread page watched all of it. They now watch only their own channel's entry. The `#channel` name map comes from a new `channelIdsByNameProvider`, which notifies only when a channel name or id changes. - **The root `App` rebuilt often, and each rebuild rebuilt every pushed route.** It watched the agent observer and the user-status cache only to keep them alive, and it watched the whole Me unread set. It now listens to the first two and selects only whether Me has unread. Rows still remount when a message arrives in the open channel. That comes from `scrollable_positioned_list` keying rows by index, and it gets its own PR. ## Before and after Setup: - iPhone 18 Pro simulator, debug build. - Local relay with about 120 ms of added round-trip time. - Seeded community: 120 channels, about 5.5k messages, a busy chat of about 1.4k messages. - The same scripted run on `main` at `5730c83f7` and on this branch, counted with local probes that are not part of this PR. - Counts are exact. Debug milliseconds are only useful for comparing the two runs. 10 messages arrive in another channel while the busy chat is open: | | `main` | this PR | |---|---|---| | Chat page rebuilds | 42 | 0 | | Message row rebuilds | 1,218 | 0 | | Frames with build time over 16.7 ms | 42 of 129 | 0 of 10 | | Worst frame build time (debug) | 78 ms | 13 ms | 5 messages arrive in the open chat: 1,300 row rebuilds on `main`, 693 on this PR. Most of the rest are the remounts from the index-keyed list. ## Test A widget test publishes a new channel list where only another channel changed, and fails if any `MessageContent` rebuilds. Reverting the production change makes it fail. ## Validation - `just mobile-check` - Full mobile suite: 3,532 passed. - The simulator run above. **Human test:** Wes ran #8456, #8460 and #8462 together on the simulator with his real account and confirmed they work. buzz-review-completed 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Wes
|
db50afd8a7 |
perf(mobile): load the channel list's membership-scoped reads together (#8462)
## Summary At startup and on every community switch, the channel list waits on a chain of relay reads, one round trip after another. Four of those reads need only the membership ids: channel metadata, hidden DMs, member snapshots and Huddle starts. Yet each one waited for the read before it. They now go out together, right after the membership list. Everything that depends on them is unchanged: DM participant names still follow metadata, and the latest-message batch still follows the filtered list. - `Future.wait(eagerError: true)` handles every request's failure and rethrows the first one unchanged, as soon as it happens. Before this change a failed read also stopped the chain. Hidden DMs and Huddle starts still fall back to empty on failure, as before. - The refresh fence checks the combined result once, before any state is written. That's the same fence check each read had before. This keeps the duplicate member-snapshot read. Replacing it with the membership list's events would need a relay-contract check first. ## Before and after Setup: - Simulator, debug build. - Local relay with about 120 ms of added round-trip time. - Seeded community with 120 channels. - 5 cold launches each, after one warm-up launch, on the same build with and without this change. - Timed with local probes that are not part of this PR. All 10 launches loaded 120 channels. | | `main` | this PR | |---|---|---| | Connected → channel list ready (median) | 1,233 ms | 715 ms | | Range | 1,154–1,297 ms | 689–747 ms | ## Test A test parks the metadata, hidden-DM and member-snapshot reads at the same time, then checks that all four reads were sent. If any read waits on another, it stays unsent and the test fails. It fails on `main`, where only metadata goes out, and on a version that sends metadata first and the rest after. Three switch tests park before discovery now, so their names say "during a directory refresh" instead of "after directory success". ## Validation - `flutter analyze` - Full mobile suite: 3,535 passed. - The simulator runs above. **Human test:** Wes ran #8456, #8460 and #8462 together on the simulator with his real account and confirmed they work. buzz-review-completed 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Wes
|
b6aa5539e3 |
feat(mobile): account onboarding, key recovery and hosted reconnect (#8375)
## Behavior Adds optional mobile Builderlab sign-in, identity backup/recovery, community discovery/creation, and account-aware reconnect. **Builderlab features are disabled by default:** when `BUZZ_AUTH_DOMAINS` is unset or empty, account login, creation, backup/recovery, reconnect prompts, and background account restoration are hidden/disabled. QR/code pairing, links, and invites retain Nostr-only entry. Saved account state is retained for later opt-in. `--dart-define=BUZZ_AUTH_DOMAINS=communities.buzz.xyz,communities.public.builderlabstaging.xyz` opts those DNS domains and their subdomains into required account setup. The same policy gates pairing, deep links, durable community admission, and reconnect. A nonempty list enables Builderlab features; `BUZZ_BUILDERLAB_URL` alone does not. Enabled flows still require their backend services. Existing Nostr relay authentication remains mandatory. `BUZZ_HOSTED_RELAY_AUTH=true` enables scoped relay assertions and reconnect prompts only for configured authentication domains. Configure assertion issuance and each community's issuer binding before enabling assertions; enable relay enforcement last. Account credentials stay at Builderlab. Wrong-account recovery preserves keys; failed writes are not replayed; authentication is bounded by request deadlines. Hosted flows preserve keys across cancellation/restart, reconcile interrupted creation/invitation acceptance, and support manual nsec file import/export. Account identities are scoped to backend and authenticated subject; reusing an existing local key for an unbound account requires an explicit selection. Recovery reconciles the advertised and recovered inventories before automatic selection. Successful self-hosted admission retires its pending key, and iOS startup removes interrupted export files. Adds authenticated relay `GET /operator/communities/joined` for the companion Builderlab membership endpoint. ## Validation - Follow-up review repair at `66a12ac92`: self-hosted entry presents readable choices and import despite incomplete enumeration, while generation still requires a complete empty inventory; explicit selection uses exact-key lookup. Consuming a value-equal duplicate now advances dispatch. Reconnect requires an existing account binding or a subject-scoped backup receipt before signing an assertion, and pins the subject inside the serialized account request. An empty different account is refused without sending key proof. Focused checks: configured domains 58 passed; default 49 passed, 9 hosted-only skips. Separate isolated mutations fail the incomplete-inventory sheet, exact-key reuse, duplicate dispatch and reconnect journeys (including an empty-account-only bypass); restored controls pass. Evidence uses synthetic storage/network boundaries, not physical Android or live backend association. All mandatory commit/push hooks passed; fresh GitHub CI is pending. - Bounded review repair at `d3cc0003f`: incomplete secure-storage enumeration now blocks automatic identity generation while explicit known-key reads retain their fallback; declined/failed onboarding links release the queue; HTTP 429/5xx keeps Retry regardless of response encoding. Default app-gate coverage exercises a bind link followed by ordinary community entry. Focused checks: configured domains 47 passed; default 38 passed, 9 hosted-only skips. Removing the three production fixes in an isolated source/Git/build copy fails the identity-resolution, declined/failed queue, and Retry journey assertions; clean and restored controls pass. Storage and HTTP failures are synthetic; physical Android and live outage behavior were not exercised. Published after all mandatory commit/push hooks passed (mobile analysis/tests, branch-skew and file-size gates); fresh GitHub CI remains pending. - Existing whole-PR source review cleared the reconnect defects at `fb15d5b82`. - Domain-policy increment: focused environment, entry, app-gate, pairing and onboarding journeys pass with empty and configured domains. Existing pairing provider/page tests pass. Changed Dart files analyze cleanly. - Isolated source/Git/build mutation: forcing paired credentials through hosted login fails the default-build journey; clean and restored controls pass. CI now runs configured-domain journeys in addition to the default-build suite. - Integrated main through `5b433d929` at `0067c069c`, including its pinned Flutter upgrade. Preserved the PR welcome UI with the updated transition API and added Material surfaces around onboarding selection/consent rows. Focused post-merge runs pass in both configurations; all mandatory local push gates passed (mobile analysis/tests, Rust tests, desktop-native checks, branch-skew and file-size checks). - Merge-review repair at `a315bce11`: focused identity/storage/admission and widget journeys pass, including account switching with an empty or already-bound second account, explicit reuse, and self-hosted removal/rejoin with another key. Default-domain journeys pass too (hosted-only cases intentionally skip there). - Isolated source/Git/build mutation checks: bypassing account scoping, reuse consent, pending-key retirement, or recovery inventory reconciliation fails the relevant journey/invariant assertions; clean and restored controls pass. - Native `RunnerTests/IdentityFilePluginTests`: both tests pass on the iPhone 18 Pro iOS 27 simulator with an isolated app identifier. At `24a0dcaac`, the picker journey seeds residue in Library/Caches, matching path_provider_foundation, and verifies plugin startup removes it while preserving an unrelated file. The earlier tmp-only fixture did not exercise the actual export location. This is synthetic native cleanup/picker evidence, not a real terminated-share or live account round trip. - Follow-up: Caches and tmp cleanup; fallback to individually known identity slots when Android bulk enumeration fails; explicit replacement of a refused self-hosted key preserves its original before swapping the retry slot. Configured-domain journeys/invariants: 34 passed; default: 31 passed, 3 hosted-only skips. Isolated enumeration/retry mutations fail with passing controls. Bulk-read fallback preserves but cannot enumerate arbitrary other-account slots until bulk reads recover. - Configured-domain CI exposed a stale pairing-status assertion after account scoping. The repaired test checks the admission mismatch, preserved account/transfer keys, and no admitted community. The configured-domain CI selection passes locally (56 tests); removing the production mismatch guard fails the updated test, with clean/restored controls passing. This is synthetic coordinator evidence, not physical QR acceptance. - Final review repair (`40e1e6101`): native iOS export creation uses atomic complete file protection; normal and restart cleanup remain. Account/policy/claim HTTP uses one 30-second total deadline with request abort and body cancellation. Removed the unrelated NIP-FA spec edit. - Focused account/admission/export tests: 25 pass; configured-domain account/admission/onboarding journeys: 33 pass. Isolated deadline and native-dispatch mutations fail, with passing clean/restored controls. Native export/picker tests: 2 pass on iOS 27 simulator. The real file-protection attribute assertion is physical-device-only because simulator provides no Data Protection attribute; locked-device protection and interrupted real sharing have not been observed. - Opt-in UI: configured-domain CI selection passes (57 tests); default selection passes (7 tests, 10 hosted-only skips); URL-only plus whitespace/empty domains passes (6 tests, 9 hosted-only skips). Changed Dart files analyze cleanly. Independent mutations that unconditionally initialize the coordinator in the app gate, welcome entry, or link form fail the default journey; clean/restored controls pass. - Native welcome screens exercised on iPhone 18 Pro / iOS 27 simulator in default and configured builds: default exposes community link / QR / pairing code only; configured build additionally exposes Builderlab connection and community creation. No live hosted login was exercised in this check. - Delivery at `e48fe73a9`: all mandatory push hooks passed (full mobile analysis/tests, Rust tests, desktop-native checks, branch and file-size checks). GitHub checks had not yet populated at the immediate post-push snapshot. ## Review disposition | Feedback | Disposition | | --- | --- | | Explicit self-hosted entry under unreadable inventory, duplicate invite dispatch, reconnect cross-account binding ([entry](https://github.com/block/buzz/pull/8375#discussion_r4318421622), [queue](https://github.com/block/buzz/pull/8375#discussion_r4318421640), [reconnect](https://github.com/block/buzz/pull/8375#discussion_r4318455512)) | Repaired at `66a12ac92`; evidence above. Reconnect refuses unproven ownership rather than silently establishing a binding. | | Incomplete Android identity inventory, stranded deep-link queue, transient HTTP retry classification ([review](https://github.com/block/buzz/pull/8375#pullrequestreview-5576864143)) | All three repaired in `d3cc0003f`; focused journeys and isolated mutation evidence above. | | Account cross-link, incomplete recovery inventory, committed invite checkpoint, pending local key retirement/replacement | Repaired in the preceding commits; journey and mutation evidence above. | | iOS interrupted key export ([review](https://github.com/block/buzz/pull/8375#pullrequestreview-5575253252)) | Native cleanup plus complete protection at creation implemented. Physical-device lock and real interrupted sharing acceptance remains pending. | | Trickle responses bypass idle timeout; unrelated NIP-FA edit ([review](https://github.com/block/buzz/pull/8375#pullrequestreview-5575764556)) | Total request deadline/abort implemented; spec edit removed. | | Production domains rejected | Ordinary entry now needs no Builderlab configuration. Opt-in account-required domains must still use supported community mappings. | | Lost Android Keystore recovery | Backup exclusions prevent the reviewed stale-restore scenario; genuine key loss still has no in-app recovery/reset and remains deferred. | | Native secp256k1 dependency question | Obsolete against the current base: upstream C integration landed in #8398; no package diff remains here. | | Operator membership endpoint contract | Documentation now states the operator chooses the pubkey; no end-user session binding is implied. Additional handler-level coverage is optional follow-up. | | Optional Android partial document cleanup/activity retention; local work after backup cancellation | Follow-up hardening, not claimed implemented. Cancellation prevents remote backup upload. | | Semgrep crypto inventory notices | Informational inventory, not demonstrated defects. | ## Remaining draft gates Native QR/browser-return acceptance remains unverified for this revision. Optional Builderlab onboarding still needs backend backup-status and joined-community routes, recovery policy/configuration, and real backup/recovery/reconnect acceptance. The empty-domain build removes these services as prerequisites for ordinary pairing; it does not make the optional hosted flows backend-ready. Human acceptance and current CI are still required before merge. Review dispositions retained: production auth-domain configuration must use supported community mappings; enabling `builderlab.xyz` does not add support for `buzz.block.builderlab.xyz`. Recovery after genuinely losing an Android Keystore key remains a follow-up, not a newly implemented capability. Human acceptance steps: build once without `BUZZ_AUTH_DOMAINS` (including with a previously saved account) and confirm no Builderlab controls/restoration while ordinary link and QR/code entry work. Build with supported domains and confirm connection/creation appear; exercise browser return and live backup/recovery/reconnect. On physical iOS, exercise export and interrupted sharing/locked-device protection. Record results before marking review complete. --------- Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Brain <1a02c72794dcd0f07058a353bc3a81f4028b8c77c92c87fce6d5c8b85970a20b@buzz.block.builderlab.xyz> Co-authored-by: Brain <1a02c72794dcd0f07058a353bc3a81f4028b8c77c92c87fce6d5c8b85970a20b@wes.communities.public.builderlabstaging.xyz> |
||
|
klopez4212
|
bbb5183f33 |
feat(mobile): add swipe-to-reply message gesture (#8436)
## Summary Swipe right on channel and thread messages to open the existing reply destination. Adds a centred accent progress ring, Reply label, threshold haptic/pulse, drag resistance, cancellation, and reduced-motion support. Retreating below readiness re-arms feedback. Includes a separate formatting-only fix required by main’s updated Dart formatter. ### Related issue Related message styling: #8281. No matching swipe-to-reply issue found. ### Testing - Full pre-push checks passed, including mobile analysis/tests and file-size checks. - Widget coverage: routing, repeated threshold crossings, cancellation, resistance, alignment, and centred scaling. - Release preview installed on iPhone with the existing profile/community; Kenny tested and confirmed the interaction. Draft: native preview verification predates the rebase onto main’s Flutter upgrade. No native gesture recording attached. --------- Signed-off-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Tom Brow
|
819dd7924f |
fix(mobile): bump Flutter 3.47, resolving memory leak (#8419)
With accessibility semantics active, opening and leaving channels
retained disposed composer overlay states through Flutter’s semantics
traversal map. Those states kept departed route and message trees alive.
This upgrades the pinned Flutter SDK from 3.41.7 to 3.47.7, which
includes [the upstream
fix](
|
||
|
klopez4212
|
27b9c827fc |
Polish mobile message layout and navigation controls (#8427)
Align outgoing messages and galleries to the right, reclaim the outgoing avatar gutter, and match desktop calendar dividers with balanced spacing. Standardize navigation and sheet icons at 24 points, restore native Edit/Done styling, and align section menus with trailing channel indicators. Validation: clean analysis; 3,513 mobile tests and push-configuration checks passed; iPhone Release build installed and tested by the owner. Includes regression coverage for message placement, date spacing, gallery direction, and section alignment. --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: fin <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
klopez4212
|
3a45e87b25 |
fix(mobile): polish Inbox controls and system notices (#8423)
Use Tabler `filter-2` in Inbox and keep the iOS filter button rounded when its menu closes. Remove shaded containers from chat system notices while preserving spacing, profile links, and reactions. Validation: mobile formatting, analysis, full test suite, and iOS Release build; independent review found no blockers. Kenny verified the icon and menu dismissal on his iPhone. --------- Signed-off-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
klopez4212
|
c8ea4fb4eb |
feat(mobile): polish Home navigation and Solo workspace (#8393)
## Summary Polish mobile Home and Solo: group Search/Inbox beside a separate profile avatar, move Inbox and Settings to bottom-up pages with Close controls, and place tabs opposite the plus/compose action. Morph plus to compose clockwise when entering Solo and reverse counterclockwise when returning Home, with a directional quarter-turn of the icon inside a level button and a subtle scale pulse, respecting reduced motion. Align Search’s Close control with Inbox, simplify its placeholder, and initialize selected filter contrast correctly. Collapse the plus menu when leaving Home. Center Solo’s native-glass New chat empty state and keep it stationary behind the keyboard. Standardize Tabler icons and neutral backgrounds, retain SF Back/Close on iOS, use native Liquid Glass headers, tab container, and actions (solid grey selected tab, slightly darker on iOS) on iOS and black actions on Android, and smooth the expanded menu corners. Repair native header safe-area/return layout and compose movement after cancellation. ### Related issue None found for this UI refinement; follows #8337. ### Testing - Formatting, analysis, full mobile suite: 3,487 passed, 4 skipped; 3 push-configuration tests passed. File-size checks passed. - Base UI built and installed on Pixel and iPhone in place. Pixel navigation/New chat cancellation checked. Subsequent glass and rotation refinements are previewed on iPhone; motion feel awaits human confirmation. - Draft pending human confirmation of the final Settings entrance/return behavior on iPhone. ### Pixel snapshots | Solo | Expanded actions | | --- | --- | | <img src="https://raw.githubusercontent.com/block/buzz/16dc0f8af971e63d788fee20974997fab925dec9/docs/screenshots/mobile-home-solo/pixel-solo.png" width="280" alt="Solo empty state with New chat" /> | <img src="https://raw.githubusercontent.com/block/buzz/16dc0f8af971e63d788fee20974997fab925dec9/docs/screenshots/mobile-home-solo/pixel-actions.png" width="280" alt="Expanded channel actions with smooth corners" /> | --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> |
||
|
Logan Johnson
|
93ffc37cbd |
feat(mobile): find people by name through the relay's name-only profile search (#8333)
🤖 ## Summary In the mobile app, searching for "wes" did not find Wes. People search matched text anywhere in a profile, including the image data of a shared default avatar. Many agent profiles use that avatar, so they filled the results and the real Wes never appeared. Now every people search in the app uses the relay's new name search: the Search page, adding channel members, new messages, and @mention suggestions. It matches only a profile's name and display name and puts exact names first. The desktop app (block/buzz-app#1084), agent tools (block/buzz-app#1124) and the CLI (#8331) make the same change. Compatibility: a relay without the new search answers 404 or 405. That search uses the old search, and so do later searches on the same relay for five minutes; then the app tries the new search again, so a relay that is upgraded while the app runs is used soon after. A query or result count that the new search cannot take also uses the old search. Other errors are shown as before. Order: search results keep the relay's ranking, so "Wes" comes before "Abe Wes". Before, the Search page and the member and new-message pickers sorted results by name. The list with no query is still alphabetical. Each screen still applies its own filters. Not in scope: the community invite screen accepts only an npub and has no name search, so this PR does not change it. ### Related issue Relay endpoint: #8301. This PR does not depend on it; either can merge first. ### Testing - Relay session tests: the name query goes to the new search with a signed request; a 404 falls back and stays on the old search until the retry time; a 405 falls back; other errors do not fall back; an unsupported result count uses the old search. - Updated tests for add members and @mention search, and a test that search results keep the relay's order while the browse list stays alphabetical. - `just mobile-check` and the relay, channel, mention, invite and search tests (1,962) pass. - No screenshots: results look the same; only which people are found changes. --------- Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> |
||
|
Wes
|
66d5354586 |
fix(mobile): split channel history batches at the relay channel cap (#8342)
## Problem The relay rejects any request that names more than 128 explicit channels in aggregate (`MAX_EXPLICIT_CHANNEL_VALUES`, `crates/buzz-relay/src/handlers/req.rs`). Mobile sent every active channel in one batch: - **Latest-message and unread catch-up batches** were rejected with `400 too many explicit channels` and fell back to websocket requests four at a time. For 144 active channels that took about 5 s each. - **The Huddle backing-channel query** (one filter with every membership) was closed as `restricted: too many explicit channels` and returned no results, so that visibility filter was effectively disabled. On a first pairing with a large community, these serialized fallbacks consumed most of the community switcher's 20 s landing budget. That's one cause of "This community is taking longer to load." ## Change - `_fetchChannelHistoryBatch` splits filters into requests whose combined `#h` values stay within `kMaxExplicitChannelValues`, four at a time. A deadline in any request still makes the whole batch unavailable. Requests that fail for other reasons are collected, and one websocket fallback runs over their filters after every request settles, so a batch never has more than four relay requests in flight. - `_fetchHuddleStarts` splits its parent channel IDs into REQs within the same cap, also four at a time. ## Evidence iPhone 18 Pro simulator (iOS 27, debug build) on a community with 411 memberships and 144 active channels, with temporary stage timing that is not part of this PR. Eight cold launches before and after: | Median since app start | Before | After | | --- | --- | --- | | Channel rows painted | 8.3 s | 4.0 s | | Unread catch-up complete | 14.4 s | 5.1 s | The Huddle query now returns successfully instead of being closed. ## Tests The fake relay session now rejects over-cap requests the way the relay does, and answers Huddle starts only for the requested parent channels. - `channel batches stay within the relay explicit-channel cap` (129 channels): every history batch and Huddle filter is within the cap, and a Huddle backing channel in the over-cap tail stays hidden. Fails when either split is removed. - `channel batches keep four relay requests in flight` (513 channels, query bridge down): peak in-flight requests are 4 for latest-message, unread catch-up and Huddle, and the fallback covers every channel. The previous version of this branch measured 16, 16 and 5. - Full mobile suite via the pre-push hook (`just mobile-check && just mobile-test`): passes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
klopez4212
|
b1d60f98e2 |
Bring synced Solo chats and projects to mobile (#8337)
## Summary Bring desktop Solo chats and project organization to mobile, with synced collapsible sections, shared unread highlights and tab badges, agent selection, shared search, native iOS creation sheets, and inline typing bubbles that transition into replies. Resolve Solo placement for every chat entry route, retain encrypted organization snapshots for offline reading, and let users resume or discard unfinished chat and project setup without deleting existing messages. ### Related issue Related: #6565; expandable agent transcripts remain separate work. ### Testing - Fresh Solo read state seeds each active chat from its captured initial last-message timestamp before exposing row/section/tab unread state. Baselines survive intervening channel updates and reset across identity/community boundaries while surviving read-state readiness changes. Regressions cover multiple chats, events before read-state readiness and during/after seeding, and identity changes; removing either the seed or the display gate fails them. - Chat completion reconciles a retained Solo-save journal even when placement is already confirmed. False/throwing cleanup regressions ensure the outer intent remains until reconciliation and only one placement is published. Typing terminal-close loops remain bounded; the retry budget resets after an uninterrupted eight-second health interval or transport reconnect. - Typing retry budgets reset after sustained recovery; invalid Solo updates retain cached rows with a retry warning that survives failed refreshes. Project names use the editors’ 120-grapheme limit, including emoji and combining characters. Regression coverage exercises repeated recovery, invalid live/refresh heads, and character-limit boundaries. - Rebased onto current main, preserving the newer Search controls, Huddle timeline filtering, and message-media layout. - Failed project journal writes reload storage before claiming recovery and reopen the entered name for retry. Typing subscription rejections are caught; terminal closures clear stale indicators and retry with a bounded backoff, canceled on disposal. Regression tests cover both false/throwing storage writes and initial/late subscription rejection. - Explicit ordinary destinations skip optional Solo lookup waits. Generic destinations perform one bounded lookup in the destination (search no longer duplicates it); an unavailable classification falls back to ordinary sending per the product owner's explicit choice. Positively identified Solo destinations use Solo providers. - Terminal Solo subscription closure preserves cached rows and exposes live-update Retry. Page coverage verifies warning visibility, usable rows during recovery, and a subsequent terminal close. Removing the warning or the immediate ordinary-route guard fails its regression. - Generic channel entries share an ordinary default when Solo classification is unavailable, per the requested product behavior. Known Solo placement takes precedence; callers can explicitly require unresolved placement to remain blocked. Bounded initial lookup preserves known Solo deep-link routing. - Dirty newest snapshots and offline-save warnings survive transport reconnects; Retry persists that same event even if the relay returns an older head. Community changes replace the service, and agent-directory reconnect refresh remains intact. - Pending-save discard reloads failed removals. Repeated reconnect testing confirms typing subscriptions are released on provider rebuild and disposal; removing the existing cleanup fails the regression. - Ordinary Home/create routes explicitly preserve private-channel sending during Solo failures; identified Solo sends use the Solo sender and explicit unresolved routes remain fail-closed. Solo unread replies beyond the initial 200-event page are loaded through the oldest-unread boundary. - Chat/project/agent cleanup reloads failed removals, retains same-process recovery, and protects replaced records. False/throw regressions verify retries do not duplicate creation or membership. Route, unread, and cleanup guard-removal mutations each fail their regression. - Ordinary channels, DMs, and forums remain sendable when optional Solo sync fails; explicit unresolved placement stays blocked. Controlled cache races retain the newest verified snapshot, keep usable chats visible, and retry offline persistence without stale writes. Both protection-removal regressions fail as expected. - Confirmed journal cleanup checks false/throwing removal and exact-record identity. Interrupted agent choices are visible immediately, identify the saved agent, and cover Resume/Later/Discard with accessible name/key-fallback controls. - Notification deep links preserve the contiguous history cursor; same-second messages infer the newest agent consistently. Failed offline-cache writes surface Retry, with false/throwing storage failures and offline restart covered. - Composite history cursors cover 350 same-second events plus older history; removing the ID cursor makes the regression fail. Agent changes now journal before granting access, with restart/failure and Resume/Later/Discard widget coverage. Signed malformed profiles remain isolated. - Native iOS avatar tests passed on the simulator: visible-row loading, three-request concurrency, streamed byte limits, response validation, downsampling/pixel limits, cancellation, and visible avatar updates. - Solo and Home share observed-event/read-marker logic. Widget coverage verifies unread rows, collapsed-section indicators, the tab badge before first Solo visit, message/thread reads, forced unread, and filtering archived/nonmember/unplaced chats. - Chat intent is saved before ownership and organization preflight; tests cover interrupted ownership lookup and a disconnect while the native creation form is open. - Mobile analysis, formatting, file-size checks, and full mobile tests passed at `1d4c41354`. - Project creation persists its encrypted name/UUID before connectivity checks or relay reads. Restart tests cover Resume/Later/Discard, scope isolation, stale-intent rejection, and lost acknowledgements. Removing the pre-network save makes all four production-flow regressions fail. - Regression coverage includes notification/Activity routing, inline replies, unknown-placement send protection, restart recovery/discard, and encrypted offline cache isolation/refresh. - Earlier feature build exercised on a physical iPhone with existing account/community data; review follow-ups have not been reinstalled on the device. UIKit agent-row accessibility checks passed on an iOS simulator. - Earlier cross-platform `just ci` stopped on the existing `buzz-acp` test `signals_cancel_startup_turn_and_pending_stdin_without_hanging` (process exit-code assertion); no Rust production changes are included in this PR. ### Remaining review limitation Agent discovery is bounded to 10 pages / 1,000 profiles with automatic retries disabled. Owner-scoped discovery remains open because the current relay ignores `#auth` filters; supporting that query requires a relay change. ### Snapshots Sample data, shared Flutter/Android surface. Native iOS uses platform sheets and controls. | Solo: projects and chats | New chat | Choose an agent | | --- | --- | --- | | <img src="https://raw.githubusercontent.com/block/buzz/d9b29aa079a3b9a88e8ed89b70df8d6af06fa41b/pr-8337--01-solo.png" width="240" alt="Solo with collapsible projects and chats" /> | <img src="https://raw.githubusercontent.com/block/buzz/d9b29aa079a3b9a88e8ed89b70df8d6af06fa41b/pr-8337--02-new-chat.png" width="240" alt="New chat form" /> | <img src="https://raw.githubusercontent.com/block/buzz/d9b29aa079a3b9a88e8ed89b70df8d6af06fa41b/pr-8337--03-agent-picker.png" width="240" alt="Agent selection list" /> | --------- Signed-off-by: kenny lopez <klopez4212@gmail.com> Signed-off-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Terp <5856f6900e8e0a4e0ea1f4f8d2ee33e4753d2119bc122f94ecafc660b46c0511@buzz.block.builderlab.xyz> Co-authored-by: Logan Johnson <loganj@squareup.com> Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz> |
