I’ve been working on NOVA because I’m genuinely exhausted by the current state of decentralized software. We’re building "distributed" tools that require 500MB of RAM just to render a search bar. It feels like we’ve gone backward.

NOVA is my attempt at a "Clean Room" implementation. It’s raw C++17. No runtimes, no heavy frameworks, just Win32 and GDI. I’m currently at v0.3 and using a terminal client called Onyx as the reference.

The hard parts:

Stripping the XP "Luna" theme to force a proper Whistler/Classic aesthetic without losing modern high-DPI support.

Using DeferWindowPos to handle atomic UI updates so it doesn't flicker like a 90s VB6 app.

Keeping the binary under 100KB while still supporting the metadata pipeline.

It’s definitely opinionated and probably "too low-level" for some, but I wanted to prove that you can still build extremely dense, high-performance tools that don't treat the user's CPU like an open buffet.

Curious what you guys think about the metadata fetch logic in the repo.

Option 2: The "Technical Deep Dive" (The Specialist) Show HN: NOVA – A C++17 framework for decentralized data

I just pushed v0.3 of NOVA. I've spent the last few weeks specifically on the GDI owner-draw logic and the metadata pipeline.

The goal was to build a decentralized engine that behaves like a "Data Terminal" rather than a webpage. I went with a statically linked Win32 architecture specifically for the "xcopy-deployable" aspect—I want this to run instantly on any machine without a setup wizard or a dozen DLL dependencies.

What's inside:

A custom layout engine that avoids the usual Win32 resize-flicker.

A 5-step signal ramp drawn directly in the status bar partition via WM_DRAWITEM.

Sub-10MB idle memory footprint.

If you're into native Win32/C++ or low-latency P2P, I'd love some eyes on how I'm handling the thread-safe UI updates from the metadata streams.

Show HN: My first project, a native Win32/C++17 assistant with zero dependencies