Repository navigation
decision: dashboard/widgets, blog, and subscription surface - G28, G29, G39 #61
Description
Activity
Ready for your decision — and one of the three is now materially cheaper
This is
needs-decision, so it is not something I can implement. Here is the current state of each, with what changed since the issue was written.1. Dashboard / front wall + widgets — no longer backend-blocked
The issue records these as
x-auth-type: session. That was re-measured on 2026-09-14 (see #66) and is no longer true — confirmed200under Bearer:GET /api/user/dashboard-layout → 200 {"layout":null} GET /api/user/front-wall-layout → 200 {"layout":null} GET /api/user/engagement → 200 {"totalDigs":24,"totalPushes":6,…} GET /api/widgets/news → 200 GET /api/widgets/markets → 200I re-confirmed
/api/user/engagementmyself on 2026-09-15:200under Bearer, returningtotalDigs,totalPushesand arecent[]feed.So option 3 (full parity, including saved layouts) is no longer blocked. The issue's costing said it was. That materially changes the comparison, and it is the main reason this needs a fresh look rather than the answer it would have got a week ago.
Option 2 (native dashboard, no layout sync) still needs no new API at all and remains the cheapest useful thing.
What I need from you: 1, 2 or 3.
2. Blog — unchanged, and option 2 is still not viable
Re-checked the spec: the only public blog routes are
POST /api/blog/subscribe,GET /api/blog/subscribe/confirm, andGET/POST /api/blog/unsubscribe. There is still no public read route, so a native reader would need either a new endpoint or scraping, and scraping is not acceptable.What I need from you: option 1 (link out) or option 3 (subscribe management only). Option 2 stays off the table unless a read route appears.
3. Subscription surface — I recommend option 2, and there is a new reason
The issue recommends read-only status in Settings ▸ Account with a "manage in your browser" button. That recommendation is stronger now: PR #83 landed the capability gate, so Free users hit real upsell prompts in nine places and every one of them needs somewhere to send the user. Today there is nowhere.
customerStatusis already read ("subscriber"live), so this is a small pane, not an integration.What I need from you: confirm option 2, or say which of 1/3 you want instead.
To be explicit about what unblocks what
- Answer 3 and I can ship it immediately — it is the smallest and it closes a real gap the gating work opened.
- Answer 1 and the size depends entirely on which option: option 2 is a day, option 3 is a feature.
- Answer 2 and option 1 is ten minutes; option 3 is a small pane.
Nothing here needs code from me first.
Summary
Three product areas where the right first step is an owner decision, not code. Each is real surface on the web; none is obviously right for a native macOS client. Filing them together so the decisions are made once.
1. Dashboard / Front wall + widgets
/help/getting-startedputs the Dashboard second in prominence, right after Home:Its tiles: Scheduled posts, Exports, Settings, Profile Information, and a Lists tree (of lists and list folders). There is also a configurable front wall, plus widgets — Location, Weather, markets, news, transit, transit stops, bike-share — and a full-screen Clock page.
x-auth-type: session:(
GET /api/weatherandGET /api/locationare public.)So even if the answer is "build it", the saved-layout half cannot be built until the routes accept Bearer.
The design question stands regardless: a native app arguably wants its own arrangement rather than mirroring the web's saved layout. Note that most of the Dashboard's content already exists natively — Scheduled posts, Exports, Settings, and a lists tree all ship; what is missing is the aggregation and the own-messages table view. A native "Dashboard" could be assembled from existing pieces with no new API surface at all, which is a materially cheaper option than the layout-syncing one.
Options:
2. Blog
/help/blogdocuments a Blog feature, and the web footer links/blog. The public API surface is only subscribe / confirm / unsubscribe (POST /api/blog/subscribe,GET /api/blog/subscribe/confirm,GET/POST /api/blog/unsubscribe— all public, all Bearer-safe). Authoring lives entirely behind/api/admin/blog*, which is admin-only and out of scope for a general client.Options:
Native authoring is admin-gated and almost certainly out of scope.
3. Subscription status surface
The web has
/subscription(current tier, Manage, Cancel — all via Stripe). This repo's standing decision is the opposite for native: "billing is managed in the web app by owner decision", and there is no in-app-purchase surface.Meanwhile
LiveEntitlementsalready readscustomerStatus(live probe 2026-09-07 returns"customerStatus":"subscriber"), andSettingsRootView's header comment still lists "Subscription" as planned — so the code is ambiguous about which way this went.Options:
What "done" looks like for this issue
docs/decisions/.Notes
work-consolidation.mdtracks these as G28, G29, and G39. The dashboard's session-only constraint is new information from the 2026-09-07 sweep and materially changes option 3's cost.