Spritely: Decentralizing the Internet with Capability-Based Security and P2P Networking
This article discusses Spritely's vision for a decentralized internet, addressing the challenges of centralized systems and proposing solutions based on capability-based security, actor-model communication, and petnames for naming. It highlights how these foundational technologies aim to enhance user control, resilience, and agency in distributed applications, moving towards a peer-to-peer network infrastructure.
Read original on InfoQ ArchitectureThe Need for Decentralization
The article critiques centralized technologies, noting their fragility, susceptibility to investor pressures leading to service degradation or disappearance, and lack of user control. It emphasizes the difficulty of building resilient distributed systems within existing legislative and technological environments. While decentralized technology offers resilience and user agency, it introduces complexity in areas like concurrency, synchronization (consensus algorithms, eventual consistency, fault tolerance), and infrastructure, as the industry primarily focuses on client-server models rather than peer-to-peer (P2P) networks.
Core Principles for a Decentralized World
Spritely proposes addressing three fundamental questions for building secure and decentralized applications:
- Resource Protection: How do we protect our resources effectively?
- Process Communication: How do processes communicate securely?
- Naming: How do we name things reliably and securely?
Protecting Resources with Capabilities
Traditional access control lists (ACLs) are deemed insufficient due to coarse-grained authority and reliance on central administrators. The Principle of Least Authority (POLA) is advocated, where entities have minimal necessary privileges. Capabilities are introduced as a superior mechanism for access control: unforgeable references that combine designation with authorization. They offer fine-grained privileges, allow granting without an administrator, and support revocation. Goblins is presented as Spritely's distributed Capability programming environment.
Capability-Based Security
Capabilities represent a powerful paradigm shift from ACLs. Instead of asking "Who can access this?", capabilities ask "Who *has the right* to access this?" by holding an unforgeable token. This simplifies distributed authorization and mitigates issues like the Confused Deputy Problem (where an entity is tricked into misusing its authority) and CSRF attacks.
Communicating with Actors and OCapN
For inter-process communication, the actor model is preferred over CSP (Communication Sequential Process) due to its asynchronous message passing and resilience to deadlocks. Actors can naturally reference Capabilities. Traditional protocols like REST (centralized, ACL-based) and RPC (lacks robust reference passing) are considered less suitable for networks of mutual suspicion. The Object Capability Network (OCapN) is proposed as a secure, transport-agnostic networking protocol based on Capabilities and Promises, designed for distributed computing.
Naming with Petnames
Addressing the challenge of secure and human-meaningful naming in decentralized systems, Spritely introduces Petnames. This technique maps human-readable names to secure, decentralized names, overcoming the limitations of Zooko's Triangle (where a name can achieve at most two of human-meaningful, decentralized, and secure properties). Petnames aim to guard against phishing and provide user-centric naming without global uniqueness constraints or reliance on centralized DNS.
Putting It All Together: A Vision for the Decentralized Web
The proposed architecture for a decentralized internet leverages Capabilities for access control, Actors for communication, and Petnames for naming. Spritely also introduces Hoot, a WebAssembly (Wasm) compiler and toolchain that translates Scheme to Wasm, supporting major browsers and NodeJS, crucial for deploying decentralized applications to the public via web browsers.