The design space for decentralized social networking keeps producing the same fundamental split: either you accept persistent servers as necessary infrastructure (ActivityPub, Matrix), replace servers with relays (Nostr), or try to build on top of what the web already provides without adding stateful processes. s@ (satproto) takes the third path, building social networking primitives on static files served over HTTP.
The Show HN post gathered 386 points and 182 comments, which tracks with a broader frustration in the decentralized social space: every major attempt at federation has quietly reintroduced the server, just under different management.
Why Static Hosting Changes the Equation
Static files in 2026 is a different proposition than it was even five years ago. GitHub Pages, Cloudflare Pages, Netlify, and similar services let you serve files from a global CDN at effectively zero cost. A static site offers extremely reliable, cheap, and scalable delivery. The question s@ asks is whether you can build a full social graph on top of this, without any server-side logic at all.
Under this model, a user’s social presence is a set of files at a well-known path on their domain. Their posts, profile metadata, following list, and public key all live as static files. Any client that knows a user’s domain can fetch these files directly, with no API keys, no platform-imposed rate limits, and no dependency on any third party’s uptime.
Where This Fits in the History of Decentralized Social
RSS and Atom got here first, in a way. Both were static-file subscription formats: you publish a file, others poll it. The social graph was implicit and entirely client-side. What RSS never built was a protocol for follows, replies, mentions, or identity verification. It was a content format, not a social graph.
IndieWeb came later with a set of complementary standards. Webmention adds a notification layer: when you link to someone’s post, your server can ping theirs so they know you cited them. h-card and h-feed add semantic markup for profiles and post collections. But Webmention requires a server endpoint to receive pings, which brings server-side logic back in. IndieWeb’s approach is flexible and web-compatible, but a fully static implementation is incomplete: you can publish and read feeds without a server, but receiving mentions requires one.
ActivityPub is the W3C standard behind Mastodon and most of the Fediverse. It is explicitly server-based: each account needs an inbox endpoint that accepts POST requests from other servers, an outbox that serves activities, and follower or following collections. Running a compliant ActivityPub server means maintaining persistent processes, handling delivery retries, and keeping up with security patches on a public-facing service. The decentralization is real, in that anyone can run the server, but the operational complexity means most people rely on hosted instances, which reintroduces centralization in practice.
Nostr takes a different approach: signed JSON events broadcast through relay servers. Identity is a keypair rather than a domain, which makes it censor-resistant but harder to verify in the social sense. Relays store and forward events, but they are still servers run by someone, and the economics of relay operation are unsettled.
What Static Social Networking Looks Like
Under s@’s model, the protocol specifies paths on a domain where clients can find social data. Following the pattern of WebFinger and RFC 8615, a profile might live at https://example.com/.well-known/satproto/profile.json, with posts at paths underneath. A feed entry following this design pattern might look something like:
{
"id": "https://example.com/.well-known/satproto/posts/1234.json",
"author": "user@example.com",
"published": "2026-03-12T10:00:00Z",
"content": "This is a post on a static social network.",
"signature": "abc123..."
}The signature field is critical. Static files can be copied and served from anywhere, so without cryptographic signatures there is no way to verify that a cached or mirrored file actually came from the author. This is analogous to how Nostr handles every event: the author’s private key signs the content, and any client can verify authenticity against the public key at the author’s profile path. If s@ follows this pattern, then CDN caching and mirroring become features rather than concerns, because the content carries its own proof of origin.
Following someone in this model is pull-based: your client periodically fetches their feed URL and looks for new entries. This is exactly how RSS readers work. The load on the content server scales with bandwidth rather than computation, so a heavily-followed account can serve millions of readers from a CDN edge node without any application server involved.
Identity under a domain-based model has a clean property: it maps onto how the web already works. If your identity is user@example.com, then finding your static files is a matter of convention, not platform registration. DNSSEC or certificate-based mechanisms could bind the domain to a key, giving you a verification chain that doesn’t depend on trusting the CDN serving the files.
What You Give Up
The pull model’s cost is latency. There are no real-time push notifications in a purely static system. When someone mentions you, you don’t know until your client polls their feed and scans for references to your handle. For real-time conversation, this is a genuine limitation. For the kind of reading most people do on social platforms, it is probably acceptable. RSS readers operated on polling for years, and their eventual decline was a business and discovery problem, not a failure of the polling model itself. Google Reader’s shutdown in 2013 was not caused by polling being fundamentally broken.
Discovery is harder. On centralized platforms, algorithmic surfaces help new readers find content. On federated platforms like Mastodon, instance-level trending helps. In a static-file protocol, you find people by already knowing their domain, or by following links from people you already follow. The IndieWeb community has worked on this problem for over a decade with limited success outside technical circles. s@ would need either a crawler-based discovery layer or a separate directory service, and both options reintroduce centralized infrastructure.
Domain ownership is also not permanent or universally accessible. If you let your domain lapse, your identity disappears along with it. ActivityPub has the same problem for self-hosted instances, but platforms like Mastodon.social let you use someone else’s server, keeping your username alive without owning a domain. Static-file social networking, in its purest form, requires you to own the domain.
Moderation is the hardest gap. Centralized platforms moderate content before it reaches users. ActivityPub gives instance admins defederation tools. Nostr gives clients relay-level filtering. In a static-file protocol, content removal depends entirely on the hosting provider’s terms of service. You need GitHub or Cloudflare to act on an abuse report, not a protocol-level flag or a server admin. This works for egregious cases, but it is an abuse escalation path, not a moderation system.
Why This Design Keeps Getting Built
The recurring interest in static-file social networking reflects something real: running server infrastructure is a significant burden for individuals, and it is a barrier to self-hosting that most people will not clear. The IndieWeb community’s own retrospectives acknowledge this adoption friction honestly. s@ is betting that if you reduce the infrastructure requirements to “have a domain and some static hosting,” enough people will actually follow through.
The deeper question is whether static hosting is a meaningful improvement in practice. GitHub Pages, Netlify, and Cloudflare Pages are all free and easy to use, but they are still platforms that can suspend your account. A truly self-hosted static site requires a VPS and a domain, which is less effort than running an ActivityPub server but still more than signing up for Mastodon. The operational simplicity is real, but it is not zero.
What s@ has working in its favor is that the web already knows how to serve and cache static files at scale. The protocol does not ask anyone to run new infrastructure; it asks them to use the infrastructure they may already have. The gap between a developer’s personal site and a functioning node in a social protocol could be small enough to matter.
Whether the ecosystem of clients, directories, and tooling will form around this is what those 182 HN comments are working through, and it is a question that prior attempts in this space have not answered cleanly. The protocol design is the easy part. Getting people to build and use the clients is where this kind of effort has historically stalled.