A from-scratch C++ kernel just hosted a real, unmodified Node.js Discord bot — and it works. The bot connected to the live gateway, authenticated, took a message from a human, asked a language model, and posted the answer back into the channel. Getting here meant a deliberate fork in the road — build the bot into the kernel, or let real Linux software do it? — and then the quiet satisfaction of watching a 37 MB runtime load off a hand-written filesystem and just... run.

Two Roads to Discord

The session opened still chasing a fully native path: a WebSocket-over-TLS client baked into the kernel and handed to ring-3 programs through new syscalls. That work shipped (more below), and it's genuinely useful — but partway through came the honest question: why reimplement Discord's entire client when Node.js already runs on JefeOS and discord.js/ws exist? The answer settled the architecture. Keep the kernel minimal — TCP and TLS — treat WebSocket as a generic, reusable layer, and let the Discord-specific churn live in a userspace package: Node as the daily driver, native as a lean optional showcase. When Discord changes their API you npm update, you don't re-engineer a kernel.

The Native Half We Kept

The native WebSocket work still landed, across three dual-reviewed pull requests: a syscall ABI (connect / send / recv / status / close) wrapping the kernel's TLS transport, a receive-frame queue the kernel fills and userspace drains, and a hardening pass that closed a frame-loss edge case before anything leaned on the ring. A code review and a security review signed off each one — the new ring-3-to-ring-0 surface matches the kernel's existing memory-safe pattern for validating user pointers. A small ring-3 program then used it to reach Discord's gateway with zero Linux compatibility in the loop: the Hello frame, a heartbeat sent, and the gateway's acknowledgement back. That's the reusable primitive banked. The bot itself took the other road.

JefeOS-Bot, Live

With the architecture decided, we brought up the real thing. A 37 MB Node.js runtime loaded off the hand-written filesystem, require()'d its actual node_modules, opened TLS plus a WebSocket to gateway.discord.gg, sent IDENTIFY, and went READY in the server. A human typed in the channel; the bot caught the message event, called out to a local language model, and posted the reply — HTTP 200, three times over. Two full heartbeat cycles acknowledged, zero reconnects, a clean two-minute soak. A hand-rolled kernel held a live, authenticated, LLM-backed chat bot together under real traffic and didn't flinch. (Its credentials, for the record, never touch the repo.)

The Brain That Credits Google

The best bug isn't a bug. Asked "what OS are you running on?", the bot answered with total confidence that it runs on "large-scale distributed computing infrastructure managed by Google." That's the language model talking — its training has no idea it's currently living on a hobby kernel in a VM. It's also the serious point wearing a clown nose: a heavyweight runtime like Node is the best stress test this kernel has. Every previous time Node ran hard on JefeOS it surfaced real defects — deep-stack overflows, memory-reclamation leaks, teardown wedges — that then got fixed. A featherweight native bot would never have found them. Running the real thing is the stability work.

What's Next

• Cut a proper version bump and a stable branch — this run is the milestone worth stamping.
• Stand the bot up as a long-lived background daemon on a dedicated VM, so it soaks for days while kernel development continues undisturbed on the dev box.
• Keep the native WebSocket client parked as the lean, no-runtime-required option for when footprint matters more than feature breadth.