Nitter list/user RSS feeds are ingested as their own source type, enriched
via fxtwitter (author name/handle/avatar, cleaner text, attached photo) with
a graceful RSS-only fallback when that enrichment fails. Tweets always
publish directly, one per article, and never enter the LLM
clustering/synthesis pipeline — the same bypass already used for YouTube,
since merging unrelated tweets together makes no sense.
Rendering: a new distinct embed-card component (avatar, name + @handle,
full untruncated text, optional attached image, published-date-only
timestamp, no like/retweet stats) replaces the plain article row wherever a
tweet appears, on both the category-page list and the article detail page.
Verified end-to-end against the real sample Nitter RSS feed (served
locally): ingestion (all 100 items, tweet metadata correctly extracted,
retweet/quote-tweet blockquotes correctly excluded from own-content text),
publishing (bypasses clustering, tweet field threaded through to the
published article), and rendering (embed card appears on the homepage feed
and the article detail page, no duplicate title).
Known follow-up: fxtwitter's JSON field names are based on public
documentation, not a verified live response (that API is unreachable from
this sandbox) — worth a real curl check before relying on the enrichment
path in production; the RSS-only fallback path is what's actually been
exercised here.
/category/local secretly filtered by geo:'philadelphia' instead of the
Local category, a leftover from an old "Local: <region>" colon-syntax
convention that has no admin UI behind it anymore — the Sources tab assigns
plain category names via checkboxes, so a source tagged "Local" never got a
matching geo value and could never show up here, even though it correctly
appeared on Top Stories (which only checks pushToTopStories + the category
array, not geo). Local now filters by category like every other category
page.
Verified: reproduced the exact bug (geo: null despite category: ['Local']),
confirmed /api/feed?geo=philadelphia returns nothing while the new
/api/feed?category=local correctly returns the article.
A long RSS/Google News URL with no natural wrap points would overflow its
grid column and break the whole row layout. The URL is still visible (and
editable) via the edit form — the list row now only shows a status line
when there's something to say (poll result, error, or a just-cleared note).
Confirmed by reproduction: a mismatch between backend FRONTEND_ORIGIN and
frontend ORIGIN throws "CORS error: Incorrect 'Access-Control-Allow-Origin'
header is present on the requested resource" on every page, since
SvelteKit's server-side fetch enforces real CORS during SSR. Easy to trip on
since the two values live in separate .env files edited at different times.
adapter-auto doesn't produce a runnable standalone server when it can't
detect a supported hosting platform (Vercel/Netlify/Cloudflare/etc.) — this
is a self-hosted app with no such platform, so builds were silently missing
a real server output. Swapped to adapter-node, which builds to
build/index.js: a persistent Node server that reads PORT/HOST/ORIGIN at
runtime, exactly what a reverse proxy needs to point a domain at.
Added a README section covering the full path: building/running both apps
as plain Node processes, the env vars each needs, and the Nginx Proxy
Manager side (proxy host + Custom Locations for /api and /media under a
single-domain, path-routed setup, or a simpler two-domain alternative).
Verified live: the adapter-node build actually serves pages and correctly
picks up ADMIN_PANEL_ENABLED via `node --env-file=.env build/index.js`
(SvelteKit's $env/dynamic/private reads process.env directly in production,
unlike the vite-dev-time gap from the previous fix).
Only /admin/login and /admin/settings existed as actual pages, so navigating
to /admin itself 404'd regardless of ADMIN_PANEL_ENABLED. Settings already
redirects to login on a 401, so that's the sensible default landing spot.
process.env.ADMIN_PANEL_ENABLED was always undefined in the running
SvelteKit server process — Vite only injects VITE_-prefixed vars into
process.env for server-side code; plain vars in frontend/.env never reached
it, so the admin panel stayed disabled (cog hidden, /admin/* 404s) no matter
what the .env file said. Switched to SvelteKit's own $env/dynamic/private,
which reads it correctly in dev, preview, and adapter-based deployments.
Reproduced and verified the fix against a real frontend/.env file (not an
inline shell var, which is what masked this the first time).
Two hardening changes beyond just a password:
- The admin panel no longer uses stored credentials at all. The backend
generates a random API key on every startup and prints it to its own
console (never through the DB-backed logger, since that's only reachable
from inside the panel this key protects). Every /api/admin/* request must
carry it as an X-Api-Key header, checked with a timing-safe comparison on
every call — there's no session to create or steal, and restarting the
backend invalidates the previous key immediately. The old admin_users and
sessions tables, scrypt password hashing, and cookie-based session plumbing
are removed entirely (dropped via migration for existing installs, not
left behind unused). The login page keeps its existing layout but now asks
for this key and explains where to find it, storing it in the browser's
localStorage rather than relying on a server session.
- The admin panel (the masthead's cog icon and the /admin/* pages
themselves) is now disabled by default on every deployment, gated by a new
frontend-only ADMIN_PANEL_ENABLED env var. This is a separate, UI-only
visibility control — the API key above is what actually protects the
backend regardless of this flag.
Every ingested article used to show up on the homepage regardless of its
source, which meant a handful of high-volume feeds could flood "Top Stories."
Sources now default to not appearing there; a source has to explicitly opt
in via a new checkbox (also toggleable inline with a star icon) for its
articles to show up on the homepage feed. An article shows there if any of
its contributing sources opted in — merged/clustered stories aren't held to
requiring all sources to agree. Category pages, Local, tags, and events are
unaffected; this only gates the bare, no-filter homepage query.
Schema: sources.push_to_top_stories and merged_articles.top_stories, both
backfilled for existing databases via ALTER TABLE.
YouTube's public Atom feed only accepts a channel_id (or the legacy user
param) — it has no equivalent for the newer @handle format, so pasting a
handle URL straight into the source's url field wouldn't have worked. The
adapter now accepts a bare channel ID, a /channel/UC... URL, an @handle URL,
or a bare handle/username, resolving whichever was given to the actual
channel ID by reading it off the channel page when needed.
- Fix "Body cannot be empty" error on DELETE by making the JSON content-type
parser tolerate empty bodies, and by only sending Content-Type from the
frontend when a request actually has one.
- Deleting a source now cascades: raw content items and any article composed
entirely from that source are removed too, plus their media.
- Add admin endpoints/UI to clear all articles, all media, or a single
source's content without deleting the source, so things can be repopulated
fresh.
- Sources can now be assigned multiple categories via checkboxes (instead of
free text) and edited in place, not just added/deleted.
- Add a "News" default category (seeded fresh, backfilled on existing DBs) so
general news sources have a real home instead of the pseudo-category "Top
stories", which is just the homepage's all-categories chronological view.
- Widen the site's content column 15% (1080px -> 1242px).
- Add YouTube as its own source type/ingestion module: pulls a channel's
public Atom feed, and each video always publishes directly as its own
article (title, embedded video, publish date, description) rather than
going through the cross-source clustering/synthesis pipeline.
Claude
Salastil