Fix DM persistence + bidirectional DM history ordering

[khaliqgant]

Summary

• persist per-participant copies for dm:* channel messages in router storage path (including sender self-copy)
• keep existing channel-level persistence for channel views
• update SQLite getMessages() so { from, to } queries match both directions and return chronological results
• add tests for DM participant persistence and bidirectional DM query behavior

Why

Dashboard DM history needed sender-visible persistence plus stable server-side conversation retrieval.

Validation

• npm test -- sqlite-adapter.test.ts (packages/storage)
• npm test -- router.test.ts (packages/daemon)

Coordination

• Pairs with dashboard/client fix in fix: sort messages by timestamp after WebSocket append relay-dashboard#30

---

[devin-ai-integration]

Devin Review found 3 potential issues.

[khaliqgant]

Addressed Devin feedback in latest commit (1b2df27):

• Made bidirectional query behavior opt-in via MessageQuery.bidirectional (no longer implicit whenever from+to are present).
• Updated all storage adapters (SQLite, JSONL, Memory) to use the same bidirectional semantics for consistency.
• Preserved caller-requested sort order (no forced ASC override).
• Updated daemon MESSAGES_QUERY caller to explicitly opt in with bidirectional: Boolean(from && to), leaving INBOX directional behavior unchanged.
• Added/updated adapter tests for one-way vs bidirectional queries and asc/desc ordering behavior.

Validation run:

• npm test -- sqlite-adapter.test.ts
• npm test -- jsonl-adapter.test.ts
• npm test -- memory-adapter.test.ts
• npm test -- router.test.ts
• npm run build (storage + daemon)

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 MESSAGES_QUERY unconditionally forces bidirectional mode, breaking existing unidirectional from+to queries

In the MESSAGES_QUERY handler, bidirectional is unconditionally set to true whenever both from and to are provided: bidirectional: Boolean(queryPayload.from && queryPayload.to). This changes the semantics of all existing queries that specify both fields.

Root Cause and Impact

Previously, queryMessages({ from: 'Alice', to: 'Bob' }) returned only messages sent from Alice to Bob. After this change, it also returns messages from Bob to Alice.

The MessagesQueryPayload type at packages/protocol/src/types.ts:677 does not expose a bidirectional field, so clients have no way to opt out of this behavior. Every caller that provides both from and to is affected:

• The MCP tool at packages/mcp/src/tools/relay-messages.ts:38-45 passes user-supplied from and to directly. A query like "show me messages from Alice to Bob" would now also return messages from Bob to Alice, which is semantically incorrect for that use case.
• The SDK queryMessages method at packages/sdk/src/client.ts:1451 also passes both fields through.

The bidirectional flag was correctly added to the MessageQuery interface (packages/storage/src/adapter.ts:52-53) as an opt-in field, but the server forces it on for all queries. The fix should either: (a) let the client control this via a bidirectional field in MessagesQueryPayload, or (b) only enable it for DM-specific query paths rather than all MESSAGES_QUERY requests.

Prompt for agents

The bidirectional flag should not be unconditionally forced for all MESSAGES_QUERY requests. Two options:

1. (Preferred) Add a `bidirectional?: boolean` field to `MessagesQueryPayload` in packages/protocol/src/types.ts (around line 689), then in packages/daemon/src/server.ts line 1468, use `bidirectional: queryPayload.bidirectional ?? false` instead of `Boolean(queryPayload.from && queryPayload.to)`. This lets clients opt in to bidirectional queries.

2. (Quick fix) Change line 1468 in packages/daemon/src/server.ts to only pass `bidirectional: false` (or remove it entirely), and let the dashboard client explicitly request bidirectional mode when it needs DM conversation history.

---

Was this helpful? React with 👍 or 👎 to provide feedback.