Valve's P2P stack has been broken for 2 months. Nobody at Valve is answering.

What happened

GitHub issue [#398](https://github.com/ValveSoftware/GameNetworkingSockets/issues/398) on `ValveSoftware/GameNetworkingSockets` has been open for more than two months. The report is specific: P2P connections that route through Valve's Steam Datagram Relay (SDR) fail during the handshake phase for a non-trivial subset of users. Reproductions span Windows and Linux, multiple ISPs, and both shipping titles and hobbyist projects built on the library. The thread has accumulated dozens of "me too" comments, packet captures, and at least one minimal repro.

What it has not accumulated is a single response from anyone with a @valvesoftware commit bit. The last substantive maintainer activity on the repository is months old. Pull requests are stacking up. The CI badge still says green. The library, by every external signal, looks abandoned — except it is the networking foundation under Counter-Strike 2, Dota 2, and a long tail of indie multiplayer games that adopted it precisely because Valve open-sourced it in 2020 with the implicit promise that it was the same code running their billion-session-a-year matchmaking infrastructure.

The practical impact is uneven but real. Some users connect fine. Others get stuck at the relay-selection step and fall back to direct connection, which fails behind symmetric NAT — exactly the case SDR exists to solve. For shipping games, this manifests as "some of my friends can't join my lobby." For indies who built their entire netcode on `ISteamNetworkingSockets`, it manifests as a support inbox they can't drain.

Why it matters

The interesting question isn't "why is Valve slow to respond to a GitHub issue." Valve is famously slow to respond to everything. The interesting question is what `GameNetworkingSockets` actually *is* as a dependency, and what its abandonment-shaped silhouette means for anyone who bet on it.

GameNetworkingSockets is not a normal open-source library. It's a client SDK for a proprietary service — Valve's global relay network — wearing the costume of a self-contained networking stack. You can technically use it in pure peer-to-peer mode without SDR, but nobody does, because the entire reason to pick it over [ENet](https://github.com/lsalzman/enet), [GameNetworkingSockets](https://github.com/ValveSoftware/GameNetworkingSockets)'s spiritual predecessor, or rolling your own QUIC layer is the relay network. NAT traversal is the hard problem. Valve solved it once, at scale, and gave away the client. The server side — the thing that actually makes P2P work in 2026 — remains Valve's.

This is the same architectural shape as Firebase, or Twilio's client SDKs, or any of a dozen other "open source" projects whose value is gated behind a service the maintainer controls. The difference is that Firebase has an SLA and a support portal. `GameNetworkingSockets` has a GitHub issue tracker and the hope that someone at Valve still cares.

The community reaction has been telling. The HN thread that surfaced this (60 points, climbing) is full of game devs saying some version of "I knew this would happen eventually, I just didn't think it would happen this quietly." One commenter notes that Valve's open-source contributions follow a consistent pattern: enthusiastic initial release, two or three years of active maintenance, then a slow fade as the original author moves to a different team inside Valve. [Source SDK](https://github.com/ValveSoftware/source-sdk-2013), [VOGL](https://github.com/ValveSoftware/vogl), and the Steam Linux Runtime have all walked this arc. The library isn't dead. It's just orphaned in the specific Valve way where nobody will ever officially say so.

Compare this to the alternatives. [GameNetworkingSockets](https://github.com/ValveSoftware/GameNetworkingSockets) competes with [Photon](https://www.photonengine.com/), Epic's [EOS P2P](https://dev.epicgames.com/docs/game-services/p-2-p), [Nakama](https://github.com/heroiclabs/nakama), and increasingly [Edgegap](https://edgegap.com/) for the multiplayer-backend slot. Photon and EOS are also vendor-controlled, but they bill you and answer your tickets. Nakama is genuinely OSS with a company behind it that ships releases on a schedule. Rolling your own on top of [quinn](https://github.com/quinn-rs/quinn) or [WebRTC](https://webrtc.org/) is more work but leaves no single point of maintainer failure.

What this means for your stack

If you're shipping a multiplayer game today on `ISteamNetworkingSockets`, the immediate move isn't to rip it out. The immediate move is to audit how much of your netcode assumes the relay network is healthy, and to build a fallback path that doesn't. That probably means a direct-connection mode with your own STUN/TURN, even if it's degraded — because the failure mode of "Valve's relay handshake hangs and nobody is fixing it" is exactly the kind of dependency risk that doesn't show up in your architecture diagram until it does.

If you're picking a multiplayer stack for a new project, the calculus changed two months ago whether you noticed or not. The argument for `GameNetworkingSockets` was always "it's what Valve uses, so it'll be maintained forever." That argument is now empirically weaker. The argument for Photon is "someone will answer the phone." The argument for Nakama is "the source actually solves your problem without a hidden service." Both have gotten stronger by default.

And if you're a Steamworks partner specifically, the political read is worth doing. Steam's matchmaking is a strategic asset for Valve; the open-source client SDK is not. A two-month silence on a P2P-breaking bug suggests the team that owns the client-side library is either tiny or reassigned. Either way, the gap between "Valve's internal networking team" and "the people who answer GitHub issues about Valve's networking library" is wider than the marketing implied.

Looking ahead

Valve will probably fix this. They usually do, eventually, and the bug is concrete enough that someone will get annoyed and land a patch. But the shape of the silence matters more than the eventual fix. `GameNetworkingSockets` was sold to the indie community as a peer — as the same code Valve runs, available to you, with the implicit guarantee that comes from a vendor eating their own dogfood. That guarantee has a half-life, and it's shorter than the lifecycle of a multiplayer game. Plan accordingly.