Skip to content

RFC — OSS Read-It-Later App

Why

None of the existing self-hosted read-it-later apps nail the full experience:

  • Readeck — decent parser, single binary, but: basic reading UX (only dark/light + serif/sans-serif), Readability strips images in bare divs, crashes on large HTML, no custom themes, limited API
  • Omnivore — had the best UX (reader customization, highlights, mobile apps) but shut down (acquired by ElevenLabs). Codebase is open but complex stack (Node, Postgres, Elasticsearch, Swift/Kotlin apps)
  • Karakeep — bookmark manager, not a reader. Stores text as raw text, no article rendering
  • Wallabag — aging PHP codebase, clunky UX, slow development
  • Pocket — commercial, not self-hosted, owned by Mozilla

The gap: a self-hosted read-it-later app with a polished reading experience and smart ingestion.

What to build (MVP scope TBD)

Must-haves (what's missing from Readeck)

  • [ ] Reader customization: font size, line height, margins, multiple themes
  • [ ] Reliable article parsing that doesn't strip images/figures
  • [ ] Site-specific cleanup (like the n8n FT config, but built-in)
  • [ ] Good mobile app (iOS + Android) with offline support
  • [ ] Highlights and annotations
  • [ ] Smart ingestion: depaywall support, archive.today integration

Nice-to-haves

  • [ ] AI summarization (local models via Ollama)
  • [ ] Semantic search ("that article about trade wars")
  • [ ] Auto-tagging/categorization
  • [ ] LLM-based article extraction fallback (for sites Readability can't parse)
  • [ ] OPDS endpoint for e-readers
  • [ ] Share to app from iOS/Android share sheet

Non-goals for MVP

  • Social features (sharing, public profiles)
  • Team/collaboration features
  • Browser extension (use share sheet or API)
  • PDF/ebook management (that's Calibre/Kavita territory)

Tech stack considerations

Component Option Notes
Backend Go or Rust Single binary, SQLite, no external deps. Readeck proves Go works well for this.
Article parser Mozilla Readability (Go port: go-readability) Proven, but needs site-specific overrides
Database SQLite Simple, embedded, fast enough for single-user/small-instance
Web UI Svelte or plain HTML+JS Keep it light. Reader UX is the priority.
Mobile Flutter One codebase → iOS + Android. Well-supported by AI code generation.
AI features Ollama API Optional, for summarization/tagging/semantic search
Search SQLite FTS5 or Meilisearch FTS5 for MVP, Meilisearch if semantic search is needed

Development approach

  • AI-assisted development (Claude Code, local models for scaffolding)
  • Mac Studio for local dev + local model testing
  • Estimated timeline: 3-5 months for working MVP with AI assistance
  • Key risk: mobile app polish is a long tail regardless of AI help

Realistic timeline with AI

Component Estimate
Backend + API 2-4 weeks
Web UI (reader focus) 2-3 weeks
Flutter mobile app 2-4 months
Article parser + site configs 1-2 weeks
Total MVP 3-5 months

Existing work to reuse

From the chizuru-v2 n8n pipeline: - Depaywall strategy chain (ladder, byparr, wayback, browserless) - Site-specific cleanup configs (FT done, more to come) - Content validation (isContentValid) - Archive.today HTML extraction - Article body extraction patterns

Open questions

  • What specifically frustrates you about Readeck's reading experience? (concrete gaps → MVP features)
  • Target audience: power users who self-host, or broader?
  • Name?
  • License: AGPL (like Readeck) or MIT/Apache?
  • Start from scratch or fork Omnivore/Readeck?

Next steps

  1. Write a one-page spec of concrete frustrations with current tools
  2. Define MVP feature set based on those frustrations
  3. Choose tech stack
  4. Scaffold project structure
  5. Build parser + API first (reuse n8n pipeline logic)
  6. Web reader UI
  7. Flutter app