Ghost Murmur Tech, Proof of Usefulness, and Why Devs Should Write
Published on 18.04.2026
What Ghost Murmur Technology Actually Is (And What It Isn't)
TLDR: The CIA has claimed that Ghost Murmur technology can detect a human heartbeat from 40 miles away. Physicists looked at the math and say the numbers are off by roughly 2 quintillion. So what does this technology actually do?
Summary: Let's start with the claim, because it's genuinely wild. At some point someone in an official capacity said that a technology called Ghost Murmur can detect a human heartbeat from 40 miles away. That's not a typo. Forty miles. For context, a normal pulse oximeter has to be clipped to your finger to work, and even high-end radar or sonar systems that monitor respiration do so across tens of meters, not tens of miles.
Physicists who looked at the underlying physics here are pretty unanimous: the signal-to-noise problem alone makes the 40-mile claim impossible with any current or near-future signal processing approach. The math doesn't get you there. The article calls out that the actual physics puts the error factor somewhere around 2 quintillion, which is one of those numbers that makes you stop and recount the zeroes. It's not "a little off." It's off in a way that suggests the people making the claim either didn't understand the technology or were describing something entirely different from what the label implies.
What Ghost Murmur actually does is considerably more modest but still interesting. It appears to operate as a form of radar-based passive sensing, likely capable of detecting motion or large-scale physiological signals like breathing at short to moderate range under specific environmental conditions. That's genuinely useful for certain applications in search and rescue or surveillance contexts. But it is categorically not a 40-mile heartbeat detector. The author, writing under the handle Misclassify, is someone who consistently asks the pointed question: is that technology where it's supposed to be? Meaning, are the claims being made for it accurate to what it actually does?
This is a pattern worth paying attention to. The gap between what a technology is claimed to do and what it actually does is enormous in surveillance and defense contexts, and the claims rarely get the same public correction as the original announcement. Ghost Murmur probably works for something. Just not what was described.
Key takeaways:
- The 40-mile heartbeat detection claim attributed to Ghost Murmur technology does not hold up to basic physics review
- The actual technology likely uses radar-based sensing for motion or respiration detection at much shorter range
- The article is a useful reminder that official technology claims, especially in defense and intelligence contexts, often go unchecked by people with the domain knowledge to evaluate them
Why do I care: From an engineering standpoint, this is a story about specification drift and communication failure. When teams or organizations describe what a system does, accuracy matters. If you build systems, you know how often a capability gets described to stakeholders in terms that bear only a loose relationship to what was actually implemented. The stakes are obviously different when the claim is about surveillance capabilities rather than a feature demo, but the underlying problem, overclaiming what technology can do, is one every engineer bumps into.
What Ghost Murmur Technology Actually Is (It's Not a Heartbeat Detector)
The Proof of Usefulness Algorithm: Is It Good? Do People Use It?
TLDR: HackerNoon's Proof of Usefulness hackathon tries to score projects on two criteria: quality and actual adoption. The algorithm is a deliberate rejection of pitch-deck-style evaluation in favor of something measurable.
Summary: There's a certain fatigue that sets in when you've watched enough hackathons judge projects on presentation polish rather than whether the thing works or whether anyone would actually use it. The Proof of Usefulness initiative from HackerNoon is trying to do something about that by building an algorithm that attempts to answer just two questions: is it good, and do people use it?
Those two questions sound simple but they're surprisingly hard to operationalize. "Is it good" tends to collapse into subjective evaluation unless you pin it to something concrete, like reliability, documentation quality, benchmark performance, or some domain-specific measure of correctness. "Do people use it" is more tractable since you can look at download counts, GitHub stars, deployment metrics, or community activity, but it also rewards incumbents and penalizes genuinely novel work that hasn't had time to accumulate an audience.
The article frames the algorithm as a technical approach to these two questions. The tagline is "usage is the new valuation," which I think gets at something real. For too long, open source and startup tooling evaluation has been driven by who can get on stage and talk well about what they built. The Proof of Usefulness framing pushes back on that by saying that actual adoption data should carry the most weight.
What I find interesting is that this is essentially a search ranking problem dressed up as a hackathon scoring system. The questions it asks are the same ones search engines, package registries, and recommendation systems have been grappling with for years. How do you surface things that are actually good and actually used, rather than things that are well marketed? The Proof of Usefulness hackathon is one answer, and even if the algorithm has rough edges, the framing is worth taking seriously.
Key takeaways:
- The Proof of Usefulness algorithm scores projects on two dimensions: quality and real-world adoption
- It explicitly rejects pitch-deck and presentation-based evaluation in favor of measurable criteria
- The "usage is the new valuation" principle has parallels in how search and recommendation systems rank content
Why do I care: As someone who thinks a lot about developer tooling and ecosystem health, this hits a real nerve. The tools that win mindshare in the frontend ecosystem aren't always the best ones technically. Sometimes they're just the ones with the best documentation sites and conference talks. A more algorithmic, usage-based scoring system for evaluating projects is genuinely useful, especially for people trying to evaluate whether to adopt a library or framework without spending days on benchmarks.
The Proof of Usefulness Algorithm: Is It Good? Do People Use It?
Why Developers Should Write Technical Articles
TLDR: Writing technical content is one of the most underrated tools in a developer's career kit. It consolidates knowledge, builds credibility, and contributes to community standards in ways that just shipping code doesn't.
Summary: This is an older piece from HackerNoon but it gets included in the newsletter because it's perennially relevant, and honestly because the newsletter team is probably nudging readers to contribute. The core argument is that writing about what you build and what you've learned is valuable both for you and for other developers.
The consolidation argument is the one I find most compelling personally. When you sit down to write a technical explanation of something you've implemented, you almost always discover gaps in your own understanding. The act of making something legible to someone else forces a different kind of clarity than just making it work. You can ship code that you don't fully understand in a deep way and it'll run fine. You can't write a coherent explanation of it without understanding it, or at least without realizing where your gaps are.
The credibility argument is also real, though it operates on a longer time horizon. Engineers who write consistently about what they're working on build a public record of their thinking. That compounds over time in ways that are hard to manufacture otherwise. It's not about personal branding in the shallow sense. It's about being someone whose reasoning and judgment are legible to the broader community.
The practical how-to material in the article covers things like picking topics from problems you've actually solved, writing for the reader who is two steps behind where you currently are, and not waiting until you feel like an expert to write. That last point is important. Most useful technical writing comes from people who just figured something out, not people who have known it for years.
Key takeaways:
- Writing technical articles helps consolidate your own understanding, often revealing gaps you didn't know existed
- Consistent technical writing builds credibility and a legible public record of your reasoning over time
- The best time to write about something is right after you've learned it, when the confusion is still fresh
Why do I care: I've seen engineers who are clearly brilliant struggle to communicate what they know, and I've seen engineers with solid but not extraordinary technical skills punch way above their weight by being good at writing and explaining. The return on investment for writing is genuinely high, and it's a skill that compounds. If you're a developer who has never written publicly about your work, the barrier is lower than you think.