Open Source,Remade with Rust

Moonlight is the open-source implementation of NVIDIA's GameStream protocol — the client that lets you stream a PC game session to a phone, tablet, Steam Deck, set-top box, or any other device on your network. It is excellent software, and like most game-streaming clients, it is written in C and C++ across a decade of accumulated networking, decoder, and input-handling code.

Starfire is the same idea, rebuilt from the ground up in Rust. The protocol surface stays compatible so existing GameStream hosts and Sunshine servers keep working, but the entire client — packet parser, video decoder bindings, input pipeline, network state machine — is memory-safe by construction. The classes of bug that historically ship as CVEs in game-streaming clients (buffer overflows in RTP parsing, integer overflows in frame-size handling, use-after-free in the decoder lifecycle) never compile in Starfire.

Built for the same hardware Moonlight runs on — desktop, mobile, embedded — with the same low-latency target. Active development; star the repo to follow along.

OAuth, OIDC, Auth0, Clerk, Firebase Auth — every off-the-shelf "Sign in with X" button on the web routes through a third-party provider you have to register with, configure client IDs for, and pay a per-monthly-active-user fee to once you cross their free tier. The provider sees every login, every site, every time.

Sovereign ID flips the model. The user's identity is a keypair on their own device; sign-in produces a token they cryptographically sign, and your backend verifies it entirely locally — no fetches to MATA, no JWKS endpoint, no DID resolver to call. Four npm packages cover the surface: browser SDK, backend verifier, statement verifier, and React bindings. MIT-licensed, zero external dependencies.

Live integration documented in the Freedom Guide. Powers the Sign in with Sovereign ID button you can drop onto any website with one component and a backend verifier call.

Most Rust web stacks today verify identity tokens by talking to an external authority — Auth0's JWKS endpoint, Clerk's verification API, AWS Cognito's token introspection. Every login is an extra round-trip out to a third party, and every outage on their side is an outage you inherit.

mID is the Rust counterpart to the Sovereign ID JavaScript verifier. A user's identity is a keypair they hold on their own device; sign-in produces a token that mID verifies entirely in-process — no I/O, no JWKS, no DID resolver. Works natively on every Rust target and via WebAssembly where native won't run. Dual-licensed Apache-2.0 OR MIT.

Pairs with the sovereign-id JavaScript SDK on the client — both speak the same wire format. Drop mID anywhere you would have called Auth0: Axum middleware, Actix extractor, an edge function, a desktop app. The verification stays in-process, the user stays in control of the keypair.

Cloud databases — Firebase, Supabase, DynamoDB, Postgres-on-RDS — assume always-on infrastructure, a single source of truth that lives in a data center, and a network round-trip for every read and write. The model breaks the moment a user goes offline, the network partitions, or the data needs to live near someone instead of in a US-East-1 rack.

SpaceDB is the opposite: a local-first database that stores encrypted app data across machines near the users who own it, with automatic CRDT convergence when replicas reconnect and offline-first operation by construction. Per-field consistency tiers (convergent, causal+, strong) so a single schema can mix eventual and strong consistency where each fits. Capability-based access control with expiry and budgets, built-in vector search that keeps the corpus local, deterministic compute-to-data with attestation, and honest freshness reporting.

Pluggable transport, storage, and crypto seams — operators implement whatever fits their environment, and no SpaceDB crate depends on any proprietary code. Dual-licensed Apache-2.0 OR MIT, free to embed in applications and run on personal devices indefinitely.

x264 and Cisco's openh264 are the two libraries every browser, every video conference, and every streaming app reaches for when it needs H.264. Both are massive C/C++ codebases, and between them they account for a long catalogue of CVEs in bitstream parsing, buffer handling, and motion-compensation arithmetic. Every app that links them inherits that surface.

rusty_h264 is a clean-room ground-up rebuild in pure Rust. The codec core is marked #![forbid(unsafe_code)] — zero unsafe blocks, no C in the dependency tree, no FFI. Bit-exact decoding against ffmpeg across the entire QP range (0–51) for both intra and inter frames, with rate control and motion compensation in the encoder. Constrained Baseline Profile today, with room to grow.

BSD-2-Clause licensed — permissive enough to embed in any product, no copyleft strings. Built specifically to be the codec layer for memory-safe video pipelines: the Comet host, the Starfire client, browser-side decoders, anything that should not ship a 25-year-old C buffer parser into 2026 production.

FFmpeg is the swiss-army knife of media — decode, encode, transcode, mux, probe, repackage just about any audio or video format ever shipped. It is also one of the largest C codebases in continuous production use, with two decades of CVEs in bitstream parsers, container demuxers, and codec arithmetic. Every browser that ships hardware video, every streaming service, every social media app depends on it — and inherits that surface.

ffmpeg (the remade_ffmpeg_rs repo) is a ground-up clean-room rebuild in safe Rust — not a wrapper around the C library, an entirely new codebase using the same wire protocols and file formats. The CLI is drop-in compatible: ffmpeg -i in.mp4 -c:v libaom -c:a libopus out.webm works the same way against upstream FFmpeg flags, plus an ffprobe binary for inspection. Image codecs (AVIF, PNG, JPEG, WebP, GIF, JPEG XL), audio (Opus, AAC, FLAC, Vorbis, PCM), video (AV1, H.264, VP9), and containers (MP4, WebM, AVI, WAV, OGG) all flow through one safe-Rust pipeline.

Apache-2.0 throughout the core library, CLI, and server — no GPL or LGPL dependencies, embeddable in closed-source products without the copyleft tax that upstream FFmpeg's GPL build carries. Pre-1.0; codec coverage and performance targets are still being filled in, and the project is honest about being engineering-target rather than independently audited. A subset of FFmpeg today, with the foundation in place to grow into a full replacement.

Sunshine is the open-source streaming host that powers most self-hosted GameStream setups today — capture the desktop, encode it with whatever hardware is available, deliver frames to a Moonlight client elsewhere on the network. It is GPLv3, written largely in C++, and carries the memory-safety surface that comes with that lineage.

Comet is the same role, rebuilt from scratch in Rust. Hardware-encode-first across NVENC, AMF, QuickSync, and VideoToolbox; a zero-copy capture-to-encode pipeline that keeps frames on the GPU; the same GameStream wire protocol so existing Moonlight clients keep working, plus a Comet-native mode that pairs with Starfire for the lowest end-to-end latency on the stack.

Measured against Sunshine + Moonlight on identical hardware: 2.1× better host latency, 3.8× better decode latency, and a sub-millisecond capture path. Shipping target is Windows desktop and gaming workloads first, with macOS host support tracking VideoToolbox.

Comet is MATA's proprietary host implementation. The Starfire client and shared protocol crates remain open source; the host stays in-house.