[GreyforgeLabs]

Searching a group conversation can hide a real reply: an outgoing "yes" and another member's "yes" in the same second collapse to one hit because search's echo key omits the sender. Search also keeps whichever self-echo row arrives first, so your own message can appear as incoming.

Use the existing dedupeSelfEcho() shared by the collector and thread loader before search discards empty bodies. This preserves distinct group senders, makes self-echo direction independent of row order, and lets an empty outgoing row identify its decoded incoming twin. Ranking and limits stay in the search layer; message text stays in memory and travels to the bridge on stdin.

Validation:

• All four new regressions fail against unchanged upstream and pass with the fix, including the injected-runner search path.
• bun test: 676 pass, zero failures.
• Repository's offscreen QML badge check, OTP adapter, Mac Python checks, shell syntax checks, and ShellCheck all pass locally.
• Synthetic data only; no real conversations read or messages sent. No QML changes.

[nixfred]

Merged in 584aa07, thank you, and welcome to Blip. This was a good catch: search kept its own echo key with no sender in it, so a "yes" from me and a "yes" from someone else in the same second quietly became one hit. Reusing dedupeSelfEcho() instead of patching the key is the right fix, since search now follows the same rules as the conversation view and cannot drift from it again.

What I checked before merging:

• All four of your new tests fail against the old search.ts and pass with the change, as you said. Full suite green.
• Ran old and new shaping side by side on live rows from the Mac (four queries, 400 rows each, comparing metadata only). Every difference was in the self-thread. Hits in every other conversation were identical.

That comparison turned up one more thing, which is not a fault in your PR. My self-thread holds 3 or 4 incoming copies of each note (same second, same text, apparently iCloud re-sync). imsg search answers newest first, and dedupeSelfEcho folds a copy only into a row of the opposite direction, so two incoming copies ahead of the sent row left one behind as an incoming hit. fc2ddce applies your idea one step further: search hands outgoing rows to the dedupe first. For the query "test" here that is 340 hits on old main, 286 with your change, 196 with both, and the hits outside the self-thread do not move.

One small thing: I thank contributors by name in a weekly post on X. Your GitHub profile lists @GreyforgeLabs, so I will tag that unless you would rather not be tagged, which is an equally good answer.