Misskey at 3,354 fingerprint matches and 717 title matches: reading a fediverse instance count

Fediverse platforms are usually discussed in terms of community growth, rarely in terms of reachable instances. Misskey is a case where the two available measurement methods disagree by a factor of roughly five, and the disagreement is more informative than either number on its own.

Context and method

Both queries below were run through the ZoomEye SDK on 2026-10-05 with sub_type=all, page=1 and pagesize=1. Page size limits the number of returned records; it does not limit the matched total, which is the figure reported here.

• Search: app="Misskey" returned 3,354.
• Comparison: title="Misskey" returned 717. No further filters were applied, so both figures describe globally indexed assets matching the stated condition at that time. Neither figure establishes whether an instance is reachable for login, correctly configured, or vulnerable.

Why the two numbers differ

The app field is populated from a fingerprint derived from observable behaviour, such as response headers, static asset paths and characteristic markup. The title field is populated from the HTML title element, which an operator can change freely and which many themes and localisations alter. A deployment behind a reverse proxy that rewrites the title, a custom instance name that omits the product name, or a client-rendered front page all reduce the title count without reducing the number of running instances.
The direction of the gap is the useful signal. Where the fingerprint count exceeds the title count, the likely explanation is deployment customisation rather than absence. Where a title count is far larger, the likely explanation is a keyword appearing in page text for unrelated reasons.

What a Misskey instance holds

A fediverse instance is an identity provider for its members and a store of their content. It holds local accounts, federated relationships, direct messages and, in many deployments, an administrative interface on the same host. The operator is a volunteer more often than not, which affects the patch cadence that can realistically be expected and makes the management interface placement a more important question than the version string.

Implications for defenders and operators

Run both queries rather than one. The fingerprint query gives the better population estimate; the title query gives a way to spot the subset that identifies itself, which often correlates with default configuration. Where an operator is auditing their own deployment, the version and configuration check happens on the host, not in the index, because a search engine cannot see an authentication requirement or a patch level.
Recording collection time matters here. This surface changes as instances are created and abandoned, so a single number is a snapshot rather than a stable inventory figure.

Limitations

The Misskey population is not a population of victims, and no exposure threshold should be read into these counts. The fingerprint itself can change between index versions, which is why the query string, sub_type and collection date are recorded alongside the number. Assets behind non-standard ports or unreachable from the collection vantage point are absent from both figures.

References

• ZoomEye, app="Misskey" (3,354) and title="Misskey" (717), sub_type=all, collected 2026-10-05.
• Misskey project documentation, deployment and administration guidance.