What Comes Next for Textflow

Good question — and since I'd hate to suggest building something that already exists, let me ground this in what's actually in the code rather than guess.

A few "obvious" ideas are already done — you have word count + reading time in the status bar (StatusBar.tsx:53) and online/offline detection — so I'll focus on real gaps. Let me confirm one more thing (what the editor's key handling already does) so I don't mis-describe it:

Now I've got an accurate picture. Turns out the editor already has a formatting toolbar (bold/italic/heading/link/list/code at EditorPane.tsx:116) and bracket auto-pairing — so those are off the list too. Here's where the real gaps are, tiered by payoff.

Tier 1 — Finish what's already half-built (best ROI) ​

1. Version history UI ⭐ my top pick Every save already snapshots content to R2 and appends a row to the versions table (pruned to 50) — see worker/files.ts. But nothing surfaces it. Add a history panel (list timestamps → diff/preview → "Restore") + one GET /api/files/:id/versions/:ts endpoint. The expensive half is done; you're getting time-travel/undo almost for free.

2. Trash / soft-delete Deletes are permanent right now (you have strong confirms, but no undo). A deleted_at column + a Trash view + restore turns a scary action into a safe one. Pairs naturally with #1.

Tier 2 — Make it a more capable editor ​

3. Image paste / drag-drop → R2 — There's zero attachment handling today. On paste/drop, upload to users/<uid>/assets/<id> and insert ![](…). R2 is already wired for note content, so this is the single feature that most makes it feel like a "real" markdown app. 4. Full-text content search — Search is name-only (Sidebar.tsx, MobileFiles.tsx:34). D1 ships SQLite FTS5 — index note bodies for real workspace-wide search. 5. Formatting keyboard shortcuts — the toolbar buttons exist but onKeyDown only handles Tab/auto-pair. Wire up Cmd/Ctrl+B/I/K. Tiny effort, big daily polish.

Tier 3 — Knowledge-base direction (bigger bets) ​

6. [[wikilinks]] + backlinks — link notes, show "linked from," maybe a graph. Turns an editor into an Obsidian-lite PKM. 7. Public share links — publish a note read-only at a public URL (share token in D1 + a public Worker route rendering from R2). High "wow," and it reuses infra you already have.

Tier 4 — Platform bets (lean on Cloudflare) ​

8. Offline PWA + durable queue — you detect offline but edits aren't persisted across a reload. A service worker + IndexedDB queue that flushes on reconnect is huge for the Capacitor Android build. 9. AI assist (Workers AI + Vectorize) — "summarize / rewrite / ask your notes" via embeddings. Cloudflare gives you this natively; highest ceiling as a differentiator. 10. Real-time collaboration (Durable Objects + CRDT) — the biggest lift; only worth it if multi-user editing is a goal.

Smaller wins: nested folders (model is flat), pinned/favorite notes, sort options, command palette (Cmd+K), bulk export as a zip / import, more OAuth providers, account deletion + data export.

My recommendation ​

That trio compounds: history makes editing safe, images make it capable, search makes it scale.

★ Insight ─────────────────────────────────────

• The cheapest features are the ones where the write path already exists. Version history feels like a big feature, but here the hard, invisible half — snapshotting bytes to R2 and indexing them in D1 on every save — already runs. What's missing is just read surface. Always check what your write path is quietly persisting before scoping a "new" feature.
• Storage shape dictates feature cost. Search-in-content is cheap because you're on D1 (SQLite → FTS5 is a built-in virtual table); it would've been painful on the old KV design. The KV→D1 migration you did didn't just fix write limits — it unlocked a whole class of query features. ─────────────────────────────────────────────────

Want me to build version history first? If so, there's one design decision worth your call up front — whether "Restore" should overwrite the current note or fork it into a new copy (keep-both), which mirrors the conflict-resolution model you already have. I can start there.