Discord-PXE
Discord-PXE is a bare-metal x86-64 Discord Gateway runtime that boots over legacy BIOS PXE and reaches Discord without a conventional operating system underneath it.
The target runtime owns the entire path:
BIOS PXE
↓
stage-1 loader
↓
runtime.bin
↓
x86-64 long mode
↓
native Realtek networking
↓
IPv4 / DNS / TCP
↓
TLS 1.2 / X.509
↓
WebSocket
↓
Discord Gateway
↓
local shard pool
There is no Linux, Windows, libc, OpenSSL, curl, Node.js, or Discord SDK on the target.
The current main branch has completed a 128-shard READY bring-up on real hardware in stable BSP scheduler mode, including per-shard TCP/TLS/WebSocket/Gateway state and reconnect/backoff recovery.
Parallel AP/SMP shard-state execution exists in the tree but remains disabled by default while shared crypto scratch and native TX ownership are being validated under concurrent execution.
What the project currently proves
Boot and machine bring-up
- legacy BIOS PXE entry
- PXENV+ discovery
- cached DHCP handoff
- TFTP runtime loading
- x86-64 long-mode transition
- E820-backed memory setup
- SMP/AP startup
Native networking
- supported Realtek hardware path
- ARP
- IPv4
- DNS
- TCP to Discord Gateway
Security transport
- RDRAND-backed randomness
- X25519
- SHA-256 / HMAC / TLS PRF
- AES-GCM
- RSA verification
- local X.509 chain verification
- authenticated TLS 1.2
Discord
- HTTP 101 WebSocket upgrade
- Gateway Hello
- Identify
- READY
- heartbeat / ACK lifecycle
- isolated shard contexts
- full 128-shard stable BSP bring-up
Why this project is unusual
Most Discord clients start with:
operating system
-> socket API
-> TLS library
-> WebSocket library
-> Discord SDK
Discord-PXE starts much lower:
firmware
-> physical memory
-> NIC
-> packets
-> crypto
-> protocol state
-> Discord
That means failures which would normally be hidden behind an OS or library are part of the project itself: packet construction, TLS transcript state, certificate verification, heartbeat timing, memory ownership, CPU concurrency, and network-device behavior.
Where to start
Build and boot
Set up the token, build the PXE images, refresh the PXE server, attach serial, and prove the singleton runtime.
Validate hardware
Follow the current regression ladder from PXE/TFTP through singleton Discord and the hardware-proven 128-shard BSP baseline.
Understand sharding
Learn the difference between global and local shard ownership, stable BSP scheduling, experimental SMP execution, Identify gating, and reconnect behavior.
Understand the system
See the boundaries between stage 1, long mode, SMP, networking, TLS, Gateway state, local contexts, and controller ownership.
Debug failures
Classify problems by the last successful layer instead of guessing from the final error line.
Go low-level
Assembly-first implementation docs with NASM, execution-order traces, Rust/C/Python translations, context tables, and optional code examples.
Stable vs experimental
| Area | Current status |
|---|---|
| PXE/TFTP boot | Hardware-proven |
| x86-64 transition | Hardware-proven |
| AP startup / worker dispatch | Hardware-proven |
| native Realtek networking | Hardware-proven |
| singleton Discord Gateway | Hardware-proven |
| 128-shard BSP scheduler | Hardware-proven |
| shard reconnect/backoff | Hardware-proven |
| AP/SMP shard execution | Experimental |
runtime /gateway/bot discovery | Not yet complete |
| production Resume lifecycle | Incomplete |
| live controller integration | Ongoing |
| authenticated controller transport | Not yet production-ready |