Discover rising Hacker News discussions before they explode. Built-in velocity tracking, pinned threads, OP alerts, instant translation and local-first privacy.
Launch Team
Dropbox SignSimple, secure eSignatures for the way your team works.
Promoted
Curious—have you considered tracking comment velocity vs. upvote velocity? Some of the most valuable HN discussions aren't necessarily the highest-ranked, but they're the ones generating unusually deep conversations.
@franz_briones Great question — and you're pointing at something the current velocity
score doesn't fully capture yet.
Right now Radar blends points + comments into one combined velocity number
(comments weighted higher: 3x vs 2x for points), plus a separate "active"
flag past 150 comments. But you're right that a post accelerating in
comments while barely moving in rank is a genuinely different signal than
one climbing on votes — and today those look the same if their blended
score matches.
The good news: the raw ingredients are already tracked separately under
the hood, so exposing comment-velocity as its own visible signal (not just
baked into one combined number) is very doable — this is going on the list.
Thanks for the sharp feedback!
@m_m_carvalho Thanks for the detailed explanation! I didn't realize you were already tracking those signals separately under the hood. I think exposing comment velocity independently could surface a different class of posts altogether—ones that are generating unusually deep discussion even before the ranking fully reflects it. It'll be interesting to see how often those diverge in real-world usage.
@franz_briones Good timing — this shipped already. Added a "Deep Discussion" 🧵 badge to
Radar that surfaces exactly this: fires when comment velocity is running
disproportionately ahead of point velocity (not just raw comment count),
so a post with modest rank but unusually fast-growing conversation gets
flagged on its own, separate from the blended score.
Curious to hear if it catches the kind of posts you had in mind once you
try it — and yeah, genuinely curious too how often it diverges from the
rank-based signal in practice. If you spot false positives/negatives, let
me know, the threshold (comment velocity ≥3x point velocity) is a first
guess, not tuned on real usage yet.
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.