Spritely presents a vision for building decentralized applications that are secure by default, starting with the treatment of three fundamental problems in distributed systems: access control, process communication, and resource naming. This was presented in a talk by Christine Lemmer-Webber, executive director of the Spritely Institute, and David Thompson, the institute’s technical director.
The idea starts from the premise that centralized services are easier to engineer, but they give the operating entity considerable power to change the service, monitor users, or shut down the product entirely. Spritely believes that reliance on centralized platforms leaves users with limited options, and that some laws designed to target large companies may turn into “legislative moats” that make compliance costly for small projects and self-hosting.
Security Starts with Capabilities, Not General Permissions
The article criticizes access-control-list and role-based models because they often depend on broad groups and permissions, as well as on a central administrative entity to grant authorization. The alternative presented by Spritely is capability security, in which a capability is an unforgeable reference that combines identification of a resource with permission to use it.
In practice, a program receives only the capabilities explicitly passed to it. If an untrusted application is run, for example, it can be granted permission to interact only with the display and keyboard, rather than being run with all of the user’s permissions. This model makes it possible to attenuate a permission when delegating it and pass it to another party without referring back to a central administrator; it can also be revoked later.
Spritely implements these principles in Goblins, a secure distributed programming environment based on capabilities. The article connects capability passing with argument passing in programming languages, so that access to resources becomes a direct result of what a function or process receives, rather than what it can access implicitly. Goblins also supports concurrency, persistence, and transactions, including rolling back to a previous state when an operation fails.
The Actor Model and the OCapN Protocol
To organize communication between processes, Spritely relies on the actor model, in which each actor receives one message at a time and can send messages to other actors, create new actors, or change its behavior for the next message. This model combines asynchronous communication with state management in a way that reduces reliance on shared locks.
Spritely considers REST primarily suited to client-server applications, while it is not a good fit for a peer-to-peer network made up of parties that do not trust one another. OCapN, or Object-Capability Network, adds the passing of secure references to remote procedure calls. The protocol is independent of the transport medium and can operate over WebSockets, Tor onion services, or other means. It also supports communication between two parties and passing objects to a third party.
OCapN uses a data model with no schema imposed at the base layer and supports asynchronous calls and promise values. The article states that it currently has implementations in Scheme, JavaScript, and Dart.
Local Naming Instead of Blind Trust in Global Names
Spritely addresses the problem of resource naming through petname systems, which give users local names that they choose for the parties or objects they know. This responds to problems with domain names, such as phishing, name squatting, and homograph attacks.
The article connects this challenge to what is known as Zooko’s triangle, which assumes that it is difficult to combine, in a single system, a human-meaningful name, decentralization, and security. Rather than presenting a global name as sufficient evidence of identity, the petname model focuses on the user’s local relationship with the resource.
What Changes in Practice?
Spritely offers a set of principles and tools more than a ready-made product that replaces centralized services. Its core value is the attempt to make security and decentralization default for developers, rather than requiring them to rediscover decades of distributed-systems and security research. However, the presentation itself does not settle questions of large-scale adoption, user experience, compatibility with current applications, or how resources should be managed when parties disconnect or disagree.
For software architects, the importance of the approach lies in combining fine-grained permission control with asynchronous communication and reference passing. For developers, the challenge remains the maturity of the tools and protocols and the availability of operating models simpler than the usual centralized architectures.