Launched this week

NODUS HN Radar
Track rising Hacker News posts before they explode
60 followers
Track rising Hacker News posts before they explode
60 followers
Discover rising Hacker News discussions before they explode. Built-in velocity tracking, pinned threads, OP alerts, instant translation and local-first privacy.






Counter to the usual feed-aggregator framing: the value of an HN radar is not "more HN", it is the threshold function. The thing I want from a tool like this is not a stream, it is the ability to say "wake me only when a story crosses 200 points and has more than 50 comments and matches one of these tags."
Asking as a real user, not a gotcha: do you treat the user-set thresholds as a first-class config, or is the current product mostly recommendation-driven? The answer shapes whether I would replace my crude saved-search workflow with this. Either answer is fine, just changes my expectations.
@fabriziowexare Great point. Right now the focus is on surfacing rising stories through velocity and activity signals, but user-defined thresholds are something I'm actively considering.
I can definitely see value in workflows like:
Alert me when a post reaches 200+ points
Alert me when a post exceeds a comment threshold
Alert me when specific keywords start gaining traction
The current version is more recommendation-driven, but configurable thresholds are high on my list because they would make the tool useful for monitoring rather than just discovery.
Thanks for the thoughtful feedback.
@fabriziowexare following up on this — user-set thresholds are now
first-class config. Shipped in v0.16.x:
• Up to 5 watch rules per user
• Conditions today: points / comments / velocity (≥, ≤, =), implicit AND
• Pick which feeds each rule watches: Top / Show HN / Ask HN / Best
• In-panel bell with badge when matches come in (grouped by rule)
• Pin button on each match → sends the post to the Pinned section for
later
• Idempotence cache so the same (rule, post) doesn't notify twice in
24h
Architecture choice: polling is setInterval-based and only runs while
the side panel is open. NO chrome.alarms, NO chrome.notifications, NO
new permissions vs. previous versions. The trade-off is honest —
"active monitoring while you're tuned in" instead of a 24/7 daemon.
Phase 3b (next iteration, ~10h coding) adds AND/OR composition +
domain / keyword / regex predicates + tag matching + post-type filter
(SHOW/ASK/LAUNCH/TELL/POLL) + op-active flag.
Genuine question back: does the current 5-rule cap + simple AND clear
the bar to replace your saved-search workflow, or is the Phase 3b
composition what would make it stick? Your answer shapes what I
prioritize next.
Source you can audit (watcher.js + match-engine.js are the heart of
it): https://github.com/mmcarvalhodev/nodus-hn-radar
Live on Chrome Web Store + Firefox AMO as v0.16.11.
about the use case here. the people most likely to want early HN signal are founders doing competitor monitoring, recruiters, investors, or people trying to comment early for visibility. those are pretty different users with different needs. which one were you actually building for and does the current feature set reflect that or did it end up somewhere in between
@ansari_adin That's a question I've been thinking about as well.
The initial target was founders, makers and indie hackers who want to spot discussions early, before they become highly visible.
But during development I realized there are other interesting use cases:
Competitor monitoring
Market research
Recruiting
Following specific technology trends
The current version focuses mostly on early discovery, but feedback like this is helping me understand where the strongest use cases actually are.
Nice! what's the early tell before 'before they explode'? upvote velocity in the first 30 mins, comment-to-upvote ratio, or normalising for time-of-day so a 7am post isn't measured against peak hours? good luck with it, will check it out.
@hiyamojo Right now the strongest signal comes from a combination of score growth, comment activity and post age.
I'm still experimenting with the weighting, but velocity in the early stage is definitely one of the most important indicators.
Time normalization is an interesting idea as well. A post gaining traction at an off-peak hour may deserve a stronger signal than one growing during peak traffic.
Thanks for the suggestion — that's exactly the kind of refinement I'm exploring.
How early can it identify trending Hacker News posts?
@nithin_raju1 The goal is to identify promising discussions within minutes rather than waiting for them to reach the top pages.
It's not perfect prediction, but the extension continuously tracks activity and tries to surface posts that are gaining momentum early.
I'm still refining the scoring model, but early discovery is the main focus.