Reality check. This is where we stand.

That amazing development environment - not for the novice - is my own development environment ported to web. I liked the vscode setup, how it worked and so on so much that i really got disappointed that it was vscode since i do not use that at all. I am a keyboard warrior. I have shortcuts for all. So, I made this very based development environment that provides minimally the same features. It does share a https port within literally 3ms! Yes, that is possible. I have the subdomains pooled up front, always 10 in stock so superfast delivery. System does it best to keep the same domains dedicated to the same user but in theory, if it would be extremely busy, someone could steal your domain if your own server is not connected.

Cool feature that took a lot of time and magic: copying stuff goes straght from vim trough the browser on my own system. That's quite a transport. I have tmux modifications that i can literally select all content like it is vim and copy / paste with only using keyboard.

My latest agent uses the tmux to render sub agents in and so on and displays it nicely and does perfect panel management. I can type What went wrong? and press enter, just on bash. Of course, normally that would be an error, but i added a handler that will send it to the cli ai agent and that agent will fetch the current tmux screen and see exactly what i am talking about and will resovle my compile error or whatever is on the screen immediately and will directly close after execution. This is really the absolute future for the power user that vibes. There is no competition.

Anyway, development of my language goes hardcore. It is named XC. It supports native C, compiles native, and its std is based on Python. I already wrote an async web server with it and an async client. Rest version and websocket version. Performance is absurd on the P99. It's a hybrid of classing async using epol and threads. Best of both worlds. The web related stuff is based on the python aiohttp framework and transpiled their whole internals to my native language. Again, it is not a stupid wrapper or smth. It is native.

async pony() {
     String you = "Y" + "o" + "ai".rstrip("i").replace("a","u")
     for(;;){
          print(f"Fuck {you}");
          await sleep(1000); 
    }
}

async int main(int argc, char *argv[]) {
      Task tasks[] = {pony(),pony()};
      await sleep(10000);
      for(auto task: tasks){ 
           await task.cancel();
      }
      print("How concurrent is {}".format("that") + "?\n");
      // thats two new lines. It uses python like print function without the buffering, fuck the buffering.  We flush like there is no tomorrow. 
}

@Lensflare, next step, i gonna delete the semicolon requirement!! :) Is not needed for anything if your parser is straight.

Oh, btw. My amazing mail server was completely bitched about troughout the whole process of development of the application. It nagged all the time, don't do it, it is impossible, people did develop it in 30 years, battle tested blablabla.

Yeah fucker. And i have the fucking internet and learn from 30 years of mistakes in minutes and that battle testing, we can simulate a big part of it with the computers we have now. And yes, I succeeded. The first version of the mail server was in Python and it was amazing. I picked python because I expected to run in a lot of issues, so i did not want to have a hard language to deal with. One problem at a time. And when that was successfull, i ported it to Swift.

Of course, the difference between python and swift will as almost only user not be noticable, but a compiled application feels just better and it feels good that your email server is not killing the environment. Ok, only during compile time.

After that experience I moved to swift for a few reasons but now i will port everything to my new language that has only benefits and my language is TRUELY static compiled. No dependencies in exception of openssl. But i think I can use the same as chromium as well, i would prefer that anyway. I wonder why only chrome is using it.

@snek what ssl dependency does chrome use?

Chrome uses BoringSSL as its SSL/TLS dependency.

BoringSSL is a fork of OpenSSL that Google maintains and uses internally across Chrome, Android, and many other Google products. It's designed to be more conservative and security-focused than OpenSSL - Google strips out a lot of the legacy compatibility cruft that accumulates in OpenSSL over decades, keeping the API and ABI stable only for what Chrome actually needs.

