DSNP

  • Name: DSNP (Decentralized Social Networking Protocol)
  • URL: https://dsnp.org/
  • Category: decentralized social-networking specification / shared social-graph protocol / delegated publishing and portable-identity middleware
  • Summary: DSNP is worth cataloging not as just another social app brand or a thin wrapper around Frequency, but as a lower-layer social-data specification that tries to separate identity, graph state, delegated publishing, and content announcements into interoperable protocol surfaces. Its clearest reusable mechanism is the split between pseudonymous DSNP User Ids plus control keys, a required public stream of state change records, Announcement-based publishing for content, User Data for durable identity-linked state like graph edges and profile resources, and explicit delegation so applications can act on behalf of users without owning the user’s social identity. DSNP also makes a more specific privacy decomposition than most social protocols: public follows, encrypted private follows, encrypted private connections, and publicly visible pseudonymous relationship identifiers (PRIds) that let counterparties verify a private connection without exposing their broader graph to everyone else. That makes DSNP a useful comparison point for Frequency, Lens, Farcaster, Ethereum Follow Protocol, and other social-data systems because it exposes where real control sits: identifier custody, delegation policy, batching and announcement transport, graph-data replacement semantics, encryption-key rotation, and chain-specific system implementation.
  • What it does:
    • Defines a blockchain-oriented social-networking protocol with required operations for identifier creation/retirement, delegation and revocation, announcement publication, batch publication, and user-data reads/writes
    • Treats a compliant DSNP system as a publicly observable and verifiable state machine that emits shared state-change records rather than as an app-specific database
    • Separates social content into Announcements while storing durable identity-linked state like graph edges, public keys, and profile resources as User Data
    • Supports public follows, encrypted private follows, encrypted private connections, and public PRId declarations that let counterparties validate bilateral private links without revealing the whole relationship graph to third parties
    • Requires pseudonymous identifiers with user-controlled control keys and allows delegation so apps or providers can publish or manage specific data on a user’s behalf without taking over the identity itself
    • Defines chunked, etag-guarded replacement of user data so social-graph and profile state can be updated asynchronously on consensus infrastructure without relying on app-owned storage semantics alone
    • Currently points to Frequency as the official DSNP system implementation, making DSNP an explicit protocol layer above one concrete chain implementation rather than only a product slogan
  • Key claims:
    • DSNP’s main analytical value is that it makes the social stack legible as protocol layers instead of app features: identifiers and control keys, delegated authority, announcement streams, identity-linked user data, and observable state-change records are all distinct objects in the spec.
    • The strongest reusable mechanism is the split between Announcements and User Data. Public speech and reactions flow through announcement publication, while graph edges, encryption keys, and profile resources live in a durable per-user state surface that applications read and replace.
    • The privacy model is more specific than generic private social graph rhetoric. DSNP distinguishes encrypted private follows from encrypted private connections and adds PRIds so counterparties can verify a private relationship without globally revealing it.
    • Delegation is central, not incidental. The spec requires users to be able to delegate and revoke permissions for announcement submission and user-data replacement, and it requires delegate actions to remain attributable and non-retroactively revocable.
    • DSNP’s portability claim is stronger than ordinary export rhetoric because the protocol expects a shared public state-change layer and common operations, not just app-level import/export tools.
    • The user-data update path is itself an important control surface: chunking, etags, compression, optional encryption, and async confirmation make social-graph mutation look more like replicated protocol state than like ordinary application rows.
    • DSNP is especially useful as a lower-layer comparison point beneath Frequency. Frequency adds chain-specific provider, batching, and stake-metering machinery, but DSNP is where the underlying social primitives and interoperability promises are standardized.
    • The main caveat is implementation concentration. The current spec explicitly points to Frequency as the official DSNP-over-blockchain system, so the open-standard story still sits on top of a narrow implementation base rather than a broad competitive ecosystem.
  • Whitepaper: Yes. The official Project Liberty whitepaper is saved as ../whitepapers/dsnp-whitepaper.pdf, and this pass also used the live DSNP overview/specification materials collected in ../whitepapers/dsnp-primary-sources-2026-05-15.md.
  • Sources:
  • Last reviewed: 2026-05-15 UTC