Skip to content

Big News from the Nothing Ecosystem

Fam. We need to talk.

July 2026 has been a wild month at Ernest Tech House. Multiple things are happening at once — some finished, some in theory, some shipping this week. Let's break it all down.


1. Pipes & Sockets Are Going Legacy

This is the big one.

As of today, Piggy communicates with the Nothing Browser binary through a named pipe (Windows) or a Unix domain socket (Linux/macOS). That's how commands travel from your script to the binary. Fast, local, no HTTP overhead.

That communication channel is going legacy when the next binary version drops.

Why?

Because of this error:

🪟 Windows — The Pipe Bug (Named Pipe Connection Failure)

If you've hit this on Windows, you know exactly how frustrating it is. Named pipe connection failures on Windows are deep in the OS plumbing — not something fixable with a code patch on our side. I was writing most of my scripts on Windows and hitting this constantly. It drove me absolutely insane.

So I went into theory mode.

The New Model: WebSockets

Here's the idea. A named pipe is a 1:1 connection — rigid, OS-specific, fragile on Windows. A WebSocket is different: it's an open channel that says "hey, I'm here, what do you need?"

The new flow will work like this:

  1. User double-clicks the Nothing Browser binary on their machine
  2. Binary launches and opens a WebSocket server internally
  3. Binary hands you the WebSocket connection config
  4. In your script, you pass it to await piggy.launch():
typescript
await piggy.launch({
  ws: {
    url: 'ws://localhost:PORT',
    // ...config the binary gives you
  }
})
  1. Everything from that point onwards is exactly the same as today

No pipe. No named pipe hell. No Windows errors that can't be fixed with code. Just a WebSocket that works identically on every OS.

One important thing: this is a theory as of right now. Coding has not started yet. It will begin once cppws development wraps up (more on that in point 2). The current named pipe / socket communication is still the active channel — don't go changing anything in your scripts today.

And don't panic about your existing code. Old versions of both the library and the binary will continue working. Just don't run npm update blindly if you're on a version that's working for you. Stay where you are until you're ready to move.


2. We're Building a WebSocket Library — cppws

You guessed it. C++ and TypeScript. Because apparently we can't help ourselves.

cppws is our native WebSocket server library — uWebSockets at the core, N-API bindings, TypeScript on top. It started as an Elysia plugin called elysiajscppws, hit a fundamental architectural wall (Bun owns the sockets — long story), and came out the other side as a proper standalone server that runs alongside any HTTP framework or none at all.

Full details are already live in the docs:

📖 cppws Documentation

Timeline: this Thursday night or the weekend. That's when the library drops. The docs and integration guides are already written. The test suite is already passing. We're just finishing final polish before publishing to npm.

If you're building anything real-time — chat, live dashboards, multiplayer, command routing between services — cppws is going to be your thing.


3. Nothing Runtime — First Phase Complete

We don't talk about this one much yet. But it's moving.

The first base of coding for the Nothing Runtime is done. Testing hasn't started yet, but the foundation is solid and it's showing serious potential. This is a longer-horizon project but the early signs are genuinely exciting.

More details will come when testing begins and we have something concrete to show. For now: it's real, it's progressing, and the first phase went great.


4. A Great Thought

I have been thinking. Some sites that were made in the early 2000 era use DWR (Direct Web Remoting) security — like the Kenyan iTax portal. This makes it very hard to scrape them or make requests like normal sites.

This is just a theory, but what if there was an API like:

typescript
await piggy.itax.runjs.indevtools()

Yeah. This runs in something like that tab's console. Now a side note — this code should not be complex JS that will fail in light theory. This should work because well, you are in that browser's context and you use that browser's JS. So yeah. 90% it will work.

This update will come in later releases as important fixes are landing today and tomorrow.


5. Some Changes (The Honest Truth)

Unfortunately, the latest binary version is a bit koo-koo. Which means things are being done wrongly.

Because of that, every API related to:

  1. Cookies
  2. Storage
  3. WhatsApp

...will be removed in the next huge rewrite.

These APIs were merged because we were in the process of making our own WhatsApp bot library and we got a little bit carried away. But no worries — the next binary version will reduce from 110 APIs to about 90 APIs. Sorry for any inconveniences caused.

What This Actually Means

This will also ship with Nothing Browser as a volatile browser binary. Which means your current session that you will use will be deleted on browser close / binary crash.

