Backend asks blocking iOS parity — A8, A9, A11, A12 (+ A10 docs) #66

Activity

1. Adron

   added

   parityWeb feature-parity workWeb feature-parity work

   backend-askNeeds a change in the interlinedlist backendNeeds a change in the interlinedlist backend

   on Sep 7, 2026
2. Adron

   added a commit that references this issue on Sep 14, 2026

   docs: mark G15/G16/G18 shipped and point open work at epic #44

   ...

   9bbbc16
3. Adron commented on Sep 15, 2026

   

   Adron

   on Sep 15, 2026

   MemberAuthor

   More actions

   Status re-verified against the backend working tree — 2026-09-15

   Ask	Status	Evidence
   A8 — Bearer on the profile-wall messages route	✅ Done	app/api/user/[username]/messages/route.ts:3,23 now imports and calls getCurrentUserOrSyncToken.
   A9 — Bearer on invite acceptance	✅ Done	Both app/api/lists/invite/[token]/route.ts:3,52,83 and app/api/documents/invite/[token]/route.ts:3,52,83 use getCurrentUserOrSyncToken.
   A11 — documents shared-with-me route	❌ Outstanding	No shared-with-me route exists; app/api/documents/shared is shared/[token] (share-link resolution), and app/api/documents/route.ts has no scope handling. getSharedDocuments is still only called from app/documents/layout.tsx:22. This continues to block #54.
   A12 — /help/api/* docs for six routes	❌ Outstanding	Not checked in detail; no reason to believe it changed.
   A10 — AI docs still describe BYO-key	❌ Outstanding	Docs-only.

   Consequence for iOS

   • A8 landing means the dugByMe flip between the feed and a profile wall should be gone — worth a
     confirmation pass on iOS, but no client change is required.
   • A9 landing means an invited iOS user can now accept in-app. Nothing on iOS consumes this yet;
     worth a follow-up issue to wire invite acceptance into the deep-link path rather than bouncing to
     the web.
   • A11 still blocks W5: "Shared with me" documents (needs a backend route — A11) #54.

   New backend ask discovered since this issue was filed

   • Bug: editing a message does nothing — PATCH /api/messages/{id} is the reschedule route, not an edit route #76 — there is no route that edits a message's content. PATCH /api/messages/{id} is the
     reschedule route; iOS EditMessageView cannot work against it.
   • Backend: POST /api/user/change-email/request never verifies the password iOS sends #78 — POST /api/user/change-email/request accepts a password and never verifies it.
4. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   Remaining asks are backend-repo work — here is exactly what's needed for each

   A8 and A9 are done (verified 2026-09-15). The three that remain all land in
   ~/Codez/interlinedlist, not here, so I'm leaving them rather than opening cross-repo PRs. What each
   one needs to be actionable:

   A11 — GET /api/documents/shared-with-me 🔴 highest value, blocks #54

   Everything needed already exists server-side; this is plumbing, not design.
   getSharedDocuments(userId) (lib/documents/queries.ts:142) returns the exact shape, and
   app/documents/layout.tsx:22 already calls it — it just has no HTTP surface.

   • Route: app/api/documents/shared-with-me/route.ts (or ?scope=shared on the existing
     documents route — either is fine, the first is less likely to disturb the root-only listing).
   • Auth: getCurrentUserOrSyncToken, so Bearer clients work. This is the whole point of the ask.
   • Shape: { id, title, role, updatedAt, isPublic, owner } — whatever getSharedDocuments
     already emits, unchanged.
   • Open question: should it paginate? Lists' equivalent (GET /api/lists/watching) — does it
     page? If yes, match it; if no, don't invent a different convention.

   The iOS side is written up in #54 and can start the day this lands.

   A12 — /help/api/* pages for six routes 🟡

   /api/lists/watching, /api/lists/{id}/contributors, /api/dm/conversations, /api/limits,
   /api/messages/{id}/reply-counts, /api/organizations/{id}/users.

   reply-counts is the one that actually matters: the name reads like in-app reply counts, but it
   returns cross-post reply counts from Bluesky/Mastodon/LinkedIn/X. That misreading already made it
   into our own planning docs (work-consolidation.md recorded it as a feed perf item) and cost a
   re-scope. Worth a sentence on the page saying what it is not.

   Since #86 (dmConversations) and #84 (reply-counts) now have real iOS consumers, the request/response
   shapes in those PRs can be lifted straight into the docs.

   A10 — AI docs still describe BYO-key 🟡 docs only

   /help/ai and /help/api/ai-integration still say the user brings their own provider key. It
   shipped as a subscriber entitlement on the app's server-side key (lib/ai/resolve-provider.ts).

   • Question: are hasOpenaiApiKey / hasAnthropicApiKey / hasGeminiApiKey still returned by
     GET /api/user? They are not in userSelect (lib/auth/user-select.ts) — that file says the
     key columns were deliberately removed after issues #199/#206/#207. So the ask to "drop them from
     GET /api/user" appears already done; only the prose is stale. Worth confirming and striking
     that half of A10.

   Suggested split

   A11 is the only one gating iOS work. If it's useful I can draft the route in the backend repo as a
   separate PR — say the word and tell me the pagination answer above. A12 and A10 are documentation and
   don't block anything.