Show HN: s@: decentralized social networking over static sites

The technical world has no shortage of decentralized social media experiments, but “Show HN: s@: decentralized social networking over static sites” (sAT Protocol) stands out by going radically simple—no servers, no relays, just encrypted JSON files on your own static website. If you’re frustrated by the complexity of Mastodon, AT Protocol, or blockchain-based platforms, s@ promises a new direction: self-hosted, small-scale, and privacy-first, all over plain static hosting. Here’s what you need to know to understand, evaluate, and potentially deploy s@ for your own close-knit social graph.

Key Takeaways:
Now at a Reduced Price: On-Demand Cloud Storage and Collaboration for Teams!
NiHao Cloud
Start with pay-as-you-go pricing! The cloud storage solution that works wherever your team is—China, America, Europe, and more—all at the same time!

Understand how s@ (“sAT Protocol”) enables decentralized social networking using only static sites and encrypted JSON data.

See concrete, real-world examples of s@ identity, post, and follow structures—no blockchain, no server, no relay required.

Get actionable insights into the security model, privacy guarantees, and operational workflow for publishing and following.

Evaluate the practical trade-offs of s@ versus Mastodon, Bluesky (AT Protocol), and other leading decentralized social apps.

Learn what can go wrong in deployment, and how to avoid the most common missteps when rolling your own micro-social web.

Why s@ Matters Now: The Case for Static-Site Social

Decentralized social media is no longer a fringe experiment. Mastodon, Bluesky, Nostr, and others have seen user surges as trust in traditional platforms erodes and network sovereignty becomes a priority (see arXiv:2504.00071). But these platforms often trade one kind of complexity for another: you’re still reliant on federation servers, complicated relay infrastructure, or the heavy machinery of blockchain.

s@ (the sAT Protocol) strips this back to basics. Each user runs a static website—think GitHub Pages, Netlify, or any static file host—that acts as their “profile” and message store. There are no servers mediating your connections: your friends’ browsers fetch your encrypted posts directly from your public site. This is not for influencers or viral content; s@ is designed for small, trusted circles who want to own their data and minimize operational risk.

You landed the Cloud Storage of the future internet. Cloud Storage Services Sesame Disk by NiHao Cloud

Use it NOW and forever!

Support the growth of a Team File sharing system that works for people in China, USA, Europe, APAC and everywhere else.

This approach resonates with a rising “small web” movement—developers who want to reclaim the simplicity and autonomy of early internet tools, but with modern cryptographic guarantees. As our previous coverage of WebAssembly integration shows, interest in unbundling and decentralizing core web functions is only accelerating.

s@ in Practice: Protocol Structure and Real Examples

s@ is defined by clear, minimal protocol documents and file structures. Here’s how it actually works, with code and configuration copied directly from the reference implementation (satproto.org):

Identity and Discovery

Identity is your domain name. Authentication is handled by HTTPS/TLS—if someone fetches your data from your static site, you control the identity.

The discovery document is at https://{domain}/satellite/satproto.json and looks like:

{
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}

If you don’t use /satellite/ as your data path, place a root pointer file:

{
  "sat_root": "my-custom-repo"
}

Posts and Encryption

Each post is an individually encrypted JSON file (with XChaCha20-Poly1305). The post index is plaintext for lazy loading:

{
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}

Post IDs are timestamp-prefixed for chronological sorting, with a random suffix to prevent collisions.

Follow Lists

Follows are listed in follows/index.json (plaintext):

{
  "follows": ["bob.example.com", "carol.example.com"]
}

Static Site Structure

The core directory structure:


/satellite/
  satproto.json             # Discovery + profile + public key
  posts/
    index.json              # Post ID list (plaintext, newest first)
    {id}.json.enc           # Individually encrypted post files
  follows/
    index.json              # Follow list (unencrypted)
  keys/
    _self.json              # Sealed box: content key + credentials (owner only)
    {domain}.json           # Sealed box: content key for follower

The protocol is hosting-agnostic—while the reference uses GitHub Pages, you can deploy anywhere static files are served.

Security, Privacy, and Feed Aggregation

s@’s security model is simple but robust for its use case:

All user data (posts, secrets, credentials) is encrypted per follower, using X25519+XChaCha20-Poly1305. Only you and your followees can decrypt your data.
Each follower receives a sealed envelope with the symmetric content key, using their X25519 public key. When you unfollow someone, you rotate the content key, re-encrypt all posts, and update envelopes for remaining followers.
There is no server or relay: all data transfer is browser-to-browser via public file hosting. This sharply limits attack surface and surveillance risk.

Feed aggregation happens client-side. Your browser fetches, decrypts, and merges posts from everyone you follow, sorted by timestamp. Replies are supported (flat, non-nested threads):

Replies have reply_to and reply_to_author set, but you can only reply to top-level posts. No reply chains.
If you can’t decrypt the original post (you don’t follow the author), replies are hidden, preventing spam and unwanted mentions.

Publishing Workflow

To publish, the client encrypts your post, pushes it as a new {id}.json.enc file to your static site (via e.g., GitHub API), and updates index.json.
All secrets (e.g., GitHub tokens) are encrypted in keys/_self.json.
For a new device, you need only your domain and private key to recover your account.

