I have been working on a small project called Hoverfly, and it is finally at the point where I am comfortable showing it to other Hive developers.
The short version is this:
Hoverfly is a single-binary local mock Hive server for testing apps, scripts, bots, and SDK integrations without depending on a live node or a stable testnet.
Testnets are not always available when you need them, and using mainnet as a test fixture is a terrible habit.
Hoverflies look like bees, but they are not.
When you are writing a Hive application, a lot of the early testing does not actually require consensus, P2P networking, or a real witness network.
You usually need to answer simpler questions first:
Hoverfly is meant to handle that layer.
It gives you a local Hive-shaped environment that starts quickly, resets easily, and does not touch the real chain.
Hoverfly is written in Go and uses BadgerDB for its local state.
By default, it runs in-memory, so stopping the process gives you a clean slate. If you want a longer-lived sandbox, you can point it at a local database directory.
It starts with seeded test accounts, including Alice and Bob, and generates local keys for them. It also simulates block production so applications that expect the head block and dynamic global properties to move forward have something realistic enough to work with.
The server currently includes explicit handlers for important account, block, content, broadcast, history, and debug flows, along with generated OpenAPI-shaped responses for the wider documented method surface.
This is not a consensus node.
It does not do P2P networking, witness scheduling, or real economics. It is a developer tool for the part of the workflow where a fast local target is more useful than a live blockchain.
The useful part is that this is not just a collection of static JSON examples.
Supported local transaction flows can mutate the sandbox:
There is also transaction serialization and signature recovery work in the project, so the goal is to catch more than just HTTP mistakes.
The default mode is intentionally permissive for quick scripts. A strict mode is available when you want selected transaction-state validation instead.
Before announcing Hoverfly, I did a pass focused less on adding shiny features and more on making the project safer to hand to somebody else.
That included fixing a standalone build problem caused by a local development dependency replacement. The public hive-anther module already has tagged releases, so Hoverfly now resolves it normally instead of assuming another repository exists beside it on disk.
I also tightened up the server itself:
The documentation also needed some honesty work. The API surface is broad, but not every endpoint is a stateful consensus-accurate implementation. The README now distinguishes explicit stateful routes from generated fixtures and fallback responses.
A mock should be useful without pretending to be something it is not.
The project currently has:
Two malformed cases in the curl fixture are skipped by the smoke tool, so I am not pretending that number is a perfect 289/289. This is still an early project and there is more semantic compatibility testing to do.
But it is now in a much better place for early adopters to try it.
The repository is here:
If you have a client that assumes it is talking to a Hive node, Hoverfly is an invitation to point it at localhost instead and see what breaks before the real chain gets involved.
Nothing fancy, just a local sandbox that should make testing less annoying.
As always,
Michael Garcia a.k.a. TheCrazyGM
