DeSo is best understood as a storage-heavy layer-1 for social and adjacent application state, not merely as a social app brand. The docs repeatedly describe it as a blockchain built from the ground up for social-media-style data and advanced trading applications.
The core design claim is that profiles, posts, follows, direct messages, NFTs, and order-book activity can all live onchain at costs low enough to make an open shared data pool practical.
The most important governance and market-structure implication from the docs is the “public pool plus many curators” model: anyone can run a node and expose a differently ranked feed, but all of them draw from and contribute back to the same underlying blockchain data.
The build-app tutorial is especially useful because it makes the architecture concrete. It points developers to the core chain repo, backend transaction-construction routes, frontend examples, and the identity stack that separates owner keys from app-scoped derived keys.
DeSo therefore should not be flattened into generic “decentralized social.” It bundles a social graph, creator-monetization rails, message transport, and trading primitives into one chain-level state machine.
The corpus value is not in accepting every project claim at face value, but in using DeSo as a full-chain contrast case against lighter social primitives such as follow registries, attestation layers, or offchain portability systems.
Specific source signals worth retaining
docs.deso.org vision page: strongest source for the project thesis around a public social-data pool, curator competition, and creator monetization.
deso-tutorial-build-apps: best evidence that the system exposes social, messaging, NFT, DEX, and identity functionality as first-class developer primitives rather than as one hosted application.
Docs repo README: good backup for the high-level vision and open-protocol framing.
Repo metadata: useful for confirming an active documentation surface and long-lived public project footprint.
Why this entry belongs in the corpus
It adds a strong comparison class for Lens, Farcaster, Ethereum Follow Protocol, BYOF, and Ceramic-era social-data systems by showing the opposite architectural bet: put the whole social graph and much of the surrounding app state on a dedicated chain.
It helps sharpen a recurring corpus question: does decentralization happen at the registry/list layer, the app-specific middleware layer, or the full shared-data-pool layer?
The reusable insight is that opening the full content pool does not eliminate control surfaces; it relocates them into chain transaction design, node operation, key-delegation flows, and feed-ranking logic layered above the shared state.