IoT: 2. Feature & Growth Ideas (May 2025) - FrankRay78/NetPace GitHub Wiki

Notes from a research session exploring how to grow NetPace's user base.

NetPace's Distinctive Position

NetPace is not in direct competition with projects like Speedtest Tracker. The key distinctions:

  • Single binary, zero setup — runs anywhere without Docker, a database, or a web server. Directly fills the gap Speedtest Tracker's maintainer explicitly said he won't support (bare-metal/LXC installs).
  • Scriptable and CI-friendly — clean CSV/JSON output, quiet mode, non-zero exit codes. Fits shell scripts and pipelines in a way a web dashboard never will.
  • Developer-first library design — ISpeedTestService, SpeedTestStub, FaultySpeedTester etc. allow unit testing against a speed test abstraction. No other tool in this space offers this.
  • Only well-maintained cross-platform .NET speed test library on NuGet.

Feature Ideas (from community research)

The following came from analysing the Speedtest Tracker v2 discussion thread (Aug 2025–Apr 2026, ~24 comments) and general research into the space.

1. LibreSpeed Provider (--provider librespeed)

Implement ISpeedTestService against the LibreSpeed open-source server protocol as an alternative to Ookla.

Why: Ookla's self-hosted server requires company registration and Ookla approval — not available to individuals. LibreSpeed is fully self-hostable (Docker, one command) with no gating. Users can spin up a server on a VPS in their chosen datacentre and point NetPace at it via --server https://my-vps.example.com, giving a fixed, consistent test endpoint for repeatable results over time.

LibreSpeed CLI supports --server-json / --local-json for custom server lists and --interface for network interface binding. LGPL licensed, no concerns implementing against the protocol.

Audience: Privacy-conscious users, homelabbers, multi-WAN users, anyone wanting reproducible results.

2. Jitter Measurement

Surface jitter (standard deviation across latency samples) alongside the existing latency figure.

Why: NetPace already runs multiple latency samples for server selection — the data is there. Jitter is the metric that matters for VoIP and gaming, and is a frequently requested addition in the space.

Effort: Low.

3. Packet Loss

Report packet loss percentage from the Ookla test result.

Why: The data is already in the Ookla dataset. Multiple users in the Speedtest Tracker v2 thread asked for it specifically.

Effort: Very low.

4. --interface Binding

Allow tests to be bound to a specific network interface (e.g. --interface eth1).

Why: The most recent comment in the Speedtest Tracker v2 thread (Apr 2026) made a detailed case for this. Users with multi-WAN setups (two ISP connections, dual-WAN routers) currently need two separate tool instances. A source interface hint lets the firewall policy-route the test traffic, enabling per-WAN measurements from a single NetPace install.

Audience: Homelab users, small businesses with failover connections.

5. Threshold Alerting (--alert-below)

Exit with a non-zero code and print a warning when results fall below a specified threshold.

Why: Highly requested across the space. For a scriptable CLI this is the right primitive — no notification infrastructure needed, just an exit code that scripts and cron jobs can act on.

Example: netpace --alert-below-download 50mbps

6. ARM and Native AOT Binaries

Expand the GitHub Actions release matrix to produce ARM64 binaries and native AOT builds.

Why: ARM is where self-hosters actually run things — Raspberry Pi, Apple Silicon, Oracle Cloud free tier, AWS Graviton. Native AOT removes the .NET runtime dependency and reduces startup time, which matters for scripts and cron jobs. Largely a CI matrix change.

Positioning Notes

  • Lean harder into "no Docker, no setup, just a binary" in the README — this is the gap Speedtest Tracker won't fill and it resonates with the Proxmox/homelab crowd.
  • The NuGet library with test doubles is the feature that most clearly differentiates NetPace from every other tool in this space. Worth surfacing more prominently.
  • LibreSpeed provider + --interface binding together address the multi-WAN homelab use case end-to-end.