Skip to content

IDEAS.md

Latest commit

 

History

History
71 lines (49 loc) · 3.55 KB

IDEAS.md

File metadata and controls

71 lines (49 loc) · 3.55 KB
Raw

Future Ideas

Brainstorm sink — not commitments. Captured 2026-05-26.

Rethink the end product

The current pipeline is ingest → classify → consolidate → summarize → embed → wiki. The wiki is just one possible sink. The same pipeline can power several different products on top of the same DB.

Reading patterns dashboard

Aggregate queries over SyncRun, Highlight.highlighted_at, Highlight.source_title to surface:

  • "You highlight 3x more on weekends"
  • "Your topic spread shifted from tech → philosophy this quarter"
  • "You've stopped highlighting fiction since March"

Pure SQL. No new LLM cost. Adds a "Patterns" tab to the existing UI.

Knowledge graph view

Topic.related_topics (M2M) is already a graph. Render with cytoscape.js or d3.force. Edge weights from co-occurrence counts. Nodes sized by highlight count. Click a node to drill into the topic page.

Surprise detector

For each new highlight, compute cosine distance to existing topic centroids via pgvector. Highlights that don't fit any cluster well = potentially the most novel things you've read. Surface as a "What surprised you this week" section.

Reading recommendations

Embed book metadata (title + blurb), match against the user's top-N insight cluster centroids. "Because you've been highlighting around Plans fail under uncertainty, you might like Antifragile." Needs a books corpus — could seed from Readwise's "to-read" list or Goodreads.

User-defined pipelines

Long-term: let users configure their own pipeline stages. A "step" is just a function taking highlights/topics and producing a side effect. UI would be a node-graph editor like n8n / Zapier. Big lift but the building blocks (LLMCall, batched tasks, Celery chains) are already there.

Multi-tenancy (login with Readwise)

Today the app uses a single hardcoded READWISE_TOKEN from env. To open it up to other users:

Auth flow

Readwise has no OAuth — they use personal access tokens at readwise.io/access_token. Standard pattern:

  1. User signs up via Django auth (or django-allauth for Google/GitHub social login)
  2. After signup, prompted to paste their Readwise token
  3. Token stored encrypted (django-encrypted-fields or cryptography.fernet)

Data model changes

Add user = ForeignKey(User, on_delete=CASCADE) to:

  • Highlight
  • Topic
  • SyncRun
  • ClassificationBatch
  • LLMCall

Scope every queryset to request.user. Migrate existing data to a single "you" user.

Task changes

  • sync_readwise_task takes user_id arg
  • Build ReadwiseClient from the user's stored token, not settings.READWISE_TOKEN
  • Beat schedule iterates: for user in User.objects.all(): sync_readwise_task.delay(user.id)

Cost realities

LLM cost scales linearly with users. With 10 users × 100 highlights × daily sync ≈ $150–600/month at current model rates. Before opening signups:

  • Per-user spend cap (track via LLMCall.cost_estimate_usd aggregation)
  • Free-tier limit (e.g., 50 highlights/day classified, weekly sync)
  • Stripe + Plan model with quotas

Effort

~1-2 weeks done well. The architecture supports it cleanly — add the FK, scope the queries, parameterize the sync. The cost layer is the bigger product question.

Decision: do these only if committing to product

These are all real opportunities, but they're product moves not portfolio moves. The current single-user wiki is a good portfolio piece as-is. Pursuing the above turns this into a real product with users, billing, support, etc. — worth doing if that's the goal, not worth doing for the demo.