🤖
## Summary
In a channel conversation, two identities with the same display name
looked identical. In the example below, the channel shows "Bad Janet"
twice, for two different identities. A reader cannot tell which one was
added and then removed.
This PR uses the contextual names from the previous PR everywhere a
conversation names someone:
- Message authors, threads, forum posts and replies
- Reactions, the typing indicator, and system rows (joined, added,
removed)
- Inline mentions and the agent activity sheet
- The profile sheet title, which now matches the row that opened it
Names are compared against the channel's members, so a label only gets
longer when a real collision exists in that channel.
The mention picker labels each choice against every candidate, so two
"Honey" choices look different. When you pick one, it still inserts the
identity's own name ("@Honey"), so the message text does not change.
Part 2 of 3: #7894 (resolver) → #7895 (conversations) → #7896 (lists,
Search, Pulse).
### Related issue
Related to #2910.
### Testing
- A widget test checks that the profile sheet names an author the same
way the channel does.
- A unit test checks that two same-name mention choices get different
labels but insert the same wire name.
- `flutter analyze` is clean, and the full `flutter test` suite passes.
- Checked on an Android emulator against the live relay, in an archived
channel with two identities named "Bad Janet".
| Before | After |
| --- | --- |
| <img width="300" alt="Before: the channel shows two different
identities both as Bad Janet"
src="https://github.com/user-attachments/assets/c7f6c345-12d8-4e11-9434-bbd2c63722db"
/> | <img width="300" alt="After: the second identity shows as Bad Janet
· sqxl"
src="https://github.com/user-attachments/assets/51c6b9fc-8900-4200-8ce0-ad1887f41dba"
/> |
---------
Signed-off-by: Logan Johnson <loganj@squareup.com>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
When a channel screen updates, Buzz Mobile can parse and format a
message again even when its text has not changed. This repeated work
runs on the same thread that handles taps and updates the screen.
The current Markdown library, `gpt_markdown` 1.2.1, checks whether the
objects used to render mentions, emoji, and channel links have changed.
Buzz creates new objects on every message rebuild, so the library parses
the message again. This change reuses those objects while their inputs
stay the same. Changes to labels, mention targets, emoji, media details,
or available actions still update the message. Taps continue to use the
latest action handlers.
In a synthetic test with the production message widget, ten unchanged
rebuilds caused 30 parser calls before this change and zero after it.
The first render still requires parsing. This test measures repeated
parsing, not overall screen speed.
Validation:
- All 91 focused message tests and 2,127 mobile tests passed. The new
regression test fails with the original code. Tests also cover changed
message data and current tap actions.
- Static checks across the repository, desktop and Tauri tests, and
desktop and web builds passed. The full local test run hit an existing
Rust ACP keepalive timing failure. Its exact retry passed, and all
checks skipped after that failure were run separately and passed.
Signed-off-by: Tom Brow <tomb@block.xyz>