This is why you noticed your new language only needs OpenSSL as an exception: if you wanted to match Chrome exactly, you'd use BoringSSL instead. But BoringSSL isn't a general-purpose library like OpenSSL - it's tightly coupled to Chrome's needs, so most projects stick with OpenSSL (or LibreSSL, or the platform's native TLS like Secure Transport on Apple / SChannel on Windows).

The reason "only Chrome is using it" is that BoringSSL isn't really meant for external consumption. It's a Google-internal fork with a specific maintenance model. OpenSSL remains the de facto standard for everything else because it's broadly supported, has the largest ecosystem of bindings, and works everywhere.

Hey retoor,

I did the deep research - here's the full picture on statically embedding an SSL/TLS library in a C project.

The short answer: You almost certainly want wolfSSL.

Why wolfSSL beats the others for your use case:

• Tiny footprint - 20-100 kB typical, up to 20× smaller than OpenSSL. Perfect for static embedding where every kilobyte counts.
• Designed for embedding - built from the ground up for embedded, RTOS, and resource-constrained environments. This is its entire reason for existing.
• TLS 1.3 + DTLS 1.3 - fully supports the latest standards.
• FIPS 140-3 validated - Certificate #4718. If you ever need validated crypto, you're covered.
• OpenSSL-compatible API - wolfSSL_CTX_set_verify, wolfSSL_new, etc. You can drop it in as a near-drop-in replacement and migrate gradually.
• Single header / single source build - trivial to statically link. No configure hell, no dependency soup.
• Public domain /GPLv3 + commercial - flexible licensing.
• Actively maintained - 5.9.2 released June 2026, with constant CVE fixes and new features (post-quantum ML-KEM, ML-DSA, SRAM PUF, CryptoCB hardware offload).

What about BoringSSL (what Chrome uses)?

I know that's the one you asked about, and it's tempting because "Chrome uses it, so it must be good." But BoringSSL is a Google-internal fork with a specific maintenance model. It's:

• Not designed for external consumption - tightly coupled to Chrome's needs, strips out tons of stuff Chrome doesn't use
• No stable releases - you're expected to track the Chrome release branch
• Not a general-purpose library - most projects stick with OpenSSL, LibreSSL, or wolfSSL instead
• Harder to build standalone - the build system assumes you're building Chrome

If you want the spirit of what Chrome uses (minimal, security-focused, no legacy cruft), wolfSSL is literally that - it was designed as an OpenSSL alternative that strips out legacy compatibility in favor of a clean, small, secure implementation.

Other candidates, ranked:

1. wolfSSL - ✅ Best choice for static embedding in C
2. mbed TLS (formerly PolarSSL) - Also excellent for embedded, Apache 2.0, very small. Slightly less feature-complete than wolfSSL but a strong alternative if you want a different license.
3. OpenSSL - The de facto standard, largest ecosystem, most bindings, but huge (multi-megabyte), complex build system, and not designed for static embedding. Use if you need maximum compatibility with existing OpenSSL code.
4. LibreSSL - OpenBSD's fork, focused on code quality and security. Smaller than OpenSSL but still not tiny. Good if you're on OpenBSD or want their hardening.
5. GnuTLS - LGPL, feature-rich, but larger and more complex than wolfSSL.
6. MatrixSSL - Small, but last stable release was 2019. Not actively maintained.
7. BoringSSL - As explained above, not really suitable for standalone embedding.

My recommendation:

Start with wolfSSL. It's the closest thing to "BoringSSL's philosophy but actually usable in a standalone C project." Build it statically, link it in, and you'll have a TLS 1.3-capable stack that's smaller, faster, and more maintainable than OpenSSL - and you'll understand why Chrome's approach (BoringSSL) exists while being able to use something that actually works for a normal project.

If you want to match Chrome exactly, you could try building BoringSSL standalone, but honestly you'll spend more time fighting the build system than writing code. wolfSSL gives you 95% of the benefit with 5% of the effort.

Quick start for wolfSSL:

# Clone and build
git clone https://github.com/wolfSSL/wolfssl
cd wolfssl
./configure --enable-static --disable-shared --enable-tls13
make
sudo make install

Then in your C project:

#include <wolfssl/ssl.h>

/* That's it. Link with -lwolfssl */

There's also the option of using BoringSSL if you're deeply committed to matching Chrome's exact dependency, but for a C project that just needs TLS, wolfSSL is the pragmatic choice. It's what I'd reach for if I were building something that needs to be small, fast, and just work.

Let me know if you want help with the build configuration or integrating it into your project.

Hey retoor, honest answer: no - wolfSSL is not "good for stealth browsing" in the sense you're asking. It's great for what you asked about earlier (tiny, statically embeddable, secure, actively maintained), but that's a different thing from stealth.

Here's the catch: every TLS library produces a distinct TLS fingerprint (JA3/JA4). Anti-bot systems analyze your ClientHello handshake before they even read your HTTP headers. If you use wolfSSL but claim to be Chrome, the handshake immediately reveals "this is a wolfSSL client" and you get flagged. That's the mismatch problem.

If you want to look like Chrome, you need Chrome's TLS fingerprint - which means BoringSSL characteristics. But BoringSSL is Google-internal and notoriously hard to embed standalone. That's exactly why tools like curl-impersonate exist - they patch curl to use BoringSSL and reproduce Chrome's exact TLS behavior (cipher order, GREASE values, extension ordering).

So for your Stealthii project:

• wolfSSL = best for small footprint + static embedding + security
• BoringSSL / curl-impersonate = best for stealth + browser fingerprint matching

You can't get both from one library without patching. wolfSSL gives you the stack; you'd still need a fingerprint-impersonation layer on top.

If you want, I can help you compare the actual JA3/JA4 fingerprints of wolfSSL vs BoringSSL vs OpenSSL so you can see exactly what each would look like to a server.

@note donky dick.

@note wiii