Static-Site Social Networks: Building AI-Spam-Resistant Communities

Static-site social networks resist AI spam not through filters or moderation queues but through architecture. Projects like the s@ (sAT) protocol eliminate centralized servers entirely, making algorithmic amplification structurally impossible. A bot has nowhere to post to a feed that doesn’t exist. The indie web is building communities small enough to be real.

What Is the AI Spam Problem Threatening Social Media?

The scale of the problem is no longer theoretical. Imperva’s bot traffic analysis found automated traffic accounts for 51% of all web requests, with malicious bots comprising 37% of total internet traffic.¹ NewsGuard identified over 1,000 news sites run almost entirely by AI in May 2025, often masquerading as credible outlets.² The social media bots market itself was valued at $2.81 billion in 2026 and is projected to reach $70 billion by 2035—a sign that automated account creation and content generation has become a mature, profitable industry.³

The deeper problem is qualitative, not just quantitative. Modern AI-powered bots can hold contextually coherent conversations, generate realistic engagement patterns, and pass behavioral checks that would have flagged template spam instantly. A February 2025 academic survey on the “Dead Internet Theory” described the shift from fringe speculation to a demonstrable, measurable phenomenon: authentic human-to-human interaction is being systematically diluted by automated content at scale.⁴

Centralized platforms respond with classifiers, rate limits, and verification systems. Each new defense becomes the next training target for the next generation of bots. The arms race compounds.

How Static-Site Social Networks Work

The architectural premise is straightforward: if social interaction happens through static files served over HTTPS, there is no dynamic server endpoint for a bot to exploit. There is no database to inject. There is no API rate limit to circumvent because there is no API.

The core technical components of static-site social networking depend on the project, but they typically include:

• Static JSON files served from a user-controlled domain as canonical data stores
• Client-side logic running in the browser to aggregate, render, and publish content
• HTTPS/TLS as an authentication layer—fetching content from a domain proves the domain owner published it
• Encryption at the content layer for posts that should remain private

The result is a system where a user’s domain is their identity, their web host is their server, and their browser is their client. No middleware, no platform, no Terms of Service between the user and their data.

The s@ Protocol: Mutual Follow as Structural Spam Defense

The s@ protocol (pronounced “sat,” short for satellite) is the most technically complete implementation of this approach available today. Built around static files, it stores all user data in encrypted JSON under a /satellite/ directory (or a custom path declared via .well-known/):

/.well-known/satellite    → discovery redirect
/satellite/profile.json   → public key + metadata
/satellite/posts/         → individually encrypted post files
/satellite/follows/       → plaintext follow list
/satellite/keys/          → sealed boxes per follower

Identity uses X25519 keypairs for key exchange; posts are encrypted with XChaCha20-Poly1305, with each follower receiving a sealed box containing the content key. Only the post owner and explicit followers can decrypt content.⁵

The anti-spam design is not a filter—it is the social model itself. To read another user’s posts, you must follow them and they must follow you back. There is no public discovery feed, no trending list, no algorithmic amplification. A bot that follows you cannot read your posts until you follow it back. You will not follow it back.

The Hacker News thread on s@’s launch surfaced real criticisms worth taking seriously. Key management is hard: private keys stored in browser localStorage disappear when users clear their browser data, and there is no account recovery mechanism. One commenter noted: “I am very technical, and idk exactly what a X25519 keypair is.” This is not a niche concern—it is the core adoption barrier for any cryptographic identity system targeting general audiences.⁶

ActivityPub Bridges: Fedipage and the Hybrid Approach

ActivityPub, the W3C protocol powering Mastodon, Pixelfed, and PeerTube, offers a different path: connect static sites to the existing Fediverse rather than building an isolated new network.

The technical challenge is real—ActivityPub’s inbox endpoint requires HTTP POST support, which static file servers cannot provide natively. Most ActivityPub endpoints, however, can be served as static files:

// /.well-known/webfinger (static JSON)
{
  "subject": "acct:user@yourdomain.com",
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://yourdomain.com/actor.json"
    }
  ]
}

Fedipage—a Hugo-based static site generator—implements full ActivityPub support by routing Accept headers to serve the same URL as either HTML (for browsers) or ActivityPub JSON (for Fediverse servers).⁷ Blog posts appear as Fediverse posts; replies, likes, and boosts from Mastodon users render in the post’s comment section. The project released v2.1.0 with expanded layout components and improved readability.

For the inbox problem, practitioners have adopted serverless functions (Cloudflare Workers, AWS Lambda) as a minimal dynamic layer, keeping the majority of content as static files while routing incoming federation requests to a serverless handler.

Niall’s comprehensive implementation guide documents the complete flow through eight detailed posts, making it the most thorough public reference for this architecture.⁸

