Hypermind: a peer to peer deployment counter whose test script is the placeholder that always fails

The test script is the placeholder that always fails

The manifest has four scripts and one of them is the untouched default that a package manager writes when nobody fills it in. It echoes a message saying no test is specified and exits with a failure code, so any pipeline that runs npm test fails immediately and on purpose. That is the honest state of a project whose description says it does absolutely nothing useful, but it leaves two loose ends. A file called test-api.js sits at the repository root, which suggests someone wrote a way to exercise the endpoints, and no script in the manifest calls it. The Dockerfile installs with development dependencies omitted, and the manifest has no development dependencies at all, so that flag has nothing to omit.

Two of the three headline features ship switched off

The feature list has three entries: the counter, ephemeral chat and visualisations. The environment table sets the chat flag to false and the map flag to false, with only the theme switcher on by default. That means a run started with the image and no flags, or with the compose file the repository actually ships, gives you the counter and nothing else. The page's own run command sets both flags to true, so the difference between reading the page and using the repository is whether you get a chat system and a particle map or not:

docker run -d \
  --name hypermind \
  --network host \
  --restart unless-stopped \
  -e PORT=3000 \
  -e ENABLE_CHAT=true \
  -e ENABLE_MAP=true \
  ghcr.io/lklynet/hypermind:latest

The chat is not a client talking to a service either: it runs on the swarm topology with local and global modes and no history anywhere.

The richest configuration reference is a block of YAML comments

The environment table in the page lists nine variables across two headings. The compose file at the repository root lists fourteen, and four of them appear nowhere else: a heartbeat interval, a connection rotation interval, a message size cap and a chat rate limit window. All fourteen sit inside a commented block headed as refinements, alongside a second commented group of three add-on flags. So the most complete inventory of what can be tuned is not in the documentation at all; it is in the whitespace of a compose file, where a reader has to notice that twenty lines of comments are a settings reference. Two of the commented examples also contradict the documented defaults, offering a chat flag set to false, which is already what the table says the value is.

The compose file in the repository is not the one on the page

The page shows a compose block that sets the chat and map flags to true, and it labels the alternative Kubernetes path in a way that invites you to choose between them. The compose file actually in the repository sets only the port, leaves both flags commented out, and points at the same published image. Anyone who copies the page gets a different service from anyone who clones the repository. The networking line is the one thing both agree on, and it is the load bearing one: host networking, with a warning that this is a peer application that has to traverse NATs, that bridging breaks the distributed hash table, and that you will end up as the loneliest node in the multiverse. Every image reference on the page is pinned to a floating tag rather than a version.

A load balancer example for a network the page says not to bridge

The Kubernetes section is three commands: create a deployment on the published image with the port, set the environment on it, then expose it as a load balancer on that port.

kubectl create deployment hypermind --image=ghcr.io/lklynet/hypermind:latest --port=3000
kubectl set env deployment/hypermind PORT=3000 ENABLE_CHAT=true
kubectl expose deployment hypermind --type=LoadBalancer --port=3000 --target-port=3000

There is no host networking in those commands, which is the setting the Docker section calls mandatory for the distributed hash table to work at all. So the illustrated production path gives you a publicly reachable HTTP endpoint in front of a counter and a chat relay, and drops the one network setting the project insists on elsewhere. The same commands also set the chat flag, so the exposed service is the one with the gossip relay in it. It reads as a joke about enterprise deployment, and it is the only deployment path that would put this on the internet.

The all time count is an estimate, and the map draws one percent of it

Two numbers come out of the swarm and they are not the same kind of thing. The active count comes from a distributed cache of peers seen inside the last forty five seconds, with the timeout configurable and the cache capped at fifty thousand entries. The all time count uses a probabilistic sketch to estimate unique peers ever encountered, which the page puts at better than ninety eight percent accuracy. That means the all time figure is an estimate with an error band, not a count, and no band is given. The dashboard then renders at most five hundred particles against a cache that can hold fifty thousand, and the map is described as showing approximate peer locations when enabled. One percent of the tracked set is what you actually see.

Whispers travel five hops through peers that keep nothing

The chat commands include a private message that names a user and a block command that names one too. A private message on this network is a gossip relay, with the hop limit defaulting to five, so a message addressed to one person is handed to up to five intermediate nodes before it lands. Nothing is stored anywhere by design, the page says so twice, which is the point of the project and also the reason there is no record to appeal to. The per-message size cap and the chat rate limit window live in that commented compose block rather than in the settings table. Connection rotation every five minutes is described as the chaos that keeps the topology unblockable, and it also means any direct neighbour you just trusted is gone a moment later.

Three releases in one afternoon, none of them referenced in the docs

The published history is a single afternoon. Three tags went out on 20 January 2026, roughly two hours apart, ending at a version whose number matches the manifest exactly, so there is no skew to explain. Since then the repository has been pushed to once more, in May, with no new release. No command anywhere on the page names a version: the run command, the compose blocks and the Kubernetes commands all use a floating latest tag, which means a deployment that worked this morning can pick up a different image this afternoon with no change on your side. The description and the project name both sit in the same register, and the opening claim about how much memory the container wastes has been struck through, leaving the corrected figure unspecified.

Editorial conclusion

Read Hypermind if you want to understand what a Hyperswarm mesh looks like from the inside, because the mechanics are described more honestly than the project description suggests. Four things to know first. This is not something to run in production: the project's own framing is that it does nothing useful, its purpose is a number on a screen, and its historical readme text has a size claim struck through. Chat and the map are both disabled by default, so a first run from the repository's own compose file gives you the counter alone. The Kubernetes example exposes a load balancer and does not use host networking, which the Docker guidance says the distributed hash table needs, so treat that snippet as an illustration rather than a working manifest. And the test script always exits non-zero with a placeholder message, while an API test file sits at the root that no script invokes. If you are after production peer counting, this is a toy that happens to have a real network underneath it.

Frequently asked questions

Official sources

1. License: MIT
2. lklynet/hypermind on GitHub
3. Project website
4. README
5. Releases