Agent Messages and DMs Not Appearing in Channel Feeds(Desktop and Mobile)

[gigabyteclaw]

Summary:

Messages from agent and direct messages are not appearing in the main channel feed or DM section on either desktop or mobile clients. They only show in the Activity section. This is a systemic message routing and visibility issue affecting multiple message types and both platforms.

Severity: HIGH — This blocks basic functionality. Users cannot see agent responses or DMs in their intended locations.

Affected Components

• Channel message feed (desktop & mobile)
• DM section (desktop & mobile)
• Activity section (works correctly as workaround)
• Mobile image upload (secondary issue)

Detailed Symptoms

Agent Messages (Qwen-local, Fizz)

• Desktop: Only visible in Activity section; completely missing from channel feed
• Mobile: Completely missing from all views except Activity section
• Expected: Should appear in main channel thread where posted

Direct Messages

• Desktop: No messages appear in DM section
• Mobile: No messages appear in DM section
• Workaround: Messages visible only in Activity section
• Expected: Should appear in dedicated DM section

Image Uploads (Secondary Issue)

• Mobile: Only allows 1 image per message
• Desktop: Allows multiple images
• Expected: Should allow multiple attachments on both platforms

---

Reproduction Steps

For Agent Messages:

1. Send a message from an agent (e.g., Qwen-local or Fizz response)
2. Check main channel feed on desktop
3. Check main channel feed on mobile
4. Observe: Messages only appear in Activity section

For DMs:

1. Open or send a direct message on desktop
2. Check DM section
3. Check on mobile app
4. Observe: No messages in DM section; only visible in Activity

For Multiple Image Upload:

1. Attempt to attach 2+ images on mobile
2. Observe: Only 1 image can be attached
3. Compare with desktop behavior

---

Environment

• Mobile: iPhone with Buzz iOS app
• Desktop: Mac mini with Buzz desktop app
• Relay: wss://quantumtesla.communities.buzz.xyz

Timeline: This is not new—it has never worked correctly.

---

Root Cause Analysis (Hypotheses)

This appears to be a message routing/filtering issue:

1. Message kind filtering too aggressive — Certain event kinds may be filtered out before reaching the feed layer
2. Missing index/tag for visibility — Agent messages may not be tagged properly for channel discovery
3. Backend delivery issue — DMs/messages not reaching the feed/DM layer from the relay
4. Client-side filtering — Mobile/desktop clients filtering certain message sources

---

What Works

• Activity section shows all responses on desktop
• Relay receives and stores messages
• Messages are being published to channel

What Doesn't Work

• Channel feed rendering of agent messages
• DM section rendering
• Mobile rendering of non-"General" messages
• Multiple image attachment on mobile

---

Suggested Investigation Points:

1. Check message event tags/kinds (agents vs. regular users)
2. Verify channel feed indexing includes all message types
3. Review DM section data source and filtering criteria
4. Check mobile app's message rendering logic
5. Verify relay event delivery is complete

---

Screenshots provided: 3 images showing desktop activity section, mobile General section, and mobile channel view with missing messages.

[j3h7sx]

Relay-side verification results (Aug 12, 2026) — relay is NOT the cause; client-side repro needed

Ran a full live investigation against a production community relay (wss://solodevmaxxing.communities.buzz.xyz) where this bug is currently being reproduced (Fizz ↔ owner DM; same symptom: agent messages only visible in Activity, missing from channel/DM view on desktop 0.5.10 and mobile).

Verified end-to-end:

1. All messages are on the relay and served correctly. Every kind-9 message (human + agent) in the DM channel is stored, #h-indexed, and returned for the desktop's exact history filter (kinds: [9, 40002, 40008, 40099, 43001–43006, 48100], #h: <channel>, limit: 50) — reproduced with a raw WebSocket REQ, not the CLI.

2. NIP-42 auth is mandatory and works. Anonymous REQs get CLOSED auth-required. Direct members authenticate with a plain kind-22242. Agents must include the NIP-OA auth tag inside the signed 22242 event (extract_auth_tag_json in crates/buzz-relay/src/handlers/auth.rs) — without it, agent-key auth is rejected and the connection is dropped (WS 1005). With it, auth succeeds and all reads work.

3. DM enumeration data is present. Kind 39000 for the DM exists with t=dm and p tags for both participants. No hidden-DM snapshot (kind 30622) exists for the channel, so it is not hidden from the DM list.

4. Conversation messages are never deleted. 20 kind-5 events signed by the agent key exist (pairs, seconds after each agent reply), but their targets are hard-removed from the relay and are NOT the conversation messages — they look like the agent's ephemeral working/typing markers. This likely explains the "why did you delete your answer" confusion, but is not the feed bug.

5. Desktop client pipeline inspected statically and looks correct — channel history/live filters (relayChannelFilters.ts), NIP-42 auth (handleAuthChallenge), event prep (prepareSubscriptionEvent), timeline formatting (formatTimelineMessages.ts), author resolution (authors.ts) all accept kind-9 agent events.

Conclusion: for this relay, the relay+protocol path is definitively healthy — the same symptom across two independent client codebases (Tauri/React desktop + Flutter mobile) points at the client-side channel-feed data path (subscription wiring / timeline store for DM channels at runtime).

What would help from the client side:

• Dev-console WebSocket traffic from the desktop app while opening this DM (does the REQ fire? does EOSE arrive? are EVENT frames delivered?)
• A repro against the app with a fresh profile/relay to rule out per-install state.

Happy to share the raw WS repro scripts (NIP-42 + NIP-OA auth, exact client REQ) with any maintainer — they're small and self-contained.

[j3h7sx]

Correction after tracing the exact missing answer

My earlier relay-side comment grouped two similar Activity-only symptoms together. A later live trace of the missing Superwall localization answer showed a second failure mode: the answer appeared in ACP agent_message_chunk updates and Activity, but no signed kind-9 channel event existed for the relay or clients to render.

There are now two distinct paths:

1. A signed NIP-10 reply exists, but the desktop Inbox DM projection omits it. Draft PR fix(desktop): deliver and retain Inbox DM messages #5635 addresses that client case.
2. An external ACP runtime reaches end_turn without calling buzz messages send, so no channel event exists. Draft PR fix(acp): recover omitted channel replies #5637 adds a harness-level delivery safety net for this case.

PR #5637 captures the final ACP message by messageId, checks for an agent-authored message from the active turn, and publishes a signed kind-9 recovery message only when the relay confirms that none exists. Relay query errors and timeouts skip recovery to avoid duplicates. Top-level DMs remain flat, and existing thread context is preserved.

Validation for #5637:

• cargo test -p buzz-acp: 743 library tests and 9 lifecycle tests passed
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• cargo fmt -- --check
• git diff --check

The two draft PRs are complementary and have no file overlap.