Is Crosshatch Web3? Why is Crosshatch building a central trust authority v an open protocol? In this blog, we unpack our design choices.

‍

Is Crosshatch web3?

At Web Summit 2022 Tim Berners Lee was similarly asked, “Is Solid Project Web3?”

This is an important question – Solid (and Crosshatch!) look like they could be web3 projects. We’re focused on interoperability, decentralization and self-sovereignty.

But Solid is not web3. TBL explained

Blockchain protocols may be good for some things, but they’re not good for Solid. They’re too slow, too expensive and too public. Personal data stores have to be fast, cheap and private.

He went on

Web 1.0 was the bloggosphere, static HTML documents linked together with URLs.

Web 2.0 added technologies like Javascript and dynamic HTML.

But, for security reasons, … identity, apps and data were tightly coupled. … The Web 2.0 approach became the era defined by a few big companies that used our data to lock us into our platforms.

This is the strategy Bill Gurley discovered in 2003.

So Solid is not web3; it’s Web 3.0. [Maybe we should lean in and just call it web4.]

Solid aimed to decouple identity and data from apps. This was originally done via the Semantic Web, but AI makes data cleanly interoperable.

Instead of bringing your data to any app as in Solid, at Crosshatch you bring your AI agent: secured AI with permissioned access to context that you control.

Professor Claude expands:

AI dissolves ontological barriers that plagued Semantic Web. No more schema wars. No more standard bodies. Pure pragmatic interop via statistical mediation.

Long-time Solid contributor Noel De Martin describes the difference clearly:

In Web3, decentralized means that data is everywhere. Whereas in Solid, decentralized means that data is anywhere. If we're talking about my private data, I'd very much prefer the second approach (with "anywhere" meaning wherever I choose).

Crosshatch is Pretty Solid.

Whereas Solid has suffered from DX and UX “that suck”, Crosshatch aims to resolve these issues with an intuitive user experience and developer experience made clean and intuitive by AI. Data should be permissioned at the context level (“recent reservations”, “recent purchases”, “recent posts”), not the data source level.

Toward “data anywhere” paradigm, we’re beginning work on a self-hosted Crosshatch, where users can sync their data to a personal data wallet hosted on their own machine.

This delivers on De Martin’s “my data wherever I choose” – in the cloud for convenience-oriented users, or locally for those privacy conscious. This is distinct from crypto’s “data everywhere” but is consistent with ethos of interoperability, self-sovereignty and decentralization.

‍

Why not an open protocol?

Last time we wrote about Crosshatch as a Personal MCP server.

When we wrote it we missed an ongoing discussion of how MCP might add auth to servers, where servers act as clients to third party integrations.  

The intuition is that end-users may be more comfortable granting scopes to servers than clients, particularly since end-users may use a server with many clients.

The spec isn’t done, but the lead author eschews a central trust authority.

We want clients and servers to be able to determine whether they trust each other based on user consent, rather than delegating to any kind of registry of trusted implementations.

Anthropic’s Justin Spahr-Summers wrote in November.

This approach makes sense for an open protocol, but we believe that it comes at the cost of user experience.

We’re overwhelmed by Terms of Service. No one reads them. When users sign up for a Solid Pod, they’re presented with a number of candidate Solid Pod providers, but it’s not apparent what the difference is between them. We all have cookie fatigue.

The open protocol approach faces a paradox: decentralization and no central authority requires consistent consent and choice, but choice creates cognitive overhead.

When presented with a new MCP server, how does a user know if it's safe to trust? Like the proliferation of cookie consent popups, more "user control" often means more decision fatigue (per privacy scholar Daniel Solove a "Kafkaesque consent"), not more actual control. This is why Crosshatch takes a different path: a single trusted intermediary that handles authentication complexity, rather than pushing that complexity onto users in the name of decentralization, hosted on your machine or in the cloud.

In our view, the happy path eventually divorces consent from source data, so that you can integrate context into LMs and client apps via your agent irrespective of where it came from.  That is, instead of sharing

• gmail.readonly
• calendar.readonly

we think you should be able to share coherent groups of events e.g., recent

• purchases
• hotel reservations
• reservations

irrespective of where the events were observed AND irrespective of what endpoints and latency are available from among source endpoints.  

Further, the server that manages these connections and permissions should be trusted. You shouldn’t have to read a new end user legal agreement every time you use an MCP server.

These three reasons:

• Simplified consent over aggregated data
• Trusted intermediary with well-known governance
• Unified data model enabling simple retrieval

are why we’re building Crosshatch as a single Personal MCP server – hosted in the cloud or on your local machine – that you can authenticate to anything with simple and intuitive consent mechanisms.

For developers looking to enable rich personalization without protocol complexity, we invite you to explore our docs or connect with our team.