Summary: Fission is best understood not as a single storage or auth product, but as a protocol foundry that tries to decompose internet applications into user-controlled authority, user-controlled encrypted state, and portable edge execution. Its most reusable mechanism is the way it keeps those layers explicit: UCAN handles delegated authority, WNFS handles encrypted and shareable filesystem state, and the ODD/WebNative stack packages those pieces into developer-facing account, recovery, storage, and application flows. That makes Fission a useful comparison class for wallet-auth middleware, smart-account permissioning, decentralized-storage stacks, and local-first products that may actually centralize their defaults in hosted recovery, SDK, or account-linking layers.
What it does:
Coordinates and contributes to working groups around UCAN, WNFS, and IPVM as explicit identity, data, and compute primitives for local-first applications
Ships the ODD SDK, a developer stack for building distributed web apps with user accounts, UCAN authorization, WNFS-backed encrypted storage, and browser-friendly session flows
Supports both Web Crypto and blockchain-wallet-based account/auth flows, including a wallet-auth plugin that exposes a personal encrypted filesystem through wallet keys
Packages multi-device account linking and key-management flows rather than treating device portability and recovery as purely app-specific concerns
Publishes a broader WebNative vision where apps can run without a conventional complex backend while users retain control over identity and data
Key claims:
Fission’s GitHub organization profile is the clearest high-level source: it says Fission is building identity, data, and compute primitives for true local-first edge applications, and it explicitly points to UCAN, WNFS, and IPVM as separate working-group layers rather than one monolithic product.
The ODD SDK README makes the stack decomposition concrete. It says ODD provides user accounts via browser Web Crypto or blockchain-wallet plugins, authorization via UCAN, encrypted file storage via WNFS backed by IPLD, and key management via websocket-driven account-linking flows.
The ODD SDK materials are analytically useful because they show where practical power can re-centralize even inside a user-controlled stack: authentication strategies, recovery kits, capability-request UX, and default account-linking services are all operational control surfaces.
The original Fission whitepaper abstract frames WebNative as a secure-by-default edge framework where users own identity and data and code is executable on any machine without deployment as a separate stage. That makes Fission more useful as a corpus entry than a generic startup profile because it exposes a coherent architectural thesis across auth, storage, and compute.
The odd-walletauth plugin README is a useful crypto-native signal because it shows Fission’s stack can treat blockchain wallets as a first-class identity and key source for accessing a personal encrypted filesystem rather than only as a payment or signing add-on.
Fission belongs in the active corpus because it is the organizational layer sitting above several already-useful primitives. Keeping it visible helps separate protocol design, SDK defaults, recovery/linking UX, and working-group stewardship from the lower-layer specs themselves.
Whitepaper: Fission does have an original technical whitepaper, but the strongest corpus signal in this pass came from reading it together with the organization profile and ODD SDK materials; see ../whitepapers/fission-primary-sources-2026-05-12.md.