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

Original Article ↗ Hacker News Discussion ↗

A new experimental protocol, s@ (satproto), proposes decentralized social networking where each user’s encrypted JSON feed is hosted on a static website they control. Commenters find the concept technically interesting and liken it to combinations of RSS, PGP, Nostr, and IndieWeb tools like Webmention, but raise concerns about key management, quantum‑vulnerable cryptography, awkward unfollow semantics, and reliance on domains and git hosting. Many argue that while such designs reduce dependence on large platforms, they will remain niche unless usability, discovery, and spam/misuse handling are prioritized as much as the cryptography.

Overall reception & concept

  • Many find the idea of a decentralized social protocol over static sites intellectually appealing, especially as an exploration of “no middleman” social networking.
  • Several note it’s clearly aimed at small, technical friend-groups rather than mass adoption, which tempers expectations.
  • Some question the practical benefit over simpler existing tech (RSS, static blogs, email-based systems).

Static sites vs. protocol complexity

  • Critics argue the system isn’t truly “static,” since it depends on cryptographic signing, key management, and a running client; only the JSON blobs are static.
  • Comparisons are made to IndieWeb tools like Webmention and older ideas (FOAF, pingback, XFN, twtxt), which achieve decentralized social interactions with far simpler mechanisms (HTTP POST, RSS, etc.).

Cryptography, security, and identity

  • The heavy use of X25519 and encryption is seen as overkill for many social use cases and a barrier for non-experts.
  • Concerns raised:
    • Publicly enumerable ciphertext vulnerable to future “harvest now, decrypt later” attacks.
    • Key distribution, rotation, and revocation problems, especially when unfollowing requires global re-encryption.
    • Domain names as identities tie the system to DNS centralization, which some see as “dead on arrival.”
  • Others defend strong encryption and note parallels to PGP session-keys + RSS, but acknowledge poor scalability.

Key storage & UX

  • Storing private keys in browser localStorage is widely criticized as fragile and non-backup-friendly.
  • People expect many users to lose keys and thus their social graph, making long-term use unlikely.
  • Suggestions: export/import flows, QR-code encoding of keys, secret-sharing recovery, and agent/UX layers that hide cryptographic details.

Discovery, paths, and protocol design

  • Debate over using a fixed path like /satellite/ vs. a .well-known/ endpoint; some see .well-known as standard and safer, others say it’s the wrong level (host vs. per-stream).
  • Lack of a clear user-facing rationale and discovery story (who else is using this, how to find them) is seen as a blocker.

Scale, spam, and social dynamics

  • Design intentionally doesn’t scale, which some accept; others worry even modest friend groups will strain feed aggregation and key-rotation.
  • Reply visibility limited to mutual follows may reduce spam but also hides interesting conversations.
  • Broader debate about whether decentralized systems can realistically displace big platforms given UX, marketing, and network effects.