I’m sharing mochi.js (https://github.com/0xchasercat/mochi), a Bun-native, raw-CDP browser automation framework. It's designed to make programmatic browser use more effective by focusing on consistency and measured parity with regular traffic, purely from the JS layer, against stock Chromium.

The most common forms of browser automation focus heavily on client-side line by line probes, which are mostly cosmetic. This makes people feel better but it doesn't have much relevance to actual WAF or anti-automation defences.

Mochi.js focuses on what actually matters, allowing you to get past captchas, WAF's and most defence mechanisms. In fact, in some cases it actually outperforms chromium forks simply by virtue of not having to lie.

The foundation is built on a probe manifest based on analyzing several WAF's and trying to cover most of the ground that matters, and from there building upwards while ensuring every decision is backed by data. Solves turnstile/interstitial automatically, single digit fpjs suspect score, very good client-side results, though browserscan and a few others are known limitations that are fundamentally conflicting with what WAF's probe for.

I'll be here if anyone wants to discuss the details, check out the docs and github. It's completely free and open source, MIT, strictly no relationship to any proprietary products whatsoever. No affiliation to patched chromium forks, or SaaS.

But I also want to talk about why I built this, because the current paradigm of "bot detection" is fundamentally broken.

Traditionally they would probably try to label my repository a malicious tool, or at best, a grey hat one.

Let's take Turnstile for example, If you attach a debugger to see what data they are extracting from your hardware, their script intentionally self-destructs. When they try to extract your data—acting as a guest on your silicon, using your electricity, without asking, the industry calls it "Security."

But if you write a script to control exactly what data your own hardware emits, refusing to provide the data they have no right to ask for, you are suddenly labeled a "Malicious Actor" engaged in "Bot Evasion."

I find it absurd we let ourselves put up with this, and the stance of the bot-evasion community only makes them feel more able to take a higher moral ground.

I have built a library that respects my hardware's reality. If that breaks your security model, that's because your security model relies on trespassing and secrecy. I stopped apologizing. Who's next?

Mochi is the exact opposite of WAF opacity. It is a glass box. It is MIT-licensed. The entire DAG, fingerprint manifest schema, harvesting process, is documented. We even commit our live benchmarks to the public record (mochi on a Linux datacenter IP scored a suspect_score: 8 and bot: not_detected against FingerprintJS Pro v4).

We don't even lie unnecessarily. We default to host-OS matching. If you run mochi on a Linux server, it uses privacy-sensible fingerprints for Linux, not Windows, because Linux is a real-user signal. It proves that WAFs aren't actually blocking what most people think they are, which begs the question of what they are really doing in that obfuscated payload.

The legitimacy argument is exactly how they captured the narrative. And nobody challenged it because the people on the other side were too busy acting like they were doing something wrong.

Is this a conspiracy theory? For sure, but only because they allow it to be. Try make a conspiracy theory about the sticky riceball.

Comments URL: https://news.ycombinator.com/item?id=48075059

Points: 47

# Comments: 20

I've - Replaced unsafe from_utf8_unchecked with safe from_utf8 - Added #![deny(unsafe_code)] at crate level - FFI module still allows unsafe (required for C ABI) - README now honestly says 'Safe Rust Core' instead of '100% Safe Rust'

Thanks to NitpickLawyer on HN for the callout

Like many of you, I watched ThePrimeagen’s recent video breakdown of Claude Code’s architecture (and Theo’s subsequent defense of React/Ink). The core of the debate—whether we should be shipping a Virtual DOM and a reconciliation engine just to render text to a terminal—stuck with me. Rather than just tweet about it, I decided to build an alternative in Rust to see what a modern, high-performance approach looks like without the web-tech overhead. Meet Flywheel. It’s a TUI compositor designed to be fast, lightweight, and capable of high frame rates without eating your CPU.

Repo: https://github.com/ccheshirecat/flywheel Crates: https://crates.io/crates/flywheel-compositor

Quickstart: cargo run --example streaming_demo --release

I’d love feedback on the architecture or thoughts from anyone else building TUIs in 2026.

Comments URL: https://news.ycombinator.com/item?id=46821804

Points: 1

# Comments: 2

so basically the link above is a fork of the chromiumoxide crate but with stealth patches implemented using rebrowser as a reference. it plugs runtime.enable and common automation flags, enforces some hardware consistency through profiles and has some convenience features and it's still early but for starters it can pass most of the common detection tests

i prefer writing my applications in compiled languages but recently been needing to go into browser automation more and more and always felt that the space for rust didn't have much of the variety that the node/python counterparts had, so this is my attempt to give some life to it, well to solve my needs at least, but i hope someone else finds it useful too!

i needed a stealth browser in rust because my need was mostly around captcha solving, so there's a turnstile solver here too and yeah i know there's a lot of them around but having it in rust allows me to integrate it into my application so much better and avoid the mess of so many external services

and yeah my use case required not only cloudflare but geetest too so i ported xkiann's python solver to rust too, with some modifications to make it deobfuscate automatically and added support for multi turn verification and user_info parameters for sites that need it

both solvers have C FFI bindings for integration with other languages!

https://github.com/ccheshirecat/chaser-oxide - chromiumoxide stealth fork https://github.com/ccheshirecat/chaser-cf - cloudflare solver https://github.com/ccheshirecat/chaser-gt - geetest solver

more details on the github repo, im falling asleep so goodnight HN and happy new year again much love to you all!

Comments URL: https://news.ycombinator.com/item?id=46459932

Points: 4

# Comments: 0

That’s what I wanted to fix.

I built something called the ProbablyFair Verifiability Layer (PF-VL). It’s an open standard that makes real fairness provable for any RNG-based game — slots, dice, plinko, whatever.

It doesn’t use a blockchain. It doesn’t use tokens. It’s just math.

Every bet carries a few guarantees:

1. The exact RNG code and parameters are published and hashed. 2. The game logic (payout tables, reels, etc.) is locked and verifiable. 3. Every bet is included in an append-only ledger with a proof. 4. Any player can replay and verify the result themselves. 5. Independent watchdogs can recompute everything continuously.

ProbablyFair doesn’t replace the casino’s system. It sits beside it. Operators don’t have to rebuild anything — just add a few calls to the SDK.

That’s it. Three API calls and one file hash.

If there’s a free, open, drop-in standard for provable fairness, then there’s no reason not to use it. Any casino that refuses is showing you something: they prefer a system where players can’t see what’s really going on.

If it’s fair, you can prove it. If you can’t prove it, it isn’t fair.

Technical bits: Core: Rust (verifier) SDK: Go (operator libraries) WASM: TinyGo (browser verifier) License: Apache-2.0 / CC-BY-4.0

Spec: https://probablyfair.org/specification | https://github.com/ProbablyFair/pf-specs/blob/main/PF-VL-1.0...

Repos: https://github.com/probablyfair/pf-core https://github.com/probablyfair/pf-sdk https://github.com/probablyfair/pf-wasm https://github.com/probablyfair/pf-specs

ProbablyFair Verifiability Layer (PF-VL-1.0) Every bet: committed, included, reproduced.

https://probablyfair.org

Comments URL: https://news.ycombinator.com/item?id=45534945

Points: 3

# Comments: 0

It supports cloud-init, GPU/VFIO passthrough (yes, you can run AI/ML workloads in isolated microVMs), booting Docker images via a plugin system, and Kubernetes-style deployments with replication, all from a single CLI(soon to be web UI, see next)

Coming soon: a built-in PaaS mode with snapshot-based cold start elimination, sort of like Dokploy, but designed for serverless workloads that boot from memory snapshots instead of containers.

Volant is intentionally a bit opinionated to make microVMs more accessible, but it’s fully extensible for power users.

Check out the README and the docs for more details.

It’s free and open source (under BSL), would love to hear feedback or thoughts from anyone!

tl;dr: 6-second GIF in the README shows the full flow: install → create VM → get HTTP 200.

Comments URL: https://news.ycombinator.com/item?id=45486006

Points: 6

# Comments: 0

Custom Nomad task driver that runs Cloud Hypervisor virtual machines natively, fork of the original virt-driver with support for cloud-init, VFIO passthrough, and full resource orchestration.

If you’ve ever wished Nomad could launch real VMs (not just containers) with the same declarative workflow, this closes that gap. It’s useful for anyone running high-isolation workloads, nested virtualization, or GPU-bound compute pipelines inside Nomad clusters. It's still got some rough edges but usable

github.com/volantvm/nomad-driver-ch

Under the hood: • Written in Go, implements full TaskDriver interface • Supports create/start/stop/destroy lifecycles • Cloud-init injection for userdata, networking, SSH • VFIO passthrough for direct PCI access

Would love feedback from Nomad operators or Cloud Hypervisor users especially around how you’d use this in your stack.

Comments URL: https://news.ycombinator.com/item?id=45480523

Points: 1

# Comments: 0

Infuze was ours but has since been shut down so we can focus fully on our own architecture. There has never been any scam, nor anything remotely related to one.

The Show HN post about the lightweight VM manager is unrelated to any cloud business. It started as a quick personal tool and unexpectedly resonated with people, so I iterated on it the same day. It’s just a minimal Go wrapper around libvirt, not connected to our core work.

Comments URL: https://news.ycombinator.com/item?id=45154857

Points: 144

# Comments: 41