Spritely 提出了一种默认安全地构建去中心化应用的构想，出发点是解决分布式系统中的三个基本问题：访问控制、进程通信和资源命名。这一内容来自 Spritely Institute 执行董事 Christine Lemmer-Webber 和该研究所技术总监 David Thompson 的演讲。
这一构想认为，中心化服务在工程上更容易实现，但也赋予运营方很大的能力，使其可以更改服务、监控用户，或彻底停止产品。Spritely 认为，依赖中心化平台会让用户面临有限的选择；此外，一些旨在针对大型公司的法律可能会变成“法律壕沟”，使小型项目和自托管的合规成本变得高昂。
安全始于能力，而非广泛权限
文章批评访问控制列表和角色模型，因为它们通常依赖广泛的群组与权限，以及负责授予授权的中心管理方。Spritely 展示的替代方案是能力安全：能力是一种不可伪造的引用，同时包含资源识别信息和使用该资源的权限。
实际上，程序只能获得明确传递给它的能力。例如，如果运行一个不受信任的应用，可以只授予它操作显示器和键盘的权限，而不是赋予它用户的全部权限。该模型允许在转授权限时缩减权限，也可以将权限传递给另一方而无需返回中心管理者处，同时还可以在之后撤销权限。
Spritely 在 Goblins 中实现了这些原则。Goblins 是一种基于能力的安全分布式编程环境。文章将能力传递与编程语言中的参数传递联系起来，使对资源的访问直接取决于函数或进程收到的内容，而不是取决于其能够隐式访问的内容。Goblins 还支持并发、持久性和事务，包括在操作失败时回滚到先前状态。
参与者模型与 OCapN 协议
为了组织进程之间的通信，Spritely 采用参与者模型。在该模型中，每个参与者一次接收一条消息，并可以向其他参与者发送消息、创建新的参与者，或改变自己处理下一条消息时的行为。这一模型结合了异步通信和状态管理，减少了对共享锁的依赖。
Spritely 认为，REST 主要适用于客户端—服务器应用，而不适合由彼此不信任的参与者组成的点对点网络。OCapN，即 Object-Capability Network，则在远程过程调用中加入安全引用传递。该协议独立于传输方式，可以通过 WebSockets、Tor onion 服务或其他方式运行；它还支持双方之间的通信以及向第三方传递对象。
OCapN 在基础层采用无强制模式的数据模型，并支持异步调用和 promise 值。文章提到，目前它已经在 Scheme、JavaScript 和 Dart 中有实现。
使用本地命名，而非盲目信任公共名称
Spritely 通过 petname 系统处理资源命名问题，使用户能够为自己认识的实体或对象选择本地名称。这是对域名问题的回应，例如网络钓鱼、名称劫持和视觉相似性攻击。
文章将这一挑战与所谓的 Zooko 三角联系起来。该理论认为，很难在同一个系统中同时实现人类可理解的名称、去中心化和安全性。petname 模型并不把全球名称视为足以证明身份的凭据，而是强调用户与资源之间的本地关系。
实际会发生什么变化？
Spritely 提供的更像是一套原则和工具，而不是一个可以直接替代中心化服务的现成产品。其核心价值在于尝试让安全性和去中心化对开发者而言成为默认选项，而不是要求开发者重新发现数十年来分布式系统和安全研究所积累的成果。不过，演讲本身并未解决大规模采用、用户体验、与现有应用的兼容性，或在参与者中断或彼此存在差异时如何管理资源等问题。
对于软件架构师而言，这种方法的重要性在于将精细的权限控制与异步通信和引用传递结合起来。对于开发者来说，挑战仍在于工具和协议的成熟度，以及是否存在比通常的中心化架构更简单的运行模式。