Christine Lemmer-Webber, Executive Director of the Spritely Institute, opened her talk with a disarmingly honest premise. The internet is not broken in a way that technology alone can fix. Centralized platforms have a track record of enriching investors, degrading service quality, and leaving users with little recourse when things go wrong. Spritely, a research institution she leads alongside CTO David Thompson, exists to build the infrastructure for a better version of the internet, one rooted in user freedom and peer-to-peer principles.

The Costs of Centralization

Lemmer-Webber walked through the familiar failures of centralized technology. Services backed by venture capital attract users with generous features, then degrade once investors demand returns. She cited Google Reader as an example of a widely used service that simply disappeared. Users had no choice and no warning.

Beyond disappearing services, centralized architectures introduce security risks that are difficult to address. A single point of control means a single point of failure. Backdoors can be inserted into centralized systems, and users often have no way to detect or resist them. Lemmer-Webber pointed to Discord as a case study. The platform hosts communities across gaming, education, and social organizing, and its concentration of power makes it a potential vector for surveillance or policy changes that affect millions of users.

She also raised the problem of legislative moats. Laws designed to punish large platforms or regulate their behavior often end up creating compliance barriers that only the largest companies can afford to meet. Smaller projects and independent self-hosters are locked out, which ironically reinforces the centralization the legislation intended to challenge.

Why Decentralization Has Not Taken Off

David Thompson addressed the engineering side of the problem directly. Centralization is technically simpler. A single source of truth is easy to reason about. Decentralization introduces concurrency, deadlocks, shared mutable state, message ordering, and consensus algorithms. Engineers working on distributed systems face challenges like Paxos, eventual consistency, and CRDTs.

But Thompson argued the barrier is not just technical difficulty. It is the absence of developer-friendly tooling. Rails made it possible to build web applications without deep expertise in every layer of the stack. Decentralized systems have not had their equivalent. Building a peer-to-peer application today requires knowledge of network security, cryptographic algorithms, and programming language theory. There are no sane defaults, no convention-over-configuration frameworks, and no turnkey solutions.

Thompson noted that every major platform today runs distributed systems behind the scenes, but the power remains centralized. Engineers work on distributed infrastructure, but users interact with a single service. The benefits of distribution, resilience, and user agency never reach the end user. Spritely's goal is to change that by making decentralized development as approachable as modern web development.

Rethinking Access Control

Thompson devoted significant attention to how decentralized systems handle access control. The current standard, role-based access control through systems like AWS IAM, rests on an access control list model. He described several problems with this approach. User and group-based privilege management is coarse-grained and grows unwieldy as organizations scale. Granting privilege requires a central administrator, which means safe delegation is essentially impossible.

He illustrated the weakness with the confused deputy problem, a well-known scenario in security design. The most common real-world version is cross-site request forgery, where an attacker tricks a user into submitting a malicious request using their authenticated session. The standard mitigation, unguessable tokens embedded in forms, works but reveals a deeper issue: the underlying model grants too much ambient authority to programs that run under a user's identity.

Thompson used the example of a program like Solitaire to make the point concrete. When a user double-clicks an executable, it inherits all the privileges of that user, including access to SSH keys and browser history. The program did not ask for those permissions specifically, but it receives them because it runs as the user. This is ambient authority, and it is how most operating systems work today.

The Spritely team argues for a capabilities-based model instead. Rather than granting programs broad access tied to a user identity, a capability system gives entities only the specific resources they need. If a program is compromised, the damage is contained to the scope of its granted capabilities. The approach aligns with the principle of least authority, which holds that every entity should have just enough privilege to complete its task and nothing more.

The Path Forward

Lemmer-Webber and Thompson are not proposing a wholesale replacement of existing systems. They are arguing that the foundational assumptions of modern application development, centralized control, ambient authority, and turnkey frameworks, encode values that do not serve users who want autonomy. Spritely's research aims to build the equivalent of a framework for peer-to-peer applications, something that handles security, naming, and communication so that engineers can focus on building products rather than reinventing decades of distributed systems research.

The Spritely Institute has prior experience with the kind of infrastructure that changes the landscape. The protocol behind Mastodon, ActivityPub, was co-authored by Lemmer-Webber and colleagues. That protocol enabled a decentralized social network to reach a significant audience. Spritely is now applying that same philosophy, but more broadly, to the architecture of the internet itself.