Configurable topics?

[dasos]

Hi, thanks for the project. I've got it stood up (had to manually create the user and install the vector extension in postgres).

I've noticed the topics, RSS feeds are hard coded, and relatively US centric. There are also several blocked topics (don't like gaming news?) Other hard coded items include the LLM summary prompts. Would you consider making the app more configurable? I appreciate it would be a considerable refactor.

To be clear, I could fork it and make the edits myself, but that would mean diverging from your upstream. So I guess the other question is, are you planning to do more development?

Thanks for your thoughts.

[grregis]

Thanks for getting it running and for the detailed feedback, and sorry the setup required some manual steps that aren’t documented yet. This is something I’ve added to my roadmap.

You’ve identified exactly the right pain points. Configurable topics, RSS feeds, and LLM prompts are all on my roadmap. The hard-coded values were a pragmatic shortcut to get the project functional, and yes, the topic list definitely reflects my own reading habits more than anything universal. (The gaming block is personal preference but was poisoning the headline feed, fair point.)

I’m planning to continue development, though I should be transparent: the project is still early beta and I’m currently traveling for a couple of weeks with my dev server offline due to a power outage back home, so active development is paused for now.

I’d genuinely welcome a contribution on the configurability front if you’re inclined. If you want to take a stab at it, I’m happy to coordinate so your work doesn’t diverge unnecessarily. Either way, I’ve flagged this as a priority when I’m back.

[dasos]

OK thanks for the update, good to hear that you have plans in this area. I've got plenty of other projects I should be doing, but I'll see if I can pull together a PR. I'll let you know if I do.

[grregis]

Hey, quick update on this. Topics and RSS feeds are no longer hardcoded, you can now add, rename, reorder, and toggle topics from a new admin page, and same deal for RSS feeds, where you can add or remove them per bucket (general ingestion, right-leaning enrichment, left-leaning enrichment) without touching code. That's merged into main now.

While I was in there I also put together an install.sh that handles the setup friction you ran into. It creates the DB user, enables the pgvector extension, and generates a SECRET_KEY automatically, so a fresh checkout shouldn't need those manual steps anymore.

Still on the list: the gaming-news blocklist and the LLM prompts are both still hardcoded for now, planning to get to those next.

[grregis]

Closing the loop on this one — everything you raised is now configurable from the admin UI, with no code edits and no fork needed.

Since the July update:

• LLM prompts (/admin/prompts) — all 14, each editable in place with a one-click reset back to its original default. Save-time validation rejects a bad edit (unknown placeholder, stray brace) with an error naming the offending token, rather than silently breaking a live prompt.
• The blocked-topic lists (/admin/ingestion-blocks) — the gaming block you called out, plus the dev-noise, sports-recap, press-release-wire and betting entries. Each rule is a URL substring or a headline substring with a note explaining why it's there, and you can untick one to disable it without deleting it. Unblocking gaming is three clicks now.
• What actually gets fetched (/admin/scheduled-fetches) — this is the one that speaks to your "relatively US centric" point, which I don't think my July update really answered. The NewsAPI/GNews category and query list was still hardcoded, so configurable topics didn't help much when the ingestion queries were all country=us. Those queries are now rows you can edit, reorder, deactivate, or replace outright.
• Run schedule (/admin/pipeline-schedule) — when fetch-only vs. full-pipeline runs happen, previously env vars.

With topics and RSS feeds from July, that covers the whole list from your original post.

Two practical notes for upgrading:

• Run flask db upgrade after pulling. Each of these is a migration that seeds the new table from the values that used to be hardcoded, so your install keeps doing exactly what it did before and you opt into changes rather than having them applied to you. Skipping that step is what caused Was running ok, then "git pull" killed it #9.
• The seeded defaults still reflect my own reading habits — that part hasn't changed. The difference is they're defaults now rather than the only option.

On your original question about whether I'm still developing this: yes. Next up is per-tier LLM provider routing (#8), so the ~1,140 mechanical calls in a run can go to a local model while the ~65 summaries go somewhere better, and then a 1.0.

I'll leave this open a little longer in case you've stood it up again and something's still hardcoded that I've missed — you spotted things I'd stopped noticing. If it all looks right, I'll close it out.

Thanks for the nudge on this; the issue is most of what 0.6.0 turned into.