This event summary was prepared by Claude with editing by Tim O’Reilly, based on a transcript of a conversation. On October 20, 2026, Tim O’Reilly hosted an hour-long discussion with Alex Komoroske, CEO and cofounder of Common Fabric. Komoroske previously spent over a decade at Google as a product manager and director of product management on Chrome, Google Maps, and Google Earth, and later worked on corporate strategy at Stripe. He is a coauthor of the Resonant Computing Manifesto, which Tim had signed. Common Fabric’s consumer product is not yet public; Alex showed it privately to Tim the day before the conversation.
The Resonant Computing Manifesto
The Resonant Computing Manifesto sets out five principles for technology that supports lasting human value: private (users steward their own data), dedicated (no conflicts of interest), plural (no unnecessary centralization of power), adaptable (able to do things its creators didn’t explicitly build), and prosocial (helps people create meaning together rather than isolating them). Komoroske contrasts “hollow” experiences—they feel good in use but leave regret afterwards—with “resonant” experiences that nourish users. He argued that modern technology and business models are structurally better at delivering hollow experiences and that the AI transition is an opportunity to change norms and architectures toward resonance.
Privacy, bits, and the physics of trust
Tim asked Komoroske to clarify what he means by privacy. Alex said he does not mean making data unreadable even to its owner (as in some interpretations of HIPAA-style protections). Instead, he means making data more useful by putting control in the user’s hands. His three-part framing is:
- Contextual integrity: invoking Helen Nissenbaum’s idea that data should be used according to users’ intentions and expectations, avoiding harm and nasty surprises.
- Atoms vs. bits: trust and social enforcement operate differently in the physical world because actions are visible; in the digital world, invisible data access removes immediate social penalties and creates incentives for companies to peek and combine data for profit.
- Data virality: digital data copies at full fidelity for near-zero cost, so once it leaves the user’s control it’s effectively out of control.
He argued the industry has relied on three inadequate defenses: unread terms of service, permission dialogs (which he called “responsibility-laundering dialogs”) that ask users to grant open-ended trust, and silos where each app only sees a slice of a person.
What Common Fabric changes: data that carries its own rules
Common Fabric’s core idea is that every data item carries a metadata sidecar wherever it goes. That sidecar contains two things: cryptographic provenance (who performed the last computation, the fingerprint of the software that did it, and inputs, traceable backwards) and policy (conditions under which the data may be declassified or used now or later). The math is analogous to blockchains for provenance, but without a global, financialized ledger.
An open-source runtime—described by Komoroske as the project’s “core reaction chamber”—enforces policies. It receives a proposed computation graph consisting of untrusted code operating on specific data with specified policies. If the computation complies with the policies, the runtime executes it, updates the provenance chain, and notifies stakeholders. If not, it halts with a descriptive error (for example, when a network request would leak something derived from confidential data). Users can run the runtime locally, but most will use hosted services that run it in Trusted Execution Environments (TEEs): hardware-isolated environments where the host cannot see inside and can cryptographically prove the runtime is unmodified.
Patterns: small, untrusted building blocks
Common Fabric builds applications out of “patterns,” small units of untrusted code written in TypeScript with a React-like shape. Komoroske emphasized that “untrusted” means you don’t have to trust them, because the data’s policies determine what they can do. When the team asked LLMs what framework felt natural, the models suggested React.
A pattern can do six things:
- Perform arbitrary computation.
- Produce derived data that persists and is available to other patterns.
- Produce UI for different contexts (e.g., dark mode or a preview chip), computed only when used.
- Make network requests if policy allows (LLM calls are technically such requests).
- Instantiate subpatterns fetched from anywhere on the internet or written by an LLM on the fly.
- Express a wish for more data.
Komoroske illustrated a wish: a meal-planning pattern might wish to know the user’s favorite foods. One pattern could present a simple textbox generated by an LLM for the user to fill in; another could search tagged notes or recent recipes; another might read the user’s Gmail with an LLM to distill preferences. If those emails are confidential, the derived result remains confidential.
Anyone can write patterns, and Common Fabric will surface popular ones, but pattern authors never see users’ confidential data because policies and the runtime prevent misuse.
Taint, type-checking, and enforcement
Common Fabric’s information-flow model uses the concept of “taint”: data becomes tainted when it has touched confidential material and thereby inherits restrictions. The goal is to keep as little data tainted as possible so that safe network requests remain feasible. The compiler untangles pattern data flows so that code that merely forwards a token receives a handle rather than the token itself and remains untainted.
Komoroske compared this to Rust’s borrow checker: it nags and refuses to compile unsafe patterns. Human programmers can find such checks tedious, but LLMs don’t mind—they’ll make the necessary tweaks. If the software compiles under Common Fabric’s checks, Komoroske said, it’s structurally safe even if its usefulness still must be evaluated.
Because the system enforces safety structurally, it can run patterns proactively and speculatively (without users installing anything) and then distribute the ones people engage with—distribution that wouldn’t be possible under traditional trust models.
Bad patterns vs. dangerous patterns
Komoroske acknowledged there will be low-quality patterns—“a lot of things will suck”—but expects social ranking and usage signals to surface the good ones. His main concern is dangerous patterns that could misuse data. He offered the draft box in chat apps as an example: today, nothing in many chat implementations structurally guarantees that text you type is invisible to others until you hit Send. In Common Fabric, a default policy could make drafts confidential until explicitly declassified to chat members, so chat apps built from that pattern could not behave otherwise.
He also noted that policy sets and patterns must coevolve: as people discover escape routes, the default policies and delegations must be updated. He did not promise perfect security—only that, for a given security budget, users could reach further and do more safely than under current models.
Data reclamation and interoperability
Tim and Alex discussed the economics and the problem that large services lock users in via accumulated data. Alex framed the solution as “reclaiming” user-contributed bits: insights a company derives from aggregate data belong to the company, but the raw bits a user contributed should be recoverable. He pointed to msgvault, an open-source project that keeps a local archive of Gmail histories, so agents and queries can run against a local copy rather than rate-limited APIs.
Who pays for compute?
Tim pressed on economics: running large services is costly, and users today get many services cheaply because providers subsidize them. Alex’s provocative formulation: if you’re not paying for your computation, it’s working for someone else. In the Common Fabric model, users either run the runtime on their own machines or use AI service providers that run the runtime in TEEs and charge for tokens, compute, and storage. If users can switch providers, margins should stay small. Komoroske acknowledged consumer resistance to paying for software but argued that the nontrivial marginal cost of LLM tokens opens the possibility of viable consumer payment models.
He also suggested incumbents like Google could migrate services into this world, but incumbents are used to different business models: patterns on Common Fabric use data without owning it, which can be premature or unattractive for some investors.
Open source base, product on top; agents writing patterns
The runtime and pattern system are open source, but Common Fabric is building a consumer product on top because the OSS components alone feel like a tech demo. That product is under development and not yet public. Komoroske and his cofounder Berni Seefeld long believed that AI would write the majority of such patterns; that shift (agents writing software) is what makes the approach scalable.
Institutional form and incentives
Common Fabric is organized as a public benefit corporation. Komoroske credited Eric Ries for advising on structuring the company to maintain long-term thinking and to better attend to externalities. He described himself as pro-market, arguing that organizations that commit to long-term horizons tend to behave better externally.
Is surveillance capitalism inevitable?
In response to an audience question referencing Shoshana Zuboff’s The Age of Surveillance Capitalism, Komoroske argued that technology decisions shaped the current model—citing the same-origin policy and how app models led to data ownership by individual apps—and that different technical choices at critical leverage points can produce different outcomes. He did not claim inevitability for surveillance capitalism.
Why it matters and what’s next
Tim framed AI as an opportunity to reset the industry’s economic and technical assumptions. He described Common Fabric as the most thoughtful proposal he’d seen for that reset, comparing his reaction to his first encounters with the web. Alex and Tim agree the project is promising, but its success depends on whether the broader ecosystem adopts different distribution, trust and business models. The underlying runtime and pattern system are open source; Common Fabric aims to deliver a consumer product on top and expects network effects as more users, patterns, hosts and delegations come online.
Closing
Common Fabric combines a normative vision (resonant computing) with concrete technical components—metadata sidecars with provenance and policy, a permission-enforcing runtime, TEEs for hosted execution, and pattern-based software whose authors need never see users’ confidential data. The team argues this design can let people do much more with AI while keeping data control in users’ hands; the next years will show whether the technology, ecosystem and emerging business models align to realize that possibility.
