Hypermind: a P2P node counter that tells you how many people are running it
The High-Availability Solution to a Problem That Doesn't Exist.
At a glance
- What is it?
- Hypermind is a self-hosted, Hyperswarm-based counter and ephemeral chat that tracks how many peers are online. It is a toy with real distributed-systems machinery inside, and the README is honest about the joke.
- Who is it for?
- Adopt Hypermind if you want a small Node.js service that demonstrates Hyperswarm discovery, HyperLogLog estimation and SSE updates on a homelab box, and you accept that it needs host networking to function. Do not adopt it if you need durable message history, a stable peer count for capacity planning, or a container that works behind a bridge network.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 108 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Hypermind claims to solve, and the one it actually solves
The README states the project outright: it is "The High-Availability Solution to a Problem That Doesn't Exist." The stated goal is knowing how many other people are currently running this specific container, plus a serverless way to say hello to them. The repository topics include pointless, useless, meme and toy-project, so the framing is deliberate. There is no central server and no database; the README says the only thing present is The Swarm. The audience is homelab operators and Node.js developers who already run Docker containers and want a small, self-contained example of peer-to-peer discovery. It is not aimed at anyone who needs a metrics backend, a service registry, or a real chat product. The useful part is that the underlying pieces (Hyperswarm DHT, HyperLogLog, Server-Sent Events) are real, and the code is a working demonstration of them even though the output is a number on a dashboard.
How the swarm, the LRU cache and HyperLogLog fit together
The README describes four steps. Discovery: the node announces itself to the Hyperswarm DHT to find peers. Gossip: connected nodes exchange an "I exist" message. State: the active count comes from a distributed LRU cache of peers seen in the last 45 seconds, and the total history uses a HyperLogLog probabilistic structure that the README claims estimates unique peers with greater than 98 percent accuracy. Chaos: connections are rotated every 5 minutes to keep the topology dynamic. Two environment variables map directly onto this design. PEER_TIMEOUT defaults to 45000 milliseconds, which is the same 45-second window the README mentions, and MAX_PEERS defaults to 50000, which caps the LRU cache. The dashboard updates through Server-Sent Events rather than polling, so the browser holds an open HTTP connection to the local Node process. Chat rides on the same topology with two modes, Local for direct neighbors and Global for gossip relay, and MAX_RELAY_HOPS defaults to 5 to bound how far a global message travels. The distinction between the two counters matters: the active number is a real count of recently seen peers, while the total is an estimate. The README states the accuracy figure but does not describe the error characteristics at low peer counts, where HyperLogLog is least precise.
Deployment: host networking is not optional
The README gives a single docker run command. It pulls ghcr.io/lklynet/hypermind:latest, sets --name hypermind, --network host and --restart unless-stopped, and passes PORT=3000, ENABLE_CHAT=true and ENABLE_MAP=true. A Compose equivalent is provided with network_mode: host and the same three environment variables. The README includes a warning that the application needs to punch through NATs and that bridging the container usually causes the DHT to fail, leaving you as "the loneliest node in the multiverse." That is the single most important operational constraint in the project. Host networking means the container shares the host's network namespace, so the dashboard port is the host port and there is no port mapping to configure. A Kubernetes example is also given, using kubectl create deployment, kubectl set env and kubectl expose with a LoadBalancer. That example does not address the NAT requirement, and a LoadBalancer in front of a DHT member is a different topology than a host-network node. Treat the Kubernetes snippet as illustrative rather than a supported production path. Feature flags default to off: ENABLE_CHAT and ENABLE_MAP are both false, while ENABLE_THEMES defaults to true. VISUAL_LIMIT defaults to 500 and caps the particles drawn on the dashboard, which is the one setting aimed at browser performance rather than network behaviour.
What the chat does not promise
The chat is described as ephemeral with no database and no history. Messages exist only as long as the peers relaying them hold them. Global messages propagate by gossip with a TTL controlled by MAX_RELAY_HOPS, so reach depends on how many hops the operator allows and how many nodes are actually connected. The documented commands are /local for direct connections, /whisper for a private message, /block for a user, /timestamp and /sound for toggles, plus /help and a set of easter eggs such as /shrug and /tableflip. Markdown is supported. Nothing in the README describes message authentication, identity persistence, or replay protection. A /block command exists, which implies some notion of a user identity, but the material does not explain how that identity is established or whether it survives a reconnect. If you are evaluating this as a communication tool rather than a demo, those gaps are the ones to resolve before use. The README also notes a fork, Hypermind-Swarm, which the same creator built as a Twitter-style platform on the same P2P foundation. That fork is a separate repository and is not covered by the deployment instructions here.
Where Hypermind is the wrong tool
The most obvious failure mode is the network one already described: run it bridged and the DHT usually fails, which means the counter shows a near-empty swarm and the chat has nobody to talk to. The second is the count itself. A HyperLogLog estimate with a stated 98 percent accuracy figure is fine for a dashboard toy and unsuitable for anything that needs an exact figure, such as capacity planning or a billing trigger. The third is durability. With no database, restarting the container discards the local view, and the total history is rebuilt only from what peers report. The fourth is that connection rotation every 5 minutes, combined with MAX_CONNECTIONS defaulting to 15, bounds how much of the swarm any single node observes. A node with 15 connections is sampling a small slice of a large network, so two operators can legitimately see different active counts at the same moment. None of this is a defect in a project that names itself useless. It is a defect if you adopt it expecting a monitoring system.
What to compare it against
The closest comparison is not another counter but a conventional metrics stack. Prometheus with node_exporter gives an exact, durable, queryable count of containers or processes on hosts you control, and it works fine behind a bridge network because it polls over HTTP rather than joining a DHT. The difference in approach is fundamental: Hypermind learns about peers by having each node announce itself to a shared DHT and gossip, so it can count instances you do not own and cannot reach directly, at the cost of approximate totals and a NAT requirement. Prometheus cannot see a stranger's container at all, but it never reports an estimate. A second comparison is the chat: a self-hosted Matrix or IRC server keeps history and identity, while Hypermind deliberately keeps neither. The choice is between reach across untrusted networks and precision within a network you control. Hypermind picks reach. If your actual question is how many of your own containers are running, Prometheus answers it better and with less configuration.
Maintenance, versioning and the licence
The project is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and places few obligations on an operator running it internally, but this is not legal advice and anyone embedding the code in a product should read the licence text themselves. On maintenance, the repository is not archived and the last push recorded is 2026-05-30. Releases are v1.0.0 and v1.0.1, both dated 2026-01-20, with v0.14.1 earlier the same day. The jump from 0.14.1 to 1.0.0 on a single day suggests the version number is not tracking a long stabilisation period. There is a VirusTotal badge wired to a GitHub Actions workflow, which indicates some automated scanning of build artefacts, but the README does not describe a support policy, a compatibility matrix, or a deprecation process. Because the image is published to ghcr.io under the :latest tag in every example, an unattended restart can pull a different build than the one you tested. Pinning a digest or a version tag is the practical mitigation, and the release list gives you v1.0.1 as the tag to pin.
Integrations and what they tell you about the intended use
The README documents community integrations rather than first-party ones. A Home Assistant integration, installable through HACS, is described as providing RGB control where 0 nodes is green and 10,000 nodes is red, sensors for swarm health and statistics logging, and WLED support to display swarm size on an LED strip. A Homepage dashboard integration is mentioned but the README is truncated at that point, so the details are not available in the supplied material. These integrations confirm the intended setting: a homelab where making a light change colour based on a peer count is the point. They also introduce a dependency worth noting, since both are third-party projects maintained outside this repository and are not covered by Hypermind's MIT licence or its release cycle. If the counter is the only feature you want, the dashboard at http://localhost:3000 and the particle map are sufficient, and the integration layer is optional surface area you can skip.
Editorial conclusion
Adopt Hypermind if you want a small Node.js service that demonstrates Hyperswarm discovery, HyperLogLog estimation and SSE updates on a homelab box, and you accept that it needs host networking to function. Do not adopt it if you need durable message history, a stable peer count for capacity planning, or a container that works behind a bridge network. Before deploying, verify that your host allows the TCP and UTP traffic Hyperswarm requires and that port 3000 is free, because the README states a bridged container will usually fail to join the DHT.
Community notes