Author of low-level libraries for Node.js. Pure-JavaScript implementations of core internet protocols - QUIC/HTTP3, TLS, DNSSEC, STUN/TURN, WebRTC, SMTP - alongside supporting libraries for real-time media, data formats, storage, and runtime utilities.

They share a single principle: every layer of the stack should be controllable from code. The protocol becomes a function you write, not a config you maintain.

Most of these libraries are built on each other. Two small foundations sit under everything secure: cryptographic-formats parses certificates and keys, and lemon-tls provides TLS and DTLS to every protocol that encrypts.

graph TD
  sfu[sfu-server] --> webrtc[webrtc-server]
  sfu --> rtp[rtp-packet]
  stable[stable-webrtc] -.->|Node.js binding| webrtc
  stable --> litepack
  stable --> delta[compact-delta]

  webrtc --> rtp
  webrtc --> turn[turn-server]
  webrtc --> tls[lemon-tls]
  webrtc --> ranges[flat-ranges]
  webrtc --> formats[cryptographic-formats]
  webrtc --> mp[media-processing]
  rtp --> ranges

  turn --> tls
  turn -.->|mDNS candidates| mdns[mdns-local]
  turn -.->|port mapping| pm[port-mapper]
  pm -.->|reachability checks| turn

  moq[moq-transport] -.->|WebTransport binding| quico
  dns[dnssec-server] --> quico
  dns --> tls
  dns --> formats
  quico --> tls
  quico --> ranges
  quico --> formats

  email[email-server] --> tls
  email --> ranges
  email --> formats
  cert[cert-manager] --> formats

  tls --> formats

  classDef base fill:#fde68a,stroke:#b45309,color:#1f2937
  class tls,formats,ranges base

_{Solid arrows are dependencies a library needs to load. Dashed arrows are optional: turn-server and port-mapper load each other, mdns-local included, only when the feature is used; stable-webrtc runs on webrtc-server as its Node.js binding; and moq-transport ships a binding for quico's WebTransport server. Highlighted libraries are the shared foundation.}

The libraries are built to stack. A few combinations that work well together:

Self-contained edge server - quico + lemon-tls + cert-manager + dnssec-server Terminates HTTP/3 with keys you control, issues its own certificates, and answers DNS for its own zone. Geo-routing and health-driven failover become if statements in the query handler.

Peer-to-peer media without external infrastructure - webrtc-server + turn-server + port-mapper + rtp-packet Relays when NAT requires it, opens a direct path when it doesn't, and gives your handler every RTP packet in between.

LAN-first application - mdns-local + port-mapper + uni-indexeddb Discovers peers on the local network, maps its own ports outward when it needs to be reachable, and stores state with one API on both sides of the wire.

Running nginx, BIND, Postfix, or coturn next to your Node.js application is the standard answer - but it limits you to what their configuration files allow, makes the system hard to extend in directions the original authors didn't anticipate, and puts a process boundary between every layer. Each library here removes that compromise. DNS records are computed at runtime per query, cryptographic keys are held in your own code, every packet is visible to your handler.

The libraries are also intentionally narrow. Each one implements its protocol and stops there. Every decision the protocol doesn't dictate - storage, business logic, signaling transport, architectural choices - stays in your code. They are libraries to compose, not frameworks to inherit.

When that's true, infrastructure stops being something you assemble around your code and becomes part of it. A two-person team can ship a system that used to require a dedicated SRE. Edge deployments don't have to ship without DNS, mail, or media handling. Geo-routing, canary releases, and health-driven failover stop being managed-service features and become a few lines of JavaScript. When something fails at the protocol level, you read source - your source. That's the Node.js these libraries are working toward.

Building production-grade implementations of the entire internet stack in pure JavaScript is more work than one person can finish alone. These projects benefit from anyone willing to read an RFC closely, find the edge case nobody else has hit, or push a library in directions the original draft never imagined. Issues, pull requests, and design discussions are open on every repository - particularly welcome from protocol implementers, security researchers, and engineers running these stacks in production.

If your team relies on any of these libraries, sponsorship through GitHub Sponsors supports continued development and maintenance.