Direct Messages parity gaps

[Adron]

Where this stands

:feature:directmessages is in good shape — inbox with cursor paging, send, thread by username,
/updates polling, read, trash, restore, recipients and image upload, with an unread badge. It is
one of the more complete modules in the app.

Gaps

• GET /api/dm/conversations is unused — "One row per conversation (grouped by pairKey),
  newest activity first." The inbox is currently built from GET /api/dm, which is a message
  list, not a conversation list. On the web the user sees conversations; on Android they see
  messages.
• /help/direct-messages documents who you can message — recipients are constrained (the
  test account can DM only a mutual follow). Android surfaces the recipient list but not the
  rule, so an empty picker looks like a bug.

---

Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

[Adron]

Both sub-issues are done, so closing this epic.

• DMs: build the inbox from GET /api/dm/conversations #85 — inbox rebuilt on GET /api/dm/conversations → feat(dm): build the inbox from GET /api/dm/conversations (#85) #90
• DMs: explain who can be messaged when the recipient list is empty #86 — mutual-follow rule explained when the recipient list is empty → feat(dm): explain the mutual-follow rule when the recipient list is empty (#86) #95

Review continues on those two PRs. Two things surfaced that are worth recording against the epic rather than losing:

GET /api/dm/conversations is undocumented. It is a bare object in the OpenAPI spec and absent from /help/api/direct-messages entirely, and the test account has no conversations, so the live response was { "items": [], "nextCursor": null } — the envelope is confirmed but the row shape is still inferred. The DTO accepts the participant under otherUser/user/author and the newest message either nested or flattened. One authenticated curl from an account that actually has conversations would let it be trimmed to the real shape.

A latent bug was fixed along the way: POST /api/dm returns { "message": { … } }, which the app never unwrapped, so a sent message kept its optimistic local-… id and any later read/trash on it would have 404'd.