Great to see people outside the team finally discussing Web5.
Let me walk through Web5’s history and its relationship with AT Protocol.
Web5 was originally proposed by former Twitter CEO Jack Dorsey to address financialization, industrial hollowing, and inefficiency in Web3, as well as over-centralization, privacy, and data ownership issues in Web2. It advocated for an organic integration of Web2 and Web3 to solve both sets of problems simultaneously.
The real-world implementation of Web5’s vision is Bluesky and its underlying protocol—AT Protocol. For unknown reasons, however, Bluesky never integrated with blockchain and instead pursued a loosely federated approach.
In early 2025, some CKB ecosystem members found Web5’s philosophy highly aligned with CKB’s principles (layered design, only putting essential data on-chain, etc.). They decided to borrow from AT Protocol to build a CKB application development framework.
Since it’s CKB ecosystem-led, DID was naturally designed to reside on the CKB chain. Thus, the Web5 we refer to here inherits Jack Dorsey’s original vision and adopts certain AT Protocol designs (PDS, app view, lexicon, etc.), but is neither compatible nor aligned in direction. In fact, Bluesky clearly leans toward Web2—perhaps “Web2.3”?—while CKB’s approach clearly leans toward Web3, maybe “Web2.7”?
The most significant difference: in AT Protocol, users’ sign keys are custodied in PDS. This is unacceptable in the “CKB Application Development Framework,” so we’ve restructured PDS for users to self-custody sign keys—more consistent with Web3 user habits.
Key Storage
As mentioned, users must self-custody sign keys.
We initially considered reusing existing CKB wallet infrastructure to co-manage sign keys. After discussions with multiple wallet developers, however, they argued that asset-holding private keys and post/like-signing keys have different security requirements. Wallets are designed for asset storage; introducing lower-security key support would increase asset loss risk. They advised against combining them. Additionally, since every Web5 app action requires sign key signatures, confirming each time would severely degrade UX. The final solution: plaintext storage in browser local storage.
In the Web5 Application Framework Modules ( GitHub - web5fans/modules · GitHub ), we developed a dedicated keystore—a lower-security-grade web wallet that even apps cannot access sign keys through.
Key rotation is implemented. The DID cell, controlled by the user’s wallet, holds the sign key’s public key (did:key format). Updating this did:key in the DID cell enables rotation. Both console (console.web5.fans) and portal (me.web5.fans) integrate this (update key). However, these sites are keystore-based, while bbs and ccfdao predate Modules’ design—migration is still being planned.
User sovereignty
DIDs are fully user-controlled. The DID indexer merely facilitates reverse lookup (DID → DID Cell). Many scenarios don’t require it—console and portal don’t depend on it. For specific users, providing a wallet address allows direct retrieval of live cells under that address to access the user’s DID Cell.
Data portability
We’ve followed AT Protocol’s design here. Users can export data and migrate between PDS instances, even self-host. Console (console.web5.fans) provides data export/import; combined with other features, full PDS migration is achievable. Portal (me.web5.fans) offers only export—migration is complex and risks data corruption, so it’s excluded. Console targets developers.
Relayer and other Web5 components are open-source: web5fans · GitHub . These are generally considered Web5 infrastructure and rarely mentioned in ccfdao contexts.
Sovereign data
Web5 is inherently Web2-Web3 hybrid—not all data goes on-chain. Some remains off-chain, but we place critical data on-chain; off-chain data only affects the specific app.
A Web3 example: if a user owns a Spore across two Spore Market sites, each freely decides which Spores to list, how to categorize them, display order—this data stays off-chain as it’s app-specific. Regardless, the user’s Spore remains on-chain, unchanged.
Ecosystem Reuse
DIDs are updatable and reusable across apps.
A user registered on bbs.fans can directly log into ccfdao.org without re-registering a DID. One issue: users must manually migrate login credentials between sites. This improves once bbs and ccfdao migrate to keystore. However, cross-device usage (desktop registration → mobile login) still requires manual credential migration—a consequence of the initial choice discussed in “Key Storage,” with no perfect solution.
AT Protocol compatibility was never a consideration—their paths diverge. Bluesky explicitly stated they won’t partner with any specific blockchain project.
Independent Operation
Yes, anomalies still require human (foundation) intervention. Full on-chain contract enforcement is nearly infeasible, especially for CKB.
Verifiable critical data suffices. Verifiability creates massive deterrence: if malicious acts are certain to be detected, they become net-negative, and no one commits them.