98bba62976cc01a7f8268817c67925f4e339e127
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 connor
|
98bba62976 |
Fix the 3am notification avalanche and the failing morning digest
Three bugs from the first day of real use. 1. Quiet hours were evaluated in UTC. The router is handed a UTC `now` and compared its hour against "22:00-07:00" directly, so notifications were silenced from 18:00 local -- prime reading time -- and the whole day's budget was released at 03:00 local. The reported avalanche landed at 03:39 and 03:55. Quiet hours are now converted to the reader's wall clock first. 2. The timezone never resolved anyway. TZ was "America/Louisville", which exists on this Arch host but NOT in a Debian container, which ships only the canonical "America/Kentucky/Louisville". The container fell back to UTC and `date` printed "America" as the zone abbreviation. The zone is now read from config rather than the environment, so a bad TZ cannot silently change behaviour, and the compose entry uses the canonical name. NOTE: ~20 other services in compose.yml carry the same bad string; they were left alone since it only affects their log timestamps. 3. Budgets are not a rate. Six notifications fired in a single minute because the daily allowance could all be spent in one cycle. Each lane now has a minimum gap (interest 75min, importance 30min) and sends at most one per cycle, which turns the budget into a rate spread across the day. Separately, the morning digest had silently fallen back to the templated list. The real 28-story payload takes 70.3s to generate against a 60s timeout. Raised to 180s -- and write_prose now LOGS why it failed instead of returning None in silence, which is what made a one-line timeout cost a debugging session. |
||
|
connor
|
7f402f22fe |
Rebalance the digest: rank by interest, cap per group, fix HN maturation
Connor: too much world news, very little software/aerospace/urbanism/Cincinnati. Measuring found three separate causes. 1. The digest ranked by max(interest, importance), and importance is largely a "big world news" detector -- 22 of 28 slots were entered on the importance axis. A personal reading list ordered by global importance is the wrong objective. The bulk of the digest is now ranked by INTEREST, with a bounded allowance (digest_importance_slots = 6) so a major event still makes the record on a busy day. 2. No per-group cap, so conflict and diplomacy took 18 of 28 slots. digest_max_per_group = 4, with unused capacity flowing back to the best remaining items so a quiet day still fills. 3. HN maturation could never happen. Items came only from `search_by_date`, which returns posts at 2-3 points; once one ages out of the newest window its score is never refetched, so it can never clear the bar and HN's best content was structurally invisible. 45 software clusters were sitting in "aggregator-immature". Added the front page via the `search` endpoint, which returns the crowd's verdict (measured: median 117 points, max 912) and whose re-polling is what actually supplies maturation. hn_min_score 150 -> 100, since a higher bar rejects most of the front page. Digest went from 8 groups (conflict 10, diplomacy 8, software 0) to 13 groups with a far flatter distribution, and the software slot is now "Benchmarking Qwen3.8 27B quantizations" -- the local-inference material that was asked for. Process note: the first two attempts at this silently did nothing. I used str.replace() without asserting the anchor matched, so a stale anchor wrote the file back unchanged while reporting success, and I measured "no change" twice before checking the file. Edits here now assert before writing. |
||
|
connor
|
dc6b6fea7e |
Phase 4: delivery -- ntfy, working feedback buttons, digest page
ntfy push is deliberately short: a title, one line, and a Click through to the story. The digest is a WEB PAGE, not a push payload -- the old system sent the whole report as one long markdown message and ntfy turned it into a .md attachment, which is what made it miserable to read on a phone. Feedback buttons finally work. The old ones never fired once: NEWS_API_BASE_URL was unset so they were dropped behind a single boot WARN, and /api/feedback had no auth anyway. ntfy runs http actions FROM THE PHONE, so the endpoint must be public -- which is why each button now carries an HMAC signed over (cluster_id, kind). A leaked URL authorises one vote on one story rather than acting as a bearer token for the whole model. Missing config drops the buttons loudly instead of silently. Digest prose is one LLM call per day through LiteLLM, and that is the entire generative-model surface of this system -- clustering, relevance, importance and vetoes are all embeddings and arithmetic. Feed text is passed as JSON data, never interpolated into prompt prose, so a headline cannot read as an instruction. Any failure falls back to the plain list; the digest never depends on a model being reachable. Verified against the live proxy: 20s, themed paragraphs, no invented facts. Digest page is mobile-first, dark-mode aware, and renders from notification_log so it is a record of what was actually sent. deploy/README.md documents the Caddy vhost and env the buttons require, and uses a python healthcheck rather than curl -- the v0.2 image shipped no curl, so its healthcheck failed forever while the service was fine. 62 tests. |
||
|
connor
|
b852840729 |
Normalise per group, and make the notification quota subject-based
Following Connor's point that corpus prevalence reflects how much an outlet publishes rather than what deserves a notification: allocation should track stated weights, not corpus composition in EITHER direction. Penalising a topic for being prevalent is a bug; rewarding it would just amplify whoever publishes most. This rules out the "reserve slots proportional to corpus share" model that the previous commit's findings were pointing toward. Two fixes: 1. Normalisation moves from per-block to per-GROUP. Taking the max across blocks gives a subject one draw per block, so foreign affairs -- six of 23 blocks -- beat everything else by having more chances. It held 70% of the digest while software-systems, a quarter of the corpus, held none. Collapsing to the group before normalising prices that in. Digest conflict share 13 -> 9, space 2 -> 4, and us-national appears at all. 2. The per-group quota now keys on the INTEREST group for both lanes. Importance blocks describe a kind of importance, not a subject, so two stories on one subject could each take a slot via different importance blocks -- which is what happened: both importance alerts were Middle East, one via war-escalation and one via economic-break. Interest alerts went from five-of-five Middle East to Ohio redistricting, political theory and tech policy. Also demoted prerelease/nightly build entries. The first alert software-systems ever won was "Nvim development (prerelease) build", which matches the block correctly and is worthless as a notification. Documented that switching normalizer requires re-tuning [routing] thresholds: they are in z-score units, and leaving them at 2.0 under "top-anchored" silences the interest lane entirely. |
||
|
connor
|
d4631ec13d |
Stop one subject taking every notification slot
Connor noticed 5 of 5 alerts were Middle East. Measuring showed that was not proportionate: Middle East blocks are ~11% of the eligible corpus while software-systems alone is 25%, yet Middle East took 35% of the top 20 and software took none. Two mechanisms, both measured: 1. Five conflict-* blocks could each claim their own alert slot. Interest blocks now carry a `group`, and routing enforces max_alerts_per_group_per_day, so related blocks share one quota. This alone moved the mix from 5/5 Middle East to three distinct groups. 2. Z-scoring subtracts each block's MEAN, which silently encodes how much of the corpus that block matches. software-systems has the HIGHEST mean raw similarity of any block (0.537) and the LOWEST max z (2.51); conflict-mideast-israel has a lower mean (0.460) and reaches 3.47. A topic is penalised for being well covered in your own feed list. Added `normalize = "top-anchored"` as an alternative that rescales each block by its own upper tail instead of its mean, leaving `weight` to express preference rather than corpus composition. Also ruled out a plausible-sounding cause rather than assuming it: HN and Lobsters items are title-only and much shorter than news articles, so terse titles seemed likely to match prose probes poorly. Measured the opposite -- title-only HN items score 0.618 against the software block, ABOVE Phoronix/LWN with summaries (0.610) and Ars Technica (0.540). Short text is not the problem; prevalence is. |
||
|
connor
|
23966a2d63 |
Phase 3: two-axis scoring and routing
Scoring (news/score.py): every profile block is embedded and compared by
z-score WITHIN block, then weighted. Veto fires on absolute similarity OR a
margin over the interest signal; demotes apply a penalty instead of excluding,
because those categories sit adjacent to real interests.
Importance is deliberately NOT corroboration count -- the old system's error,
which measured the subscription list rather than the news. It combines block
similarity, corroboration, burst velocity, editorial prominence and aggregator
score, all weighted from config.
Routing (news/route.py): two lanes with separate budgets. Interest never
overrides quiet hours; importance may, within a hard nightly cap. Vetoes are
absolute on BOTH lanes -- the v0.2 bypass lane never consulted relevance, so a
blocklisted item could still fire at priority 5, and a test now asserts it
cannot. Budgets are spent strongest-first rather than first-come.
Measured on 1,318 real clusters: 2.5 notifications/day and a 14-item digest,
inside the 2-5/day target.
Three defects the real data exposed, none of which unit tests would have caught:
- velocity was computed as origins/hours with a 0.5h floor, giving every
SINGLE-source cluster a spurious velocity of 2.0. Growth rate is undefined
for a cluster that has not grown; it is now zero below two origins.
- deferred items (quiet hours, budget exhausted, immature) settled straight
into the digest and bypassed its cap, producing 198 items/day. Everything
that misses an alert lane now competes for one ranked, capped digest.
- feeds return large archives on first fetch -- 88 Strong Towns items going back
five months, and a BBC entry titled "BBC News app" dated 2025. Those belong in
the scoring population but must never notify, so routing now has a recency
requirement.
Reading the output also found two profile gaps: recurring columns and link
round-ups ("Catching Our Eye News Roundup", "Astronomy Picture of the Day")
scored as top-ranked interest items. They are on-topic but publish on a
schedule, so they are demoted rather than vetoed and still reach the digest.
|
||
|
connor
|
a2c812794d |
Tiered corroboration: origins, pickups and depth scored separately
Connor's point: "several outlets carried this" covers situations that carry
different amounts of information, and origin_count() flattened them all to one
number. Splitting on same/different newsroom and same/different text gives four
cases:
same newsroom, same text -> pure duplicate (BBC World + BBC top). Zero
signal; the front-page placement it does carry is
already captured by sources.prominence.
same newsroom, diff text -> DEPTH. A newsroom filing four pieces on one story
is a real editorial judgement, previously
discarded entirely.
diff newsroom, same text -> PICKUPS. Syndicated copy; each carrier chose to
run it. Weak but non-zero.
diff newsroom, diff text -> ORIGINS. Independent judgement and independent
newsgathering. Strongest.
score = origins + 0.3*log1p(pickups) + 0.2*log1p(depth), weights in config.
Origins stay dominant; the others break ties among the many two- and
three-origin clusters, and log damping stops a high-volume feed inflating depth.
Measuring first changed the design. Depth outnumbers pickups 78 to 11 across 91
real clusters, because these sources are mostly national outlets writing their
own copy rather than local papers running wire -- so the more valuable half was
the one not originally proposed. UK settlements scores 10.55 from 10 origins
plus 15 same-newsroom pieces; AfD scores 5.55 from 5 origins plus 15.
Tests assert the four-case ordering directly, and that twenty pieces from one
newsroom still rank below two independent ones. Both needed a helper generating
vectors with exact pairwise cosine: the band between the 0.82 clustering
threshold and the 0.97 syndication threshold is narrow, and two earlier drafts
of these tests used ad-hoc vectors that fell outside it and asserted nothing.
|
||
|
connor
|
d57b9e092c |
Detect syndication from text, not just from configured ownership
Connor's observation: two outlets running the same story can be caught by comparing the text, without anyone having to know who owns whom. Corroboration is now origin_count(), a union-find where two items share an origin if EITHER they are in the same bucket, OR their text is near-identical (normalised title match, or cosine >= 0.97). The rules are complementary: buckets are same-owner/different-text (NYT filing five distinct AfD pieces), text matching is different-owner/same-text (a local station reprinting wire). On real data it fires exactly where it should: the vote-by-mail cluster collapses 2 buckets -> 1 origin, catching the States Newsroom syndication automatically -- the case previously fixed by hand in config -- and a Smithsonian story collapses 3 -> 2, catching WCPO reprinting wire, which no static bucket can express since WCPO is genuinely independent on local stories. The eight Renoir-heist reports, each independently written, correctly stay at 8. Across 91 multi-item clusters: 174 buckets -> 163 true origins. Note this is the one place a lexical comparison is right. Clustering fails on lexical methods because paraphrases share no wording, which is why the SimHash stage was measured and deleted -- but syndicated copy is literally the same bytes. First formulation was wrong and the data caught it: summing syndication groups and solo buckets produced 3 origins for a 2-bucket cluster. Syndication may only ever reduce corroboration, which the union-find guarantees and a test asserts. |
||
|
connor
|
863f5e20ac |
Make the system portable: split config from profile, remove hard-coding
Audit found three things compiled in that shouldn't have been: the User-Agent carried the author's domain, the cluster threshold and window were module constants the pipeline never overrode, and the embedding model was pinned -- which blocked the one change most likely to be wanted, swapping in a multilingual model for native-language sources. Configuration is now three files with distinct roles: config.toml (machinery), profile.toml (who the reader is), sources.toml (what to read). All are relocatable via NEWS_CONFIG_DIR. news/*.py now contains no interest, place name, feed URL, or personal identifier. tests/test_config.py keeps it that way: it builds a configuration for an invented reader and asserts none of the author's identity or preferences reaches the running code. Writing it immediately found a real bug -- CONFIG_DIR was resolved at import time, so NEWS_CONFIG_DIR silently did nothing if set after the module was first imported. Now resolved per instantiation. Documented the coupling that portability creates: [clustering].threshold and [scoring].veto_absolute are cosine constants calibrated against one corpus with one model, so changing [embedding].model invalidates both. |