The IndieWeb’s Trust-First Anti-Spam Stack

The IndieWeb community predates the AI spam crisis but has been quietly building infrastructure that is well-suited to resist it. The core principle: interaction flows through explicit social relationships, not platform algorithms.

The Webmention protocol (a W3C Recommendation) enables cross-site interaction—a comment posted on one site notifies another. The spam problem is acknowledged honestly on IndieWeb’s spam page: Webmention provides no native spam prevention, and Trackback was effectively abandoned because it became “pretty much all spam.”

The response is the Vouch protocol—an extension to Webmention that requires a sender to include a third-party URL that both the sender and receiver have previously linked to. It is trust propagation through demonstrated social graph connections, not behavioral classifiers.⁹

Combined with IndieAuth (using your own domain as your login credential), the stack creates an identity system where throwaway accounts are structurally expensive to create and maintain.

Comparing Approaches

The pattern is clear: spam resistance trades directly against discoverability. s@ has the strongest structural spam defense and the least discoverability by design. ActivityPub bridges offer existing Fediverse reach but inherit Fediverse moderation challenges. IndieWeb sits in between—networked through links but gated by social trust.

Failure Modes and Realistic Limits

These architectures are not silver bullets. Several failure modes deserve honest acknowledgment:

Key management remains unsolved. Both s@ and IndieAuth rely on cryptographic keys that average users will lose. No mainstream recovery UX exists for these systems. Until key management becomes as seamless as “forgot password,” adoption will remain technically gated.

Fediverse federation imports Fediverse problems. ActivityPub-connected static sites inherit the moderation challenges of the broader Fediverse: spam from connected instances, coordinated harassment from bad actors who have established trust within the network, and the labor of defederation decisions.

Small networks are their own vulnerability. The mutual-follow model that makes s@ spam-resistant also makes it brittle for community-building. A network of friends is not a public square. Content that would benefit from broad distribution—journalism, technical documentation, emergency information—cannot function in these systems.

Scraping still works. Encrypted posts prevent scraping of content, but profile metadata, follow lists, and post timestamps are often public. AI-powered scrapers can still build social graphs from public data even when content is encrypted.

Why This Matters Beyond Hobbyists

The mainstream response to AI spam is platform-controlled trust scores, paid verification, and device attestation. Each solution consolidates identity verification further into the hands of platform operators.

The indie web approach inverts this: identity is self-sovereign (your domain), trust is socially established (your links and follows), and spam resistance is architectural (no feed to spam, no algorithm to game). The tradeoff is genuine network effects and mainstream usability.

As AI-generated content degrades trust in open platforms, closed architectures—both platform-controlled and network-small—will gain appeal. Projects like s@ and Fedipage are building the technical vocabulary for one possible answer: communities that are resistant to automation not because they fight bots harder, but because they structured themselves to make bots irrelevant.

Frequently Asked Questions

Q: Can a static site actually participate in the Fediverse? A: Yes, with caveats. Static files can serve most ActivityPub endpoints (webfinger, actor JSON, outbox), but the inbox—which receives incoming federation messages—requires HTTP POST handling. Most implementations use a thin serverless function layer (Cloudflare Workers, AWS Lambda) for the inbox while keeping everything else as static files. Fedipage automates this pattern for Hugo sites.

Q: How does the s@ protocol’s mutual-follow requirement prevent spam specifically? A: In s@, posts are individually encrypted and the decryption keys are distributed only to people in your follow list. A bot that follows you cannot read your posts until you follow it back. Because there is no public discovery feed and no algorithmic amplification, a bot account that fails to earn mutual follows cannot reach anyone—making mass spamming structurally unprofitable.

Q: Is the IndieWeb’s Vouch protocol widely implemented? A: Not yet at scale. Vouch is a documented W3C proposal within the IndieWeb community, and several Webmention libraries support it experimentally, but it remains uncommon in production deployments. Most IndieWeb practitioners rely on manual moderation and allowlist-based trust scoring rather than automated Vouch verification.

Q: What happens if I lose my private key in s@? A: There is currently no account recovery mechanism. If your X25519 private key is lost—through browser localStorage clearing, device failure, or forgetting to export it—your identity is permanently inaccessible. This is the protocol’s most significant practical limitation for non-technical users, and the Hacker News community surfaced it as the primary adoption barrier at launch.

Q: Do these systems protect against harassment, or just spam bots? A: They specifically target automated spam at scale—bots that rely on algorithmic amplification and mass reach. Targeted harassment from a motivated individual with a real domain identity is not structurally prevented by any of these architectures. The mutual-follow model makes harassment less likely to spread, but it does not make it impossible. Moderation at the individual relationship level remains necessary.