This has great disadvantages but also great advantages.

And also — I don't know how to code C++ for cookies and storage. So I just wrote code that starts fresh every time.

Why am I doing this?

  1. Nothing Browser in its DNA is volatile. You can't inject cookies in it. The .cookiesinject API is using JS to try and give Qt cookies — and it fails. Why? I don't know.
  2. I am making a scraping browser. If I save your sessions, you can be trackable with cookies.
  3. The DNA of both headless and headful binary does not allow cookies injection, let alone cookies storage.

I know people will shush this news. But read this: Session Management Docs

The session export exports a huge JSON. And that is from captured request chugging. Then back in — works 50% of the time. Or Qt just ignores them. I don't know why Qt does that.

And also: Nothing Private Browser

This is the original version of Nothing Browser. This is what it was meant to be. In the first place, it was not meant to store cookies or storage. It was just meant to dump captured stuff and give you a JSON.

The Silver Lining

Great news in this pool of terrible news:

  • Nothing Browser hit 40 GitHub stars yesterday 🎉
  • Some new APIs are coming
  • We are also thinking of forking Zen Browser since it is mainly styled using JS — we revamp the UI, slap our logo, and call it Nothing Telemetry Browser.

Why? Just for fun. And also because that is JS and not C++. It can be done in like 3 days. Easy. Not that C++ is hard — I also want a browser in my name.

Not to worry — Nothing Browser and Nothing Private Browser will also receive updates. Thank you.


6. Ernest Tech House is on YouTube

We have a YouTube channel now.

📺 youtube.com/@ErnestTechHouse

What's going up there:

  • Tutorials on everything we build — Piggy, cppws, Nothing Browser, Nothing Runtime
  • Walkthroughs of real scraping scripts
  • Some random beats and cool vibes because why not

Subscribe if you want to follow along as we build. We'll be posting regularly.



7. Sth i just figured out

their is something funny i have just figured out, nothing browse performs activities in browser what do i mean listen to my thinkng when using cdp you control the ui using the pointer and some instructions note instructions like the teacher tells you wipe the board and you wipe it then you report back with i have wiped it tat is how in theory cdp works it is a protocal or something nothing browser is not a protocal it is a map of commands wht do i mean when you send await piggy.somesite.click piggy js li makes a json command sends it over the pipe or socket depends on when you are reading thisit looks hey i recevived this instructions what does it mean it gives the binary the json the binary sees it is a click n an object and it uses c++ to simulate the click then responds back i have cliked and the js lib brings back sucess clicked and that is why piggy js tool is just 4 files though long but just literal 4 js files and a python library a go any language that can talk either named pipes of ws can talk to the binary because the binary has no idea what language is sending the command it is just takingit executing and returnin back a sucess simple that is why it is hard to detect events that are in browser (which we emplore) nothing browser will soon become the number one scraping binary i sure hope so and also new apis will come soon crazy apis when i it a hurdle or sb in the communit its a hurdle an api will be made or if their is too much repetition of code

7. Official WhatsApp Channel

We're on WhatsApp now too — as a channel, not a group. Privacy matters, so no group chats where everyone can see each other. Just us posting updates you can read whenever.

💬 Join the WhatsApp Channel

Prefer to reach us directly? You can:

We actually respond. Come say hi.


The Quick Summary

WhatStatusWhen
Pipe/socket → WebSocket communicationTheory, not yet startedAfter cppws ships
Old binary + library still works✅ YesForever (don't npm update if happy)
cppws WebSocket libraryFinal polishThis Thursday/weekend
Nothing Runtime first phase✅ DoneTesting coming soon
Cookies/Storage/WhatsApp APIs❌ RemovedNext huge rewrite
Nothing Telemetry Browser💡 TheoryMaybe soon
YouTube channel✅ LiveNow
WhatsApp channel✅ LiveNow

Bottom Line

A lot is moving. None of it breaks what you have today — except the cookies/storage/WhatsApp APIs, which are getting removed. But honestly, they never worked properly anyway.

Keep your existing scripts running. Don't npm update blindly. Follow along on YouTube. And check in on the docs for cppws this week — that one ships soon.

One import. 20 lines. Go.


Nothing Blog. Part of the Nothing Ecosystem.

Built by Ernest Tech House · Kenya · 2026

Written on: 3rd July 2026

MIT Licensed | Built by Ernest Tech House · Kenya · 2026