Bloqr AI: A new form of internet privacy and security, vastly simplified. Entering open beta soon.

This is the core component architecture for just the backend https://bloqr.dev package, which is just one of several packages that will make up the entire Bloqr AI application once they are wired together. Today I completed the rest of the final architecture now that the backend is largely feature complete, though still lots of bugs to work through. The rest of the coding will be extremely simple compared to the compiler. I estimate I’m about 75% done, aside from testing. The only major package left is the client/device software 🙂

This is why software architecture is hard. Coding is the easy part, but designing how each component interacts with one another while ensuring they are reusable is what makes software engineering such a difficult discipline. Software architecture has been described as building a skyscraper starting with the top floor, in mid-air, with constantly changing requirements.

My final systems architecture is as follows. You only need the client software to interface with Bloqr AI, but installation is flexible depending on the type of user. For regular users, the client and proxy are bundled together, and the façade can be installed basically anywhere, though by default it’s on the device. For technical users, you can install the proxy and façade in any type of hosted service for flexibility, airgapped solutions, etc.

• bloqr-compiler: Backend components that run the core systems, hosted in Cloudflare and edge-native. Written in Rust and Typescript (Dependency graph pictured below, Rust components not pictured.) Some open source for basics, everything else is proprietary. Roughly 750,000 lines of code (600,000 typescript, 150,000 server-side Rust web assembly). This also includes the Admin Panel which I was initially going to make a separate package but that adds needless complexity, so it’s a monolith.
• bloqr-façade: A thin wrapper that communicates directly with the bloqr-proxy, provided as both Rust and .Net libraries. This is for non-developer use, and serves as the two way “traffic cop” to direct traffic between the server and the client, and wraps the web APIs on the server. (this code is auto-generated and not written by hand.) Open Source. 50,000 lines of code.
• bloqr-proxy: The “glue” that ties the façade to the server and client using the façade as a two-way intermediary. This is the only component that’s forked, though it’s heavily customized (from Brave’s Rust Proxy.) Open Source. Around 100,000 lines of code.
• bloqr-client: Client software that runs on your device, surfaces the UI. This communicates directly with the bloqr-proxy. Written in various languages depending on the device (e.g. Mac, Windows, Mobile, etc.), with universal binaries in Rust and .Net. There’s a hosted web version written in Typescript for zero-touch installations, compiled to client-side rust web assembly. Closed source and proprietary, obfuscated. No idea on lines of code yet as this is the last piece to write. The total size of the client software will be tiny and utilize very little resources since it runs in the background. The client will also include UI interfaces to 3rd party vendors (e.g. AdGuard, NextDNS, Pi-Hole, Cloudflare, etc) though those are paywalled. Basically, a completely self-contained single pane of glass supporting all major vendors, vastly simplified for regular users. Advanced features are available for developer licenses.

Standalone libraries and infrastructure components:

• Not pictured is all of the Cloudflare infrastructure code for things like databases (of which there are about a dozen), queueing, workflows, logging, AI, Cloudflare services, etc. All of that code is super closed source. This isn’t a package so much as a set of libraries that interface with Cloudflare on the server.
• bloqr-sdk: This package encompasses the developer SDKs (software development kits) for developers to provide their own customizations and enhancements for the façade, proxy, and client packages. It roughly parallels the façade, albeit with lots of developer options. Most of this code is generated via various prebuilt packages, but allows developers to customize nearly every aspect of the non server code, without having to touch the source code since my open source code does not allow modifications.

The communication flow is:
[Cloudflare] compiler [Middleware] façade/sdk [Device] proxy <– [Device] client

Developers would use the SDK to hook into the middleware and device packages. The SDK also allows bypassing the web APIs to run code locally, albeit with higher licensing fees. You would use the SDK as well if you wanted to rewrite your own backend for a different cloud provider, but only enterprises and vendors would be interested in this very advanced usage scenario, and I’ll charge through the nose for it but also plan to provide custom consulting. I don’t expect to have more than a handful of users even interested in this.

Security is handled by better-auth, email services are handled by Resend, and runtime support is handled by Grafana, Sentry, and a handful of other hosted services. The core backend DB is PostgreSQL hosted on Neon. Validation is handled by Zod, routing is handled by Hono, API layer is handled by tRPC. The web UI is written in Angular 21/Typescript with Tailwind and Vite providing support functionality. Standalone client libs are TBD since they’ll vary per platform.