This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
Smart Feed Filter turns public RSS feeds into a short, category-grouped digest for one person.
The problem: professionals with RSS still drown in unread items, and generic readers sort by recency while AI summarizers add reading work instead of removing it.
Smart Feed Filter removes the triage step. You define a profile: a small set of categories, each with a name, description, criteria, and weight. A local decision model scores every feed item against those categories. The app shows the last 72 hours grouped by category, ranked inside each category, with tags and (optionally) a one-line reason.
It's a filtering engine, not a summarizer. No article fetching, no private accounts, no generated prose.
Who gets a little more relaxed, or lazier? The data scientist who wants to skim only ML-method papers and skip hiring/funding noise; the off-work reader who wants hobby content without the feed becoming an everything feed.
Smart Feed Filter's workflow in two steps:
User defines profile (categories, criteria, weights)
│
▼
Manual refresh → fetch → dedupe → store
│
▼
Local classifier (Ollama) scores new items
│
▼
72h digest grouped by category, ranked by score
Here are screenshots of the running app:
Low confidence group and sources
├── app
│ ├── config.py
│ ├── db.py
│ ├── __init__.py
│ ├── logging_config.py
│ ├── __main__.py
│ ├── main.py
│ ├── routes/
│ ├── schema.sql
│ ├── seed.py
│ ├── services/
│ ├── static/
│ ├── templates/
│ ├── timeutil.py
│ └── versioning.py
├── data
│ └── feedfilter.db
├── eval/
├── profiles
│ ├── catalog.yaml
│ ├── ds.v1.yaml
│ └── fun.v1.yaml
├── pyproject.toml
├── requirements.txt
├── spec.md
└── tests/
tev1:0.8b (fallback tev1:4b), POST /v1/systemone. ollama serve, ollama pull tev1:0.8b), retry classifies only missing.
Reasons are templated, never generated. Ranking handles ordering. Retroactive edits use a preview-diff-then-atomic-apply flow over the last 14 days; weight edits reorder without model calls, threshold edits re-filter cached probabilities.
Before building UI, I ran a model gate via python eval/harness.py --gate: a 100-item labeled set (50 per profile) scored on macro-F1, precision@10, latency, and failures. The local tev1:0.8b model passed my selection after category and threshold tuning; fallback tev1:4b documented.
Categorizing work content was (is?) harder than off-work (fun) content because real-world topics overlap heavily (ML methods vs. LLM apps vs. MLOps vs. experimentation), which is exactly why the spec encodes separate criteria fields and why ds.v1 needed more tuning cycles than the fun profile.
Here is the sample of ds.v1 profile:
id: ds.v1
name: Data Scientist
kind: work
version: 1
threshold: 0.62
max_categories: 16
seed: true
description: >
Professional reading profile for data scientists and ML practitioners.
Prefers methods, production practice, analytics, and responsible AI over
general technology news, hiring, funding, and product marketing.
exclude_hints:
- hiring, recruiting, and career advice
- funding, acquisitions, and business news
- consumer gadgets and general technology policy
- health or medical advice
categories:
- id: ml-research
name: ML Methods & Research
description: >-
New machine-learning methods, architectures, training techniques,
benchmarks, or results from research papers and research labs.
criteria_true: >-
The item reports or analyzes a machine-learning method, model, benchmark,
training technique, or research finding.
criteria_false: >-
The item is product news, production operations, business news, career
advice, or not about machine-learning methods.
reason_hint: covers methods, architectures, benchmarks, or research findings
weight: 1.3
enabled: true
Each category can be enabled/disabled. So for example you can be interested in some topic like "Responsible AI & Evaluation", and after getting enough valuable information just turn it off - until you need it again. Similarly with job search and vacancies - your job-search profile can include categories for different positions with their own criteria.
Open innovation made this build possible in a way a closed API never could. The intelligence here isn't a black box you call — it's a local model plus an open taxonomy loop: versioned category criteria, eval harness, gate, threshold tuning, and preview diffs. Opening the criteria (criteria_true / criteria_false, reason hints) meant the taxonomy itself became community- and maintainer-editable, versioned via hash.
And because the model runs locally on an open-weight model via Ollama - local-first means no vendor lock-in. Privacy wasn't an afterthought — it was the architecture: no API key, no telemetry, nothing leaving the machine except public feed requests. Open source made that stack reproducible.