Trade-offs, Limitations, and Alternatives

Every decentralized social protocol makes trade-offs. s@ is refreshingly honest about what it’s for—and what it isn’t.

Factor	s@ (sAT Protocol)	Mastodon (ActivityPub)	Bluesky (AT Protocol)
Hosting Model	Static web (no server/relay)	Federated servers (“instances”)	Relay servers, custom protocol
Scalability	Best for small, trusted groups; does not scale to mass audiences	Scales to millions, but requires operational overhead	Scales, but relies on central relays for large feeds
Privacy Model	End-to-end encrypted per follower	Posts are public; DMs require trust in server admin	Posts are public; no end-to-end encryption
Interoperability	Not compatible with other protocols	Fediverse (ActivityPub compatible)	AT Protocol ecosystem only
Infrastructure Required	None (static hosting only)	Persistent servers with moderation/admin	Relays and server-side logic

Factors@ (sAT Protocol)Mastodon (ActivityPub)Bluesky (AT Protocol)Hosting ModelStatic web (no server/relay)Federated servers (“instances”)Relay servers, custom protocolScalabilityBest for small, trusted groups; does not scale to mass audiencesScales to millions, but needs ops/admin overheadScales, but central relays enable large feedsPrivacy ModelEnd-to-end encrypted per followerPosts public to all (DMs require trust in server admin)Posts public to all (no end-to-end encryption)InteroperabilityNot compatible with other protocolsFediverse (ActivityPub compatible)AT Protocol ecosystem onlyInfrastructure RequiredNone (static hosting only)Persistent servers with moderation/adminRelays and server-side logic

Considerations and Limitations

Does Not Scale: s@ is not designed for influencer-scale or even community-scale use. The protocol explicitly states, “No! Neither does friendship.” If your use case demands public feeds, trending topics, or discoverability, look elsewhere.
Manual Social Graph: There’s no built-in friend discovery. To add a friend, you literally text them your domain or tell them in person. This is deliberate, but not for everyone.
No Server-Side Search or Discovery: You can’t search posts or users globally—feeds are strictly limited to people you follow.
Operational Simplicity, but No Convenience Layer: If you use a third-party to host your static site, your encrypted data is on their servers (though only you and your followers hold the keys). For truly sovereign hosting, you must self-host and configure CORS.
Not Interoperable: s@ does not federate with Mastodon, Bluesky, or any ActivityPub/AT Protocol platforms. You’re building your own “dark forest” social graph.

Notably, this mirrors a trend we’ve seen in other “unbundled” web technologies: maximum autonomy at the cost of friction and discoverability. See our analysis of Rails 8 trade-offs for a broader discussion of simplicity vs. scale.

Upgrade & share files freely!

Unlock the full potential of cloud storage by subscribing today. Logo Sesame Disk

Enjoy seamless access and sharing across China, the USA, Europe, and just everywhere!

Alternatives at a Glance

Mastodon: ActivityPub-based, federated servers, rich moderation and community features. Widely adopted, but requires trusted server operators (Exploding Topics).
Bluesky: AT Protocol, relay-based, custom feeds, but relies on central relays for scale and has no end-to-end encryption by default.
Scuttlebutt: Peer-to-peer, local-first, but distribution is slow and complex for less technical users.

Common Pitfalls and Pro Tips

Key Management: Losing your private key means losing access to your posts and credentials. Back up your private key securely and consider using a hardware token for extra safety.
Hosting Caveats: If you use GitHub Pages or similar, you must enable CORS so other clients can fetch your data. Some hosts restrict this by default.
Follow List Disclosure: While posts are encrypted, your plain follow list is visible (though key envelopes leak this anyway). If you need follower privacy, s@ does not offer it.
Content Key Rotation: When you unfollow someone, you must rotate your content key and re-encrypt all posts. Failing to do so leaves your data accessible to ex-followers.
Limited Threading: Only flat replies to posts are supported—no nested conversations.
No Push Notification or Real-Time Updates: s@ is strictly pull-based. Expect latency between publishing and others seeing your updates.

Conclusion and Next Steps

s@ is a radical experiment in decentralized social networking that rejects both the scale and complexity of most “Web3” and federated alternatives. If you want to build a social space for your closest friends, with true data autonomy and minimal operational burden, s@ is the most self-sovereign protocol available—at the cost of interoperability, convenience, and reach.

To get started, fork the reference repo, enable static hosting, and experiment with the protocol’s file structure and cryptography. For more context on the broader decentralized social landscape, see this overview of decentralized network architectures and our recent analysis of unbundled, developer-first web infrastructure.

If your needs go beyond a handful of friends and privacy is not your only goal, evaluate alternatives like Mastodon or Bluesky. But for practitioners seeking the purest form of small, encrypted, static-first social networking, s@ is the new reference point.

Sources:

Sources and References

This article was researched using a combination of primary and supplementary sources:

Supplementary References

These sources provide additional context, definitions, and background information to help clarify concepts mentioned in the primary source.

Critical Analysis

Sources providing balanced perspectives, limitations, and alternative viewpoints.