The Velocity of Change

AI is moving at a pace that makes Moore’s Law look leisurely. Consider this: Lovable reportedly reached $100 million in ARR in just 8 months—the fastest-growing startup in history. Cursor hit a $9.9 billion valuation with $500 million ARR. These aren’t just impressive numbers; they’re indicators of a fundamental shift in how software gets built and consumed.

By late 2024, Google reported that 25% of all new code was AI-generated. A year later, Anthropic’s CEO revealed that for some internal teams, that number has reached 70-90%. This isn’t gradual evolution—it’s a step function change in software development velocity.

The Rise of Vibe Coding

I’ve been experimenting with vibe coding myself, primarily using Cursor. The experience is both exhilarating and humbling. As an experienced software engineer, I can carefully guide the AI to build functional applications rapidly. Where it still struggles—like when I asked it to perform Test-Driven Development and it started modifying code to pass tests rather than fixing the actual issues—shows we’re not quite at full autonomy yet. But the trajectory is clear: people are increasingly building complete applications using nothing but AI.

Junior developers using these tools report 21-40% speed increases for routine tasks. More importantly, non-developers are now building functional software. This democratization of development isn’t just changing who can build software—it’s changing what gets built.

The Perfect Storm Against SaaS

Several converging trends are creating an existential threat to traditional SaaS:

1. AI Can Now Build the Entire Stack

SaaS, at its core, is a combination of:

• Data management

• Business logic

• User interfaces

• Connectivity

AI can now handle all of these components. It writes business logic, controls databases, and increasingly builds complete user interfaces (Google’s Flash UI being a prime example). OpenAI is innovating with UI widgets that appear directly in chat interfaces, essentially embedding micro-applications within conversations.

2. Direct Competition from Chat Interfaces

OpenAI and Anthropic have both launched health-focused chat interfaces that directly challenge existing health SaaS platforms. This isn’t theoretical disruption—it’s happening now. Why pay for a specialized meditation app or symptom tracker when an AI chat interface can provide personalized guidance instantly?

3. The Bloat Problem

Many mature SaaS products have become victims of their own success. They’re bloated with features that most users never touch. Vibe-coded alternatives have a compelling advantage: they do exactly what a user wants, nothing more, nothing less. They may not be as polished or pretty, but they’re often a better fit for the user’s actual needs.

The Migration Pattern

I see a clear migration path emerging. Simple, single-purpose SaaS applications will fall first, such as:

• Calendar scheduling (Calendly)

• Social media posting (Buffer, Hootsuite)

• Basic health and lifestyle apps

These tools have minimal moats and can be replicated by a competent vibe coder in hours, not months. Consumer and SMB markets will lead this exodus—they have lower switching costs and simpler requirements that are easier to vibe code.

Enterprise SaaS has more breathing room, but not much. The complexity that once protected enterprise software is becoming increasingly manageable by AI systems.

The Moat Question

The survival of any SaaS company now hinges on a simple question: what’s your moat?

SaaS companies with genuine moats will survive and potentially thrive:

• Proprietary data that has inherent value

• Network effects that make switching costly

• Regulatory compliance that requires certification

• Deep integrations that create switching friction

Without these moats, SaaS companies are essentially selling convenience—and convenience is exactly what AI-generated micro apps provide, often better and cheaper.

The Infrastructure Gap

There’s a critical piece missing in this new world: connectivity infrastructure for micro apps.

While platforms like Zapier and n8n work well for businesses building internal tools, they’re not designed for deploying vibe-coded applications that others can use. We need a new platform architecture where micro apps can:

• Share data seamlessly

• Communicate with other users

• Maintain security and privacy

• Scale automatically

This gap represents both the biggest challenge and the biggest opportunity in the transition away from traditional SaaS.

The Support Paradox

When something breaks in a vibe-coded app, who fixes it? This question points to an emerging product category: AI infrastructure assistants that can automatically debug, fix, and maintain vibe-coded applications. We’re not there yet—as my TDD experiments showed, AI still struggles with certain debugging scenarios—but this will be solved.

The Platform Wars

The race to become the platform for these micro apps is already underway:

• OpenAI and Anthropic are early contenders with their MCP interfaces and chat widgets

• Startups like Lovable and Manus AI have captured the vibe coder market

• Google is a serious dark horse with incredible AI infrastructure—they may be building something in stealth

The winner of this platform war will essentially become the new operating system for AI-generated software.

My Predictions for 2026 and Beyond

1. Vibe coding becomes production-ready
We’ll see tooling that makes it trivial to deploy vibe-coded apps securely and at scale. The current gap between “it works on my machine” and “it’s production-ready for thousands of users” will narrow dramatically.

2. Full-stack AI platforms emerge
Vibe coding tools will evolve into complete deployment and integration platforms. Think Heroku meets GPT meets Zapier—all in one seamless experience.

3. Browser-based development becomes the norm
Users will vibe code complete interfaces and applications entirely within browsers. No local development environment needed.

4. The SaaS reckoning becomes public
By late 2026, we’ll see leading SaaS companies publicly acknowledge that AI alternatives—whether vibe-coded apps or AI chat tools—are causing growth stagnation. The first major SaaS bankruptcy blamed on AI disruption will be a watershed moment.

The Pricing Revolution

The monthly subscription model that defined SaaS may not survive this transition. We’re likely moving toward usage-based AI pricing, though human psychology favors predictable costs. I expect we’ll see tiered “AI usage” plans that mirror current SaaS tiers but fundamentally change what we’re paying for—compute and intelligence rather than features and seats.

Final Thoughts

The SaaS model isn’t going to disappear overnight, but its dominance is ending. We’re entering an era where software becomes truly personal—not personalized by configuration, but personally created on demand.

Smart SaaS companies need to act now: identify your moat or build one immediately. If you can’t, consider a pivot while you still have runway. The companies that survive will be those that embrace AI not as a feature to add, but as a fundamental restructuring of how software gets created and delivered.

The irony isn’t lost on me: SaaS promised to democratize access to software, but AI is democratizing the creation of software itself. The revolution that SaaS started, AI will complete—just not in the way SaaS companies expected.

Credits: Open Source LLM’s were used to support the research and editing of this post.

I started by running my command line app configured to use Claude 3.5 from Anthropic. I asked it to list the tools it can access and then inquired about the parameters for the query email tool. Claude correctly returned a detailed list of parameters—such as selector, field, sort, limit, skip, and count—demonstrating its full support for filtering and sorting.

Next, I switched my configuration to use OpenAI’s GPT-4. After updating the settings, I ran the same command to view the available tools. While GPT-4 did list the tools (with names or descriptions), when I asked for the parameters of the query email tool, it only returned four: field, limit, skip, and count. Notably, it omitted the selector and sort parameters. Without these, it's difficult to filter emails (for example, by using a regular expression or distinguishing between sent and received emails) effectively.

I also tested Llama 3.3 70B. When configured with Llama, the model initially tried to execute the tools rather than just listing them. After a second attempt—making sure it only listed the parameters—it successfully returned the complete set, including selector and sort.

This inconsistency, particularly with GPT-4 and other OpenAI models, limits their utility in scenarios where full tool parameter support is required. I’m curious to know if others have experienced similar issues or have found workarounds.

“An open standard we've been working on at Anthropic that solves a core challenge with LLM apps - connecting them to your data.

No more building custom integrations for every data source. MCP provides one protocol to connect them all.”

It’s important to make a clarification here:

Model Context Protocol doesn’t negate the need to build custom integrations for every data source. MCP is a protocol that enables a LLM to have a common pathway to integrate with every data source. The integrations still need to be built for each data source.

I thought I’d try it out to see how well it worked and if it was a viable way to connect my data in Verida (email, calendar, google docs, telegram messages etc.) to Claude.

Here’s a detailed breakdown of my experience.

Background research

I started by skimming through the MCP documentation, starting with the Getting Started guide. I am familiar with using Claude via AWS Bedrock, so planned on integrating directly there, however it became clear that MCP is only supported on Claude desktop as of today:

After groking the architecture, it realized I would need to create a MCP server, then configure Claude desktop to know about my server. Not too difficult I thought.

So I jumped into the documentation on creating my first MCP server with typescript.

Creating a MCP server

After reading the MCP server for typescript example I learned there are different types of interfaces in the protocol such as; resources, prompts, tools. I clearly needed a “tool” to enable querying my data, but wasn’t sure about the other interfaces.

I decided to take a closer look at the Typescript SDK in Github and discovered a collection of example servers. As I had the basic concepts in mind, modifying an existing server would probably be easier.

I found a PostgreSQL example server, this seemed perfect as a starting point. Reading the code, it provides two key interfaces:

1. Resources: This lists the available database tables available to be queried, presumably so Claude knows about them.

2. Tools: The actual “query” tool to extract data from the database for Claude to process.

I proceeded to spend the next hour creating a new Github repo with this PostgreSQL server as a starting point. I added the Verida SDK as a dependency in the package.json and copied some existing code to query my private data stored on Verida.

After some usual wrangling with typescript build processes, I finally had something that I hoped would be close to working.

Now, how to test?

Testing my MCP server

For the most part, the MCP documentation is quite good. It clearly has large gaps, where there are placeholders for future content, but the current content is clear and concise. There’s a clear section on debugging and it points out they’ve built a really great inspector to help with testing your MCP server.

I spun up the inspector in no time and opened it in my local browser.

I could easily navigate to see the “Resources” I had exposed. I could also navigate to “Tools” and manually execute my “query” tool.

This is where I hit my first real issue. Debugging currently sucks. The documentation has some basic dot points on development workflow. Basically, you have change your code, rebuild your code, reconnect the inspector, then test again.

There is no ability (that I’m aware of) to attach my IDE to a debugger for real-time debugging. There is also no ability to console.log output to see what’s going on in the server as this causes problems with Claude.

As such, my debugging ended up being throwing Errors to get insight into values of variables on the code and those Errors propagated up to the inspector for me to review. Very slow and cumbersome, but I assume Anthropic are working on a better flow here.

I was able to work through my issues and ended up with my two interfaces fully tested and working via the MCP inspector:

• Schema resources: List all the available database schemas that can be queried

• Query tool: Run a database query against one of the database schemas

Connecting my MCP server with Claude

As mentioned above, MCP is only supported on the Desktop version of Claude (which I didn’t have). I downloaded, signed in and was ready to test.

First, I needed to configure Claude Desktop to know about my MCP server. In the Claude Desktop settings there is a “Developer” section, which can open a JSON configuration file where you enter your MCP configuration.

This was pretty straightforward to do, and once I restarted Claude, the settings showed my MCP server was available.

However, I hit a snag:

Claude was showing this error message with no further information. According to the MCP documentation there should be logs on my local computer to help debug, however I have none.

After a lot of mucking around, I realized there was an issue with my schema resources endpoint which I fixed. Now, after restarting Claude Desktop it appeared I was connected properly.

There is a little tool icon that appears:

Clicking that icon shows information about the MCP tools that are connected.

Ok, I’m all set, now let’s test this out

Using Claude with my MCP Server

Unfortunately, this is where things started to fall down.

Claude really struggled to discover my server and use it, even with my increasingly specific attempts to use it.

I started with something simple, summarize my recent calendar entries.

It’s clear here that Claude couldn’t make the connection between me asking for “calendar entries” and the CALENDAR database schema that was available via my MCP Server.

I thought I’d ask it what it know about the connected MCP servers, but alas it doesn’t seem to know:

I tried to be much more explicit and ask for information about the available schema resources, but that didn’t work either:

I tried a different approach and use more keywords:

Now, this did work! (sort of).

This prompt appeared asking for my approval to allow the query tool to run:

I accepted, but as you can see from the screenshot above, it failed to return any results. This is because calendar_entries is not the correct schema name, it should be CALENDAR (which is returned from my MCP server resources endpoint).

At this point, I’m unclear if the inability for Claude to establish the link between the schema resources (CALENDAR) and the query tools is something I haven’t done well enough in my MCP server or is more an issue with Claude.

So, I decided to be very very explicit with running a query:

So, this is much better. You can see it has sent a MCP server tool request with the correct schemaName of CALENDAR, and then it even tried a different variation when that didn’t work.

But.. it didn’t work and this is where I gave up (for now).

The query was clearly executing in the MCP server, but was returning an error in the top right of Claude desktop:

As mentioned above, I have no logs available on my local machine to give more insight on this error.

I replicated the exact same CALENDAR query using the MCP inspector console and it works perfectly every time, which is rather confusing.

Summary

MCP seems promising. The concept of a common interface for connecting LLM’s to external data sources is going to be really important moving forward.

I had some issues with debugging and getting things to work, however I expect those things to be improved over time. All things considered, it was a fairly good developer experience for a first release of a new protocol.

I am concerned about the lack of Claude’s ability to recognize that a prompt can use an available tool and the challenges of linking that tool precisely enough to make it work correctly. It’s not really viable to be asking Claude very specific questions to use a tool, it really needs to seamlessly integrate it with your usage.

This was my first attempt at using MCP, so it’s quite possible I missed a few things that could have improved my server and produced better results. That being said, this is a warts and all breakdown after spending a couple of hours playing with MCP and I expect it would be similar to the experience of other developers trying MCP for the first time.

1. The Brain: The Core of AI Computation

Every AI agent needs a "brain"—a system that processes and performs tasks for us. This brain is an amalgamation of various technologies:

• Large Language Models (LLMs): The foundation of most AI agents, these models are trained to understand and generate human-like responses.

• Fine-Tuning: A step further, where LLMs are tailored using personal data to offer more personalized and accurate outputs.

• Retrieval-Augmented Generation (RAG): A method that smartly incorporates user data into the context window, helping the LLM access relevant personal information and provide more meaningful interactions.

• Databases: Both vector and traditional databases come into play, enabling the AI agent to store and retrieve vast amounts of information efficiently.

The synergy of these technologies forms an AI's cognitive abilities, allowing it to generate intelligent and context-aware responses.

2. The Heart: Data Integration and Personalization

An AI agent's brain is only as good as the data it has access to. The "heart" of the AI agent is its data engine, which powers personalization. This engine requires access to various types of user data, such as:

• Emails and Private Messages: Insights into communication preferences.

• Health Records and Activity Data: Information from fitness trackers or health apps like Apple Watch.

• Financial Records: Transaction histories and financial trends.

• Shopping and Transaction History: Preferences and past purchases for tailored shopping experiences.

The more data an AI agent has, the better it can serve as a "digital twin," representing and anticipating user needs.

3. The Limbs: Acting on Your Behalf

For an AI agent to be genuinely useful, it must do more than just think and understand—it needs the capability to act. This means connecting to various services and APIs to:

• Book Flights or Holidays: Manage travel arrangements autonomously.

• Order Services: Call for a ride, order groceries, or make appointments.

• Send Communications: Draft and send emails or messages on your behalf.

To enable these capabilities, the agent must be seamlessly integrated with a wide array of digital services and platforms, with user consent being a critical aspect.

4. Privacy and Security: The Final Piece

As these agents become more capable and integrate deeply into our lives, ensuring privacy and security is paramount. The more data an agent holds, the more vulnerable it becomes to potential misuse. Here's why this matters:

• Self-Sovereign Technologies: The ideal future of AI agent technology is built on decentralized and self-sovereign systems. These systems empower users as the sole owners of their data and AI computation.

• Guarding Against Big Tech Control: Companies like Google, Apple, and Microsoft already possess vast amounts of user data. Concentrating even more data into their control can lead to potential exploitation. A decentralized model prevents these corporations from having unrestricted access to personal AI agents, ensuring that only the user can access their private information.

Final Thoughts

For AI agents to flourish and be trusted, they must be built on a foundation that respects user privacy and autonomy. In essence, a robust AI agent will consist of:

• A Brain: Advanced AI computation.

• A Heart: A rich data engine powered by user data.

• Limbs: The ability to take action on behalf of the user.

However, without strong privacy and security measures, these agents could pose significant risks. The future of AI agents hinges on creating a technology layer that preserves individual ownership, enforces privacy, and limits the control of major tech companies. By ensuring that only the agent’s owner can access its data, we set the stage for a safer, more empowering digital future.

If you are a builder, particularly in the AI space, Verida has just announced exclusive early access for builders to try the Verida AI tools for AI builders. You can register here.

Here’s a snapshot of the Verida API’s for AI builders to access private user data:

Please reach out if you’re interested in learning more or keen to meet in person if you are also attending Devcon.

I’ll be attending a number of other relevant events over the week, including:

• Decentralized Data Summit

• FHE Summit

• dAGI Summit

• Scaling DeAI Summit

• Cambridge Research: AI for Web3

• Applied AI + Crypto Day

• Encryption Day: ZK, FHE & MPC

I look forward to meeting many of the members of the Verida community in person at Bangkok!

Confidential Compute Nodes

Confidential Compute Nodes running on the Verida Self-Sovereign Compute Network operate a web server within a secure enclave environment to handle compute requests and responses.

There will be different types of nodes (i.e., LLM, User API) that will have different code running on them depending on the service(s) they are providing.

For maximum flexibility, advanced users and developers will be able to run compute nodes locally, on any type of hardware.

Nodes have key requirements they must adhere to:

GPU access is required for some compute nodes (i.e., LLM nodes), but not others. As such, the hardware requirements for each node will depend on the type of compute services running on the node.

Code Verifiability is critical to ensure trust in the compute and security of user data. Nodes must be able to attest the code they are running has not been tampered with.

Upgradability is essential to keep nodes current with the latest software versions, security fixes and other patches. Coordination is required to ensure applications can ensure their code is running on the latest node versions.

API endpoints are the entry point for communicating with nodes. It’s essential a web server host operates within the secure enclave to communicate with the outside world.

SSL termination must occur within the secure enclave to ensure the host machine can’t access API requests and responses.

Resource restraints will exist on each node (i.e., CPU, memory) that will limit the number of active requests they can handle. The network and nodes will need to coordinate this to ensure nodes are selected that have sufficient resources available to meet any given request.

Interoperability and Extensibility

In order to create an efficient and highly interoperable ecosystem of self-sovereign API’s, it's necessary to have a set of common data standards. Verida’s self-sovereign database storage network provides this necessary infrastructure via guaranteed data schemas within encrypted datasets, providing a solid foundation for data interoperability.

Developers can build new self-sovereign compute services that can be deployed on the network and then used by other services. This provides an extensible ecosystem of API’s that can all communicate with each other to deliver highly complex solutions for end users.

Figure 4: Interoperable data between self-sovereign AI services

Over time, we expect a marketplace of private AI products, services and APIs to evolve.

Service Discovery

Verida’s self-sovereign compute network will enable infrastructure operators to deploy and register a node of a particular service type. When an API needs to send a request to one of those service types, it can perform a “service lookup” on the Verida network to identify a suitable trusted, verifiable node it can use to send requests of the required service type.

User Data Security Guarantees

It is essential to protect user privacy within the ecosystem and prevent user data leaking to non-confidential compute services outside the network. Each service deployed to the network will be running verifiable code, running on verifiable confidential compute infrastructure.

In addition, each service will only communicate with other self-sovereign compute services. Each API request to another self-sovereign compute service will be signed and verified to have been transmitted by another node within the self-sovereign network.

Tokenized Payment

The VDA token will be used for payment to access self-sovereign compute services. A more detailed economic model will be provided, however the following key principles are expected to apply.

End users will pay on a “per-request” basis to send confidential queries to compute nodes and the services they operate. The cost per request will be calculated in a standardized fashion that balances the computation power of a node, memory usage and request time. Applications can sponsor the request fees on behalf of the user and then charge a subscription fee to cover the cost, plus profit, much like a traditional SaaS model.

Node operators will be compensated for providing the confidential compute infrastructure to Verida’s Self-Sovereign Compute Network.

Builders of services (i.e., AI Prompts and Agents) will be able to set an additional fee for using their compute services, above and beyond the underlying “per-request” compute cost. This open marketplace for AI Agents and other tools drives innovation and provides a seamless way for developers to generate revenue from the use of their intellectual property.

Verida Network will charge a small protocol fee (similar to a blockchain gas fee) on compute fees.

Other Use Cases

Data Training Marketplaces

Verida’s Private Data Bridge allows users to reclaim their private data from platforms such as Meta, Google, X, email, LinkedIn, Strava, and much more.

Users on the Verida network could push their personal data into a confidential compute service that anonymizes their data (or generates synthetic data) which is made available to various AI data marketplaces. This provides an option for users to monetize their data, without risk of data leakage, while unlocking highly valuable and unique datasets such as private messages, financial records, emails, healthcare data for training purposes.

Managed Crypto Wallets

There is a vast array of managed wallet services available today that offer different trade-offs between user experience and security.

Having an always available cloud service that can protect user’s private keys, but still provide multiple authorization methods for a user is extremely useful to onboard new users and provide additional backup protection measures for existing users.

Such a managed wallet service becomes rather trivial to build and deploy on the Verida self-sovereign compute network.

Verifiable Credentials

Verida has extensive experience working with decentralized identity and verifiable credential technology, in combination with many ecosystem partners.

There is a significant pain point in the industry, whereby developers within credential ecosystems are required to integrate many disparate developer SDK’s to offer an end-to-end solution. This is due to the self-sovereign nature of credentials and identity solutions where a private key must be retained on end user devices to facilitate end-to-end security.

Verida’s self-sovereign compute network can provide a viable alternative, whereby application developers can replace complex SDK integrations with simple self-sovereign APIs. This makes integration into mobile applications (such as identity wallets) and traditional web applications much easier, simpler and viable.

This could be used to provide simple API integrations to enable:

1. Identity wallets to obtain access to a user’s verifiable credentials

2. End users to pre-commit selective disclosure rules for third party applications or identity wallets, without disclosing their actual credentials

3. Provide trusted, verifiable universal resolvers

4. Trust registry APIs

Any complex SDK that requires a user’s private key to operate, could be deployed as a micro service on Verida’s self-sovereign compute network to provide a simpler integration and better user experience.

Conclusion

Verida's mission to empower individuals with control over their data continues to drive our innovations as we advance our infrastructure. This Litepaper outlines how the Verida Network is evolving from decentralized, privacy-preserving databases to include decentralized, privacy-preserving compute capabilities, addressing critical issues in AI data management and introducing valuable new use cases for user-controlled data.

As AI faces mounting challenges with data quality, privacy, and transparency, Verida is at the forefront of addressing these issues. By expanding our network to support privacy-preserving compute, we enable the more effective safeguarding of private data while allowing it to be securely shared with with leading AI models. This approach ensures end-to-end privacy and opens the door to hyper-personalized and secure AI experiences.

Our solution addresses three fundamental problems: enabling user access to their private data, providing secure storage and sharing, and ensuring confidential computation. Verida's "Private Data Bridge" allows users to securely reclaim and manage their data from various platforms and facilite its use in personalized AI applications without compromising privacy.

While we are not focusing on decentralized AI model training or distributed inference, Verida is committed to offering high-performance, secure, and trusted infrastructure for managing private data. We are collaborating with partners developing private AI agents, AI data marketplaces, and other privacy-centric AI solutions, paving the way for a more secure and private future in AI. This empowers users to be confident about the ways their data is used, and receive compensation when they do choose to share elements of their personal data.

You can learn more or get involved at https://www.verida.network/

Confidential Compute

A growing number of confidential compute offerings are being offered by the large cloud providers that provide access to Trusted Execution Environments (TEEs). These include: AWS Nitro, Google Confidential Compute and Azure Confidential Compute. Tokenized confidential compute offerings such as Marlin Oyster and Super Protocol have also emerged recently.

These compute offerings typically allow a container (such as a Docker instance) to be deployed within a secure enclave on secure TEE hardware. The enclave has a range of verification and security measures that can prove that both the code and the data running in the enclave is the code you expect and that the enclave has been deployed in a tamper-resistant manner.

There are some important limitations to these secure enclaves, namely:

1. There is no direct access available to the enclave from the infrastructure operator1. Communication occurs via a dedicated virtual socket between the secure enclave and the host machine.

2. There is no disk storage available, everything must be stored in RAM.

3. Direct GPU access is typically not available within the secure enclave (necessary for high performance LLM training and inference), however this capability is expected to be available in early 2025.

The Verida network is effectively a database offering high performance data synchronization and decryption. While secure enclaves do not have local disk access (by design), it is possible to give a secure enclave a private key, enabling the enclave to quickly download user data, load it into memory and perform operations.

While enclaves do not have direct access to the Internet, it is possible to facilitate secure socket connections between the host machine and enclave to “proxy” web requests to the outside world. This increases the surface area of possible attacks on the security of the enclave, but is also a necessary requirement for confidential compute that interacts with other web services.

It is critical that confidential AI inference for user prompts has a fast response time to ensure a high quality experience for end users. Direct GPU access via confidential compute is most likely necessary to meet these requirements. Access to GPUs with TEEs is currently limited, however products such as the NVIDIA H100 offer these capabilities and these capabilities will be made available for use within the Verida network in due course.

Self-Sovereign Compute

Verida offers a self-sovereign compute infrastructure stack that exists on top of confidential compute infrastructure.

Figure 1: Self-Sovereign Compute Architecture

The self-sovereign compute infrastructure provides the following guarantees:

1. User data is not accessible by infrastructure node operators.

2. Runtime code can be verified to ensure it is running the expected code.

3. Users are in complete control over their private data and can grant / revoke access to third parties at any time.

4. Third-party developers can build and deploy code that will operate on user data in a confidential manner.

5. Users are in complete control over the compute services that can operate on their data and can grant / revoke access to third parties at any time.

There are two distinct types of compute that have different infrastructure requirements; Stateless Confidential Compute and Stateful Confidential Compute.

Stateless (Generic) Confidential Compute

This type of computation is stateless, it retains no user data between API requests. However, it can request user data from other APIs and process that user data in a confidential manner.

Here are some examples of Generic Stateless Compute that would operate on the network.

Figure 2: Verida Personal Data Bridge

Private Data Bridge facilitates users connecting to third-party platform APIs (ie: Meta, Google, Amazon, etc.). These nodes must operate in a confidential manner as they store API secrets, handle end user access / refresh tokens to the third-party platforms, pull sensitive user data from those platforms, and then use private user keys to store that data in users’ private databases on the Verida network.

LLM APIs accept user prompts that contain sensitive user data, so they must operate in a confidential compute environment.

AI APIs such as AI prompt services and AI agent services provide the “glue” to interact between user data and LLMs. An AI service can use the User Data APIs (see below) to directly access user data. This enables it to facilitate retrieval-augmented generation (RAG) via the LLM APIs, leveraging user data. These APIs may also save data back to users’ databases as a result of a request (i.e., saving data into a vector database for future RAG queries).

See Self-Sovereign AI Interaction Model for a breakdown of how these generic compute services can interact together to provide AI services on user data.

Stateful (User) Confidential Compute

This type of computation is stateful, where user data remains available (in memory) for an extended period of time. This enhances performance and, ultimately, the user experience for end users.

A User Data API will enable authorized third party applications (such as private AI agents) to easily and quickly access decrypted private user data. It is assumed there is a single User Data API, however in reality it is likely there will be multiple API services that operate on different infrastructure.

Here are some examples of the types of data that would be available for access:

1. Chat history across multiple platforms (Telegram, Signal, Slack, Whatsapp, etc.)

2. Web browser history

3. Corporate knowledge base (ie: Notion, Google Drive, etc)

4. Emails

5. Financial transactions

6. Product purchases

7. Health data

Each of these data types have different volumes and sizes, which will also differ between users. It’s expected the total storage required for an individual user would be somewhere between 100MB and 2GB, whereas enterprise knowledge bases will be much larger.

In the first phase, the focus will be on structured data, not images or videos. This aligns with Verida’s existing storage node infrastructure that provides and aids the development of a first iteration of data schemas for AI data interoperability.

The User Data API exposes endpoints to support the following data services:

1. Authentication for decentralized identities to connect their account to a User Data API Node

2. Authentication to obtain access and refresh tokens for third-party applications

3. Database queries that execute over a user’s data

4. Keyword (ie: Lucene) search over a user’s data

5. Vector database search over a user’s data

Connecting Stateful Compute to Decentralized Identities

Third party applications obtain an access token that allows scoped access to user data, based on the consent granted by the user.

A decentralized identity on the Verida network can authorize three or more self-sovereign compute nodes on the network, to manage access to their data for third-party applications. This is via the serviceEndpoint capability on the identity’s DID Document. This operates in the same way that the current Verida database storage network allocates storage nodes to be responsible for user data.

Secure enclaves have no disk access, however user data is available (encrypted) on the Verida network and can be synchronized on demand given the appropriate user private key. It’s necessary for user data to be “hot loaded” when required which involves synchronizing the encrypted user data from the Verida network, decrypting it, storing it in memory and then adding other metadata (i.e., search indexes). This occurs when an initial API request is made, ensuring user data is ready for fast access for third-party applications.

After a set period of time of inactivity (i.e., 1 hour) the user data will be unloaded from memory to save resources on the underlying compute node. In this way, a single User Data API node can service requests for multiple decentralized identities at once.

It will be necessary to ensure “hot loading” is fast enough to minimize the first interaction time for end users. It’s also essential these compute nodes have sufficient memory to load data for multiple users at once. Verida has developed an internal proof-of-concept to verify the “hot loading” concept with user data will be a viable solution.

For enhanced privacy and security, the data and execution for each decentralized identity will operate in an isolated VM within the secure enclave of the confidential compute node.

Stay tuned, the third and final release of the Litepaper will be made available next week.

Introduction

Verida’s mission has always been clear: empower individuals to own and control their data. Now, we’re taking it further.

This Technical Litepaper presents a high-level outline of how the Verida Network is growing beyond decentralized, privacy preserving databases, to support decentralized, privacy-preserving compute optimized for handling private data. There are numerous privacy issues currently facing AI that web3 and decentralized physical infrastructure networks can help solve. From Verida’s perspective, this represents an expansion of our mission from allowing individuals to control their data to introducing new and powerful ways for users to benefit from their data.

Current AI Data Challenges

We are running out of high-quality data to train LLMs

Public internet data has been scraped and indexed by AI models, with researchers estimating that by 2026, we will exhaust high-quality text data for training LLMs. Next, we need to access private data, but it’s hard and expensive to access.

Private enterprise and personal AI agents need to access private data

There is a lot of excitement around the next phase of AI beyond chat prompts. Digital twins or personal AI agents that know everything about us and support every aspect of our professional and personal lives. However, to make this a reality AI models need access to private, real time context-level user data to deliver more powerful insights and a truly personalized experience.

Existing AI platforms are not private

The mainstream infrastructure providers powering the current generation of AI products have full access to prompts and training data, putting sensitive information at risk.

AI trust and transparency is a challenge

Regulation is coming to AI and it will become essential that AI models can prove the training data was high quality, ethically sourced. This is critical to reduce bias, misuse and improve safety in AI.

Data creators aren’t being rewarded

User-owned data is a critical and valuable resource for AI and those who create the data should benefit from its use. Reddit recently sold user data for $200M, while other organizations  have reached similar agreements. Meta is training its AI models on user data from some countries, but excluding European users due to GDPR preventing them from doing so without user consent.

Verida’s Privacy Preserving Infrastructure

Verida has already developed the leading private decentralized database storage infrastructure (see Verida Whitepaper) which provides a solid foundation to address the current AI data challenges.

Expanding the Verida network to support privacy-preserving compute enables private, encrypted data to be integrated with leading AI models, ensuring end-to-end privacy, safeguarding data from model owners. This will unlock a new era of hyper-personal and safe AI experiences.

AI services such as ChatGPT have full access to any information users supply and have already been known to leak sensitive data. By enabling model owners access to private data, there is increased risks of data breaches, imperiling privacy, and ultimately limiting AI use cases.

There are three key problems Verida is solving to support secure private AI:

1. Data Access: Enabling users to extract and store their private data from third party platforms for use with emerging AI prompts and agents.

2. Private Storage and Sharing: Providing secure infrastructure allowing user data to be discoverable, searchable and accessible with user-consent to third party AI platforms operating within verifiable confidential compute environments.

3. Private Compute: Provide a verifiable, confidential compute infrastructure enabling agentic AI computation to securely occur on sensitive user data.

Supporting the above tasks, Verida is building a “Private Data Bridge”, allowing users to reclaim their data and use it within a new cohort of personalized AI applications. Users can pull their private data from platforms such as Google, Slack, Notion, email providers, LinkedIn, Amazon, Strava, and much more. This data is encrypted and stored in a user-controlled private data Vault on the Verida network.

It’s important to note that Verida is not building infrastructure for decentralized AI model training, or distributed AI inference. Rather, Verida’s focus is on providing a high performance, secure, trusted and verifiable infrastructure suitable for managing private data appropriate for AI use cases.

We have relationships with third parties that are building; private AI agents, AI data marketplaces and other privacy-centric AI use cases.

Comparing Current AI Solutions

AI solutions can be deployed primarily through two methods: cloud-based/hosted services or on local machines.

Cloud-based AI services, while convenient and scalable, expose sensitive user data to potential risks, as data processing occurs on external servers and may be accessible to third parties.

In contrast, local AI environments offer enhanced security, ensuring that user data remains isolated and inaccessible to other applications or external entities. However, local environments come with significant limitations, including the need for technical expertise that is not available to the majority of users. Moreover, these environments often face performance challenges; for instance, running large language models (LLMs) on standard consumer hardware is typically impractical due to the high computational demands.

Verida’s Confidential Storage and Compute infrastructure offers alternatives to these approaches.

Apple has recently announced Private Cloud Compute that provides a hybrid local + secure cloud approach. AI processing occurs on a local device (ie: mobile phone) by default, then when additional processing power is required, the request is offloaded to Apple’s servers that are operating within a trusted execution environment. This is an impressive offering that is focused on solving important security concerns relating to user data and AI. However, it is centralized, only available to Apple devices and puts significant trust in Apple as they control both the hardware and attestation keys.

Self-Sovereign AI Interaction Model

Let’s look at what an ideal model of confidential AI architecture looks like. This is an interaction model of how a basic “Self-Sovereign AI” chat interface, using a RAG-style approach, would operate in an end-to-end confidential manner.

Figure 3: Self-Sovereign AI Interaction Model

The End User Application in this example will be a “Chat Prompt” application. A user enters a prompt (i.e., “Summarize the conversation I had with my mates about the upcoming golf trip”).

A Private AI API endpoint (AI Prompt) receives the chat prompt and breaks down the request. It sends a prompt to the LLM, converting the original prompt into a series of search queries. The LLM could be an open source or proprietary model. Due to the confidential nature of the secure enclave, proprietary models could be deployed without risk of IP theft by the model owner.

The search queries are sent to the User Data API which has access to data previously obtained via Verida’s Private Data Bridge. This data includes emails, chat message histories and much more.

The Private AI API collates the search query results and sends the relevant responses and original prompt to the LLM to produce a final result that is returned to the user.

Verida is currently developing a “showcase” AI agent that implements this architecture and can provide a starting point for other projects to build their own confidential private AI products.

Share

One of the questions to answer is how fast can data, stored in a decentralized database storage network like Verida, be made available to a personal AI agent. This is a critical question as huge time lags will create a poor user experience, making any personal AI products unviable.

There are many ways to use AI to communicate with data, however in this case we are assuming a Retrieval-Augmented Generation (RAG) approach.

Dynamic User Data Queries

The current architecture we are researching involves a “User Data API” that unlocks personal data stored (encrypted) on the Verida network, decrypts the data and then makes it available to AI agents and large language models (LLM’s) on demand.

This poses key latency questions:

1. What is the latency to fetch encrypted data from the network?

2. What is the latency to decrypt the data and make it queryable?

3. What is the latency to make the data searchable via Lucene style search queries?

While (3) isn’t absolutely necessary, at this stage it seems reasonable to assume a Lucene style search is a powerful tool to allow fast, flexible search queries across user data.

Test Setup

I used an early version of the Verida Personal Data Bridge (source code) to pull my most recent 4,000 emails. This resulted in 250MB of raw database data (including PDF attachments converted to text), which became 330MB once database indexes were included.

I then ran the Verida User Data API to hit the search endpoint that searches all my data matching the email schema (https://common.schemas.verida.io/social/email/v0.1.0/schema.json):

http://localhost:5022/search/ds/aHR0cHM6Ly9jb21tb24uc2NoZW1hcy52ZXJpZGEuaW8vc29jaWFsL2VtYWlsL3YwLjEuMC9zY2hlbWEuanNvbg===?q=name:Luca

For testing purposes, the Personal Data Bridge and User Data API are running locally on my Macbook Pro. The Verida account is on the Banksia testnet, connected to a Storage Node running on my local machine.

Test Results

Here’s the timed output from this initial set of tests:

Latency

Making a /search request involves the following time sensitive operations:

1. Time to sync encrypted user data from the Verida network to the local machine

2. Time to decrypt the user data into a decrypted database

3. Time to load all records from the decrypted database into memory

4. Time to load all data into an in memory Lucene index and query it

The screenshot shows three requests running over 4,000 of my personal emails.

Request 1

The first request took 3m 41s to complete steps 1,2,3.

Step 4 took an incredibly fast 38 ms.

Request 2

The second request used a cached copy of the Lucene index so only needed to complete step 4, again returning results in 38 ms.

Request 3

For the third request, I shut down the server, which cleared the in memory Lucene cache.

This request didn’t need to complete step 1. It completed steps 2 and 3 in 34s and generated the Lucene results in 26ms.

Note: Step 1 is actually pulling data from a Storage Node running on my local machine, not the network itself. As such step 1 is a bit faster than real world usage which would have this code running in data centres with fast pipes.

Memory

The baseline memory usage of the User Data API server is (bytes):

{
    "rss": 115982336,
    "heapTotal": 36827136,
    "heapUsed": 33001104,
    "external": 2117266,
    "arrayBuffers": 54788
}

After loading the data in-memory (bytes):

{
    "rss": 772591616,
    "heapTotal": 362926080,
    "heapUsed": 351119608,
    "external": 2156712,
    "arrayBuffers": 82355
}

This shows an increase in memory usage for the process from a baseline of 115MB to 772MB.

Discussion

Here’s a breakdown of the learnings and a discussion on each.

It’s important to note that this infrastructure is intended to be run within secure enclaves to guarantee end-to-end privacy of user data. As it currently stands, secure enclaves only support in-memory storage, with no access to long term physical disk storage.

Latency

These are roughly extrapolated times for each step:

Step 1: Sync encrypted data: ~3 minutes

Step 2 & 3: Locally decrypt data and load into memory: ~34 seconds

Step 4: Load data into Lucene and run query: 34 milliseconds

The time to query the data is incredibly fast at 34ms, which is a huge positive.

However, the time to load the data in Step 1 is a blocker to a great user experience. That being said, this step only needs to occur once for any given server.

Under the Verida model of using decentralized identifiers, each Verida account will specify specific confidential compute nodes to act on their behalf. These nodes can sync this data once and then receive regular updates (using the Verida network real-time sync capabilities), keeping it up-to-date at all times.

The 34 seconds to decrypt and load into memory only needs to happen when the User Data API doesn’t have user data in it’s memory cache. This will happen when; 1) The server starts for the first time, or 2) If the cache is cleared (likely to happen after a period of inactivity for a user).

In reality, there may be a 30 second delay for this load process when a user makes their first request and then all subsequent requests should be very fast. Better hardware will drastically improve this load time.

Memory Usage

Memory usage ballooned from 115MB to 772MB, an increase of 657MB. The raw uncompressed data (stored in memory database) was 330MB including indexes. 657MB is almost exactly 2x330MB which makes sense, because the data is actually loaded into memory twice. One copy is an in-memory database, the second copy is an in-memory Lucene database.

It’s quite possible the Lucene search service proves to be more useful than the in-memory database, allowing it to be dropped and halving that memory usage.

A future piece of work is to investigate running Lucene locally within the secure enclave, instead of storing in-memory. This would potentially eliminate the 30 second load time and significantly reduce the memory usage of the User Data API server.

4,000 emails?

Our vision is to enable AI to access all your digital data; email history, message history from chat platforms, search and browser history, health care data, financial records and more. That obviously requires a lot more than the 330MB of data used in this example.

The Personal Data Bridge supports pulling Facebook page likes and posts. I have pulled down over 3,000 facebook posts (excluding images and videos) which was less than 10MB.

We are still learning the volume of data for each dataset as we connect more sources to the Personal Data Bridge, but it’s probably safe to assume that email will be the largest data set for most people.

In my case 4,000 emails represented just 2 months of one of my multiple inboxes. The vast majority of those messages are junk / spam that I never intend to read. It may be sensible to add an additional processing layer over the data to eliminate emails that aren’t worth indexing. This will save memory and reduce time.

Extending that idea further, there will likely be a need to build additional metadata based on your personal data to help AI assistants to quickly know more about you. For example, you can enable a LLM to search your email and social media history to create a profile for you; age, gender, family, income, food preferences and much more. This is incredibly useful context to help guide any personal AI assistant, when combined with conducting real time search queries for specific prompts.

Where next?

The current focus is getting an end-to-end solution that can be run on a local machine to connect your personal data to AI LLM’s.

While there are some performance bottlenecks mentioned above that could be investigated further, there is nothing that is an obvious blocker.

To that end, the next key priority is to be able to write a prompt (ie: Create a haiku of the conversation I had with my Mum about Mars) and have it sent to a locally running LLM (ie: Llama3) that has access to user data via the Lucene index to produce a meaningful result.

This post is part of a Privacy / AI series. See Part 1: Top Three Data Privacy Issues Facing AI Today and Part 2: How web3 and DePIN solves AI’s data privacy problems.

Verida is providing key infrastructure that will underpin the next generation of the privacy preserving AI technology stack. The Verida Network provides private storage, sources of personal data and expandable infrastructure to make this future a reality.

Let’s dive into each of these areas in more detail.

Private storage for personal AI models

The Verida network is designed for storing private, personal data. It is a highly performant, low cost, regulatory compliant solution for storing structured database data for any type of application.

Data stored on the network is protected with a user’s private key, ensuring they are the only account that can request access to, and encrypt their data (unless they provide permission to another account).

This makes the Verida Network ideal for storing private AI models for end users. The network’s high performance (leveraging P2P web socket connections), makes it suitable for high speed read / write applications such as training LLMs.

Source of data for training AI models

We’ve all heard the saying “garbage in, garbage out” when it comes to data. This also applies to training AI models. They are only as good as the data they are fed for training purposes.

The Verida ecosystem provides a broad range of capabilities that make it ideally suited to being a primary source of highly valuable data for training AI models.

Verida has been developing an API data connector framework that enables users to easily connect to existing API’s of centralized platforms and claim their personal data, that they can securely store on the Verida network.

Users on the Verida network will be able to pull health activity data from the likes of Strava and Fitbit. They can pull their private messages from chat platforms, their data from Google and Apple accounts. This can all then be leveraged to train AI models for exclusive use by the user, or that data can be anonymized and contributed to larger training models.

Establishing a data-driven token economy offers a promising avenue for fostering fairness among all stakeholders. Eventually, major tech and data corporations may introduce a token system for service payments, thereby incentivizing users to share their data.

For an example; individuals could leverage their anonymous health data to train AI models for healthcare research and receive token rewards in return. These rewards could then be utilized for subscribing to the service or unlocking premium features, establishing a self-sustaining cycle where data sharing leads to increased service access as a reward. This model fosters a secure and equitable relationship between data contribution and enhanced service access, ensuring that those who contribute more to the ecosystem reap greater benefits in return.

Users could also use their personal data to train AI models designed just for them. Imagine a digital AI assistant guiding you through your life. Suggesting meetup events to attend to improve your career, suggesting a cheaper greener electricity retailer based on your usage, suggesting a better phone plan or simply reminding you of an event you forgot to add to your calendar.

Expandable infrastructure

As touched on in “How web3 and DePIN solves AI’s data privacy problems”, privacy preserving AI will need access to privacy preserving computation to train AI models and respond to user prompts.

Verida is not in the business of providing private decentralized computation, however the Verida identity framework (based on the DID-Core W3C standard) is expandable to connect to this type of Decentralized Physical Infrastructure (DePIN).

Identities on the Verida network can currently be linked to three types of DePIN; Database storage, Private inbox messages, Private notifications. This architecture can easily be extended to support new use cases such as “Private compute” or “Personal AI prompt API”.

With the appropriate partners who support decentralized private compute, there is a very clear pathway to enable personalized, privacy preserving AI leveraging a 100% DePIN technology stack.

This is incredibly exciting, as it will provide a more secure, privacy preserving solution as an alternative to giving all our data to large centralized technology companies.

This post is part of a Privacy / AI series and continues from the Top Three Data Privacy Issues Facing AI Today.

Artificial intelligence (AI) has become an undeniable force in shaping our world. From personalized recommendations to medical diagnosis, AI's impact is undeniable. However, alongside its potential lies a looming concern: data privacy. Traditional AI models typically rely on centralized data storage and centralized computation, raising concerns about ownership, control, and potential misuse.

See part 1 of this series, “Top3 data privacy issues facing AI today”, for a breakdown of key privacy issues which we will explain how web3 can help alleviate these problems.

The emergence of Decentralized Physical Infrastructure Networks (DePIN) are a linchpin for providing privacy preserving decentralized infrastructure to power the next generation of large language models (LLMs).

At a high level, DePINs can provide access to decentralized computation and storage resources that are beyond the control of any single organization. If this computation and storage can be built in such a way that it is privacy preserving; ie: those operating the infrastructure have no access to underlying data or computation occurring, this is an incredibly robust foundation for privacy preserving AI.

Let’s dive deeper into how that would look, when addressing the top three data privacy issues.

Privacy of user prompts

Safeguarding privacy of user prompts has become an increasingly critical concern in the world of AI.

An end user can initiate a connection with a LLM hosted within a decentralized privacy-prserving compute engine called a Trusted Execution Environment (TEE), which provides a public encryption key. The end user encrypts their AI prompts using that public key and sends the encrypted prompts to the secure LLM.

Within this privacy-preserving environment, the encrypted prompts undergo decryption using a key only known by the TEE. This specialized infrastructure is designed to uphold the confidentiality and integrity of user data throughout the computation process.

Subsequently, the decrypted prompts are fed into the LLM for processing. The LLM generates responses based on the decrypted prompts without ever revealing the original, unencrypted input to any party beyond the authorized entities. This ensures that sensitive information remains confidential and inaccessible to any unauthorized parties, including the infrastructure owner.

By employing such privacy-preserving measures, users can engage with AI systems confidently, knowing that their data remains protected and their privacy upheld throughout the interaction. This approach not only enhances trust between users and AI systems but also aligns with evolving regulatory frameworks aimed at safeguarding personal data.

Privacy of custom trained AI models

In a similar fashion, decentralized technology can be used to protect the privacy of custom-trained AI models that are leveraging proprietary data and sensitive information.

This starts with preparing and curating the training dataset in a manner that mitigates the risk of exposing sensitive information. Techniques such as data anonymization, differential privacy, and federated learning can be employed to anonymize or decentralize the data, thereby minimizing the potential for privacy breaches.

Next, an end user with a custom-trained Language Model (LLM) safeguards its privacy by encrypting the model before uploading it to a decentralized Trusted Execution Environment.

Once the encrypted custom-trained LLM is uploaded to the privacy-preserving compute engine, the infrastructure decrypts it using keys known only to TEE. This decryption process occurs within the secure confines of the compute engine, ensuring that the confidentiality of the model remains intact.

Throughout the training process, the privacy-preserving compute engine facilitates secure communication between the end user's infrastructure and any external parties involved in the training process, ensuring that sensitive data remains encrypted and confidential at all times. In a decentralized world, this data sharing infrastructure and communication will likely exist on a highly secure and fast protocol such as the Verida Network.

By adopting a privacy-preserving approach to model training, organizations can mitigate the risk of data breaches and unauthorized access while fostering trust among users and stakeholders. This commitment to privacy not only aligns with regulatory requirements but also reflects a dedication to ethical AI practices in an increasingly data-centric landscape.

Private data to train AI

AI models are only as good as the data they have access to. The vast majority of data is generated on behalf of, or by, individuals. This data is immensely valuable for training AI models, but must be protected at all costs due to its sensitivity.

End users can safeguard their private information by encrypting it into private training datasets before submission to a LLM training program. This process ensures that the underlying data remains confidential throughout the training phase.

Operating within a privacy-preserving compute engine, the LLM training program decrypts the encrypted training data for model training purposes while upholding the integrity and confidentiality of the original data. This approach mirrors the principles applied in safeguarding user prompts, wherein the privacy-preserving computation facilitates secure decryption and utilization of the data without exposing its contents to unauthorized parties.

By leveraging encrypted training data, organizations and individuals can harness the power of AI model training while mitigating the risks associated with data exposure. This approach enables the development of AI models tailored to specific use cases, such as utilizing personal health data to train LLMs for healthcare research applications or crafting hyper-personalized LLMs for individual use cases, such as digital AI assistants.

Following the completion of training, the resulting LLM holds valuable insights and capabilities derived from the encrypted training data, yet the original data remains confidential and undisclosed. This ensures that sensitive information remains protected, even as the AI model becomes operational and begins to deliver value.

To further bolster privacy and control over the trained LLM, organizations and individuals can leverage platforms like the Verida Network. Here, the trained model can be securely stored, initially under the private control of the end user who created it. Utilizing Verida's permission tools, users retain the ability to manage access to the LLM, granting permissions to other users as desired. Additionally, users may choose to monetize access to their trained models by charging others with crypto tokens for accessing and utilizing the model's capabilities.

Potential use cases are only restricted by your imagination. What if…

• Internet hotspots could be established in rural areas where there is little coverage? 

• Homeowners could be rewarded by selling excess solar energy back to the grid?

• Consumers could share unused storage space on their devices with others?

• Entrepreneurs could unlock peer-to-peer microloans to build local projects?

Underpinned by blockchain technology, DePINs make all of this possible — at a time when the infrastructure powering the global economy is experiencing seismic change. Figures from Statista suggest 33.8% of the world's population don't use the internet, with people in low-income countries most likely to be shut out of the modern information society. The International Energy Agency estimates that 100 million households will depend on rooftop solar panels by 2030, and enhancing economic incentives will be a crucial catalyst for adoption. And let's not forget that the rise of artificial intelligence means the need for storage and computation is booming, with McKinsey projecting demand for data centers will rise 10% a year between now and the end of the decade. DePINs have the power to cultivate a cloud storage network that's much cheaper than traditional players including Google and Amazon.

DePINs mount a competitive challenge to the centralized providers who dominate the business landscape. Right now, most of the infrastructure we use every day is controlled by huge companies or governments. This creates a real risk of monopolies where a lack of choice pushes up prices for consumers and businesses — with the pursuit of profits stymying innovation and shutting out customers based on geography and income.

Blockchains are at the beating heart of these decentralized networks. That's because individuals and businesses who contribute physical infrastructure can be rewarded in crypto tokens that are automatically paid out through smart contracts. Consumers can also use digital assets to unlock services on demand.

This approach isn't about modernizing access to infrastructure, but changing how it is managed, accessed and owned. Unlike centralized providers, the crypto tokens issued through DePINs incentivize all participants to get involved. Decentralized autonomous organizations (known as DAOs for short) play a vital role in establishing the framework for how these projects are managed. Digital assets can be used to vote on proposals ranging from planned network upgrades to where resources should be allocated. Whereas big businesses are motivated by profit, community-driven projects can focus on meeting the needs of underserved areas. The issuance of tokens can also provide the funding required to build infrastructure — and acquire the land, equipment and technical expertise needed to get an idea off the ground.

Web3 has been driven by a belief that internet users should have full control over their data, and tech giants should be stopped from monetizing personal information while giving nothing in return. DePINs align well with these values, all while reducing barriers to entry and ensuring there's healthy competition. Multiple marketplaces for internet access, data storage and energy will result in much fairer prices for end users — and encourage rivals to innovate so they have compelling points of difference. It also means an entrepreneur with a deep understanding of what their community needs can start a business without large capital requirements. Open access and interoperability are the future.

Certain challenges must be overcome for DePINs to have a lasting global impact. There's no denying that multibillion-dollar corporations currently benefit from economies of scale, vast user bases, and deep pockets. That's why it's incumbent on decentralized innovations to show why their approach is better. Reaching out to untapped markets that aren't being served by business behemoths is a good first step. Another obstacle standing in the way of adoption concerns regulatory uncertainty, which can prevent investors and participants from getting involved. Careful thought also needs to be paid to the ramifications that DePINs can have on data privacy. Unless safeguards are imposed, someone who accesses an internet hotspot through blockchain technology could inadvertently disclose their particular location.

Ecosystems have been created that allow DePINs to be established while ensuring that user privacy is preserved at all times — championing data ownership and self-sovereignty. As well as reducing the risks surrounding identity theft, they have been built with the evolving nature of global regulation in mind — with measures such as GDPR in the EU forcing companies to rethink how much data they hold on their customers.

Zooming in on Europe as a use case, and how these regulatory headwinds will affect more than 400 million citizens on the continent, gives an invaluable insight into how DePINs — and the infrastructure they're built on — can have an impact in the years to come.

For one, the current internet landscape means that we need to create a new digital identity every time we want to join a website or app — manually handing over personal information by filling out lengthy forms to open accounts. Users are then confronted by lengthy terms and conditions or privacy notices that often go unread, leaving people in the dark about how their data is going to be used in the future. That's why the EU has proposed singular digital identities that could be used for multiple services — from "paying taxes to renting bicycles" — and change the dynamic about how confidential information is shared. This approach would mean that consumers are in the driving seat, and decide which counterparties have the right to learn more about who they are.

The European Union's approach is ambitious and requires infrastructure that is fast, inexpensive and interoperable — allowing digital signatures, identity checks and credentials to be stored and executed securely across the trading bloc. Another element that must be thrown into the mix is central bank digital currencies, with the European Central Bank spearheading efforts to create an electronic form of the euro that is free to use and privacy preserving — all while enabling instant cross-border transactions with businesses, other consumers and governments.

High-performing and low-cost infrastructure will be essential if decentralized assets are going to be used by consumers across the continent — not to mention regulatory compliance. Privacy-focused wallets need to support multiple blockchains — as well as decentralized identities, verifiable credentials and data storage. A simple, user-friendly mobile application will be instrumental in guaranteeing that DePINs gain momentum.

The future is bright, and we're yet to scratch the surface when it comes to the advantages decentralization can bring for all of us. But usability and efficiency are two key pillars that must be prioritized if this new wave of innovation is to match the unparalleled impact of the internet.

This post was written by me, but originally published on DailyHodl.com

AI (artificial intelligence) has caused frenzied excitement among consumers and businesses alike – driven by a passionate belief that LLMs (large language models) and tools like ChatGPT will transform the way we study, work and live.

But just like in the internet’s early days, users are jumping in without considering how their personal data is used – and the impact this could have on their privacy.

There have already been countless examples of data breaches within the AI space. In March 2023, OpenAI temporarily took ChatGPT offline after a ‘significant’ error meant users were able to see the conversation histories of strangers.

That same bug meant the payment information of subscribers – including names, email addresses and partial credit card numbers – were also in the public domain.

In September 2023, a staggering 38 terabytes of Microsoft data was inadvertently leaked by an employee, with cybersecurity experts warning this could have allowed attackers to infiltrate AI models with malicious code.

Researchers have also been able to manipulate AI systems into disclosing confidential records.

In just a few hours, a group called Robust Intelligence was able to solicit personally identifiable information from Nvidia software and bypass safeguards designed to prevent the system from discussing certain topics.

Lessons were learned in all of these scenarios, but each breach powerfully illustrates the challenges that need to be overcome for AI to become a reliable and trusted force in our lives.

Gemini, Google’s chatbot, even admits that all conversations are processed by human reviewers – underlining the lack of transparency in its system.

“Don’t enter anything that you wouldn’t want to be reviewed or used,” says an alert to users warns.

AI is rapidly moving beyond a tool that students use for their homework or tourists rely on for recommendations during a trip to Rome.

It’s increasingly being depended on for sensitive discussions – and fed everything from medical questions to our work schedules.

Because of this, it’s important to take a step back and reflect on the top three data privacy issues facing AI today, and why they matter to all of us.

1. Prompts aren’t private

Tools like ChatGPT memorize past conversations in order to refer back to them later. While this can improve the user experience and help train LLMs, it comes with risk.

If a system is successfully hacked, there’s a real danger of prompts being exposed in a public forum.

Potentially embarrassing details from a user’s history could be leaked, as well as commercially sensitive information when AI is being deployed for work purposes.

As we’ve seen from Google, all submissions can also end up being scrutinized by its development team.

Samsung took action on this in May 2023 when it banned employees from using generative AI tools altogether. That came after an employee uploaded confidential source code to ChatGPT.

The tech giant was concerned that this information would be difficult to retrieve and delete, meaning IP (intellectual property) could end up being distributed to the public at large.

Apple, Verizon and JPMorgan have taken similar action, with reports suggesting Amazon launched a crackdown after responses from ChatGPT bore similarities to its own internal data.

As you can see, the concerns extend beyond what would happen if there’s a data breach but to the prospect that information entered into AI systems could be repurposed and distributed to a wider audience.

Companies like OpenAI are already facing multiple lawsuits amid allegations that their chatbots were trained using copyrighted material.

2. Custom AI models trained by organizations aren’t private

This brings us neatly to our next point – while individuals and corporations can establish their custom LLM models based on their own data sources, they won’t be fully private if they exist within the confines of a platform like ChatGPT.

There’s ultimately no way of knowing whether inputs are being used to train these massive systems – or whether personal information could end up being used in future models.

Like a jigsaw, data points from multiple sources can be brought together to form a comprehensive and worryingly detailed insight into someone’s identity and background.

Major platforms may also fail to offer detailed explanations of how this data is stored and processed, with an inability to opt out of features that a user is uncomfortable with.

Beyond responding to a user’s prompts, AI systems increasingly have the ability to read between the lines and deduce everything from a person’s location to their personality.

In the event of a data breach, dire consequences are possible. Incredibly sophisticated phishing attacks could be orchestrated – and users targeted with information they had confidentially fed into an AI system.

Other potential scenarios include this data being used to assume someone’s identity, whether that’s through applications to open bank accounts or deepfake videos.

Consumers need to remain vigilant even if they don’t use AI themselves. AI is increasingly being used to power surveillance systems and enhance facial recognition technology in public places.

If such infrastructure isn’t established in a truly private environment, the civil liberties and privacy of countless citizens could be infringed without their knowledge.

3. Private data is used to train AI systems

There are concerns that major AI systems have gleaned their intelligence by poring over countless web pages.

Estimates suggest 300 billion words were used to train ChatGPT – that’s 570 gigabytes of data – with books and Wikipedia entries among the datasets.

Algorithms have also been known to depend on social media pages and online comments.

With some of these sources, you could argue that the owners of this information would have had a reasonable expectation of privacy.

But here’s the thing – many of the tools and apps we interact with every day are already heavily influenced by AI – and react to our behaviors.

The Face ID on your iPhone uses AI to track subtle changes in your appearance.

TikTok and Facebook’s AI-powered algorithms make content recommendations based on the clips and posts you’ve viewed in the past.

Voice assistants like Alexa and Siri depend heavily on machine learning, too.

A dizzying constellation of AI startups is out there, and each has a specific purpose. However, some are more transparent than others about how user data is gathered, stored and applied.

This is especially important as AI makes an impact in the field of healthcare – from medical imaging and diagnoses to record-keeping and pharmaceuticals.

Lessons need to be learned from the internet businesses caught up in privacy scandals over recent years.

Flo, a women’s health app, was accused by regulators of sharing intimate details about its users to the likes of Facebook and Google in the 2010s.

Where do we go from here?

AI is going to have an indelible impact on all of our lives in the years to come. LLMs are getting better with every passing day, and new use cases continue to emerge.

However, there’s a real risk that regulators will struggle to keep up as the industry moves at breakneck speed.

And that means consumers need to start securing their own data and monitoring how it is used.

Decentralization can play a vital role here and prevent large volumes of data from falling into the hands of major platforms.

DePINs (decentralized physical infrastructure networks) have the potential to ensure everyday users experience the full benefits of AI without their privacy being compromised.

Not only can encrypted prompts deliver far more personalized outcomes, but privacy-preserving LLMs would ensure users have full control of their data at all times – and protection against it being misused.

In Web2, signing into applications often involves the exchange of personal data, creating potential security and privacy challenges. Each application creates new risks to the security and management of your personal information.

With the advent of Web3, a paradigm shift is on the horizon. There is a future where signing into an application doesn't entail exposing your data to developers or application owners. Instead, the application operates within the user's browser or mobile device.

As a result, user data remains securely within the application and is never shared with the developer. This opens the door to a seamless and secure digital experience, potentially eliminating the need for explicit consent for every piece of data shared.

In this decentralized future, we unlock the possibility of a zero-click login or onboarding process. Users could employ a Web3 wallet to instantly personalize or onboard to any website or application.

There would be security measures in place, ensuring automatic interactions occur only with verified and trusted applications listed on a blockchain-based trust registry.

Imagine visiting an online store where this is implemented. A plugin could automatically connect to your private data wallet, rebuilding the entire shopping website based on your preferences and past interactions.

Crucially, this personalization happens locally in your browser, without sharing any sensitive data with Shopify or the store owner.

This is part of our vision at Verida. More than just enabling web3 login or onboarding, we envision a future where interactions with apps and websites are seamlessly personalized.

This decentralized approach ensures that data is utilized on the user's computer, eliminating the risk of data leakage and making automatic consent a straightforward and secure process.

The days of compromising personal data in the name of convenience will soon be replaced by a decentralized, user-controlled future that replaces the centralized control of web2.

Verida DbStore is the first “self-sovereign” database infrastructure for Web3, which promises to revolutionize how data is managed by offering users guaranteed ownership, the speed and performance of traditional databases, and the ability to permanently delete their data. As a new decentralized infrastructure and architecture, Verida DbStore is specifically designed for rapid access to highly changing, structured personal data with encryption as a fundamental aspect of the protocol.

Here’s an explainer video that dives deep into the differences.

The full article is available here.

You can learn more with the official Verida announcement.

I often talk to crypto natives about “web3” and quickly realize we are talking about rather different things. What follows below is my perspective as a web3 builder with the usual caveat that there is no right or wrong definition of these things and they will evolve over time.

There is significant prior art here, so I’d like to acknowledge Gavin Wood’s original blog post defining Web 3.0 and Jesse Waldon’s post on “crypto” v “web3” that talks to some of the tribalism behind these words.

Crypto: Own your Assets

At the risk of oversimplification, the objective of “crypto” is for an individual to own their assets. This can be enabled by holding tokens or NFTs which can be exchanged through decentralized exchanges or marketplaces.

This can be broken down as follows:

Infrastructure

1. Key management (Seed phrase, private key, social recovery)

2. Protocol networks (Bitcoin, Ethereum, NEAR etc.)

3. Protocol tokens (BTC, ETH, NEAR etc.)

4. Standards (ERC-20 Token standard, ERC-721 NFTs etc.)

5. Crypto wallets (Metamask, Rainbow wallet, Verida wallet)

Apps

1. DEX (Uniswap, Pancake Swap, Balancer)

2. DeFi apps (Synthetix, GMX)

3. NFT marketplaces (Blur, x2y2, Paras)

4. Project tokens (Decentraland, Bankless, Sandbox)

Web3: Own Everything

The intent of web3 is for an individual to own every part of their digital life.

Own your identity. Own your data. Own your assets. Everything is encrypted. Everything is verifiable. Everything is controlled by you.

This can be broken down as follows:

All of “Crypto”

Web3 encompasses all the infrastructure and apps of crypto.

Infrastructure

1. Identity (DIDs)

2. Auth (Sign in with Ethereum, WalletConnect, Verida SSO)

3. Data storage (Textile, Ceramic, Verida DbStore)

4. Messaging (EPNS, WalletConnect Chat, nostr, Verida Messaging)

5. Web3 wallets (Onto, Verida Wallet)

Apps

1. Social (Farcaster, Damus, Gm.xyz, Verida.one)

2. Identity / Credentials (Gitcoin Passport, Disco.xyz, Galxe, Keloverse)

3. Chat (Session, status.im)

4. Content (mirror.xyz)

Why is the distinction important?

Web3 has the potential to disrupt every single industry, not just finance. It is the key to unlocking mass adoption of decentralized technology beyond the tech savvy.

The economic model, consensus model and underlying technologies are different for each part of the web3 stack. Developers, infrastructure providers and investors need to understand these differences and not apply pre-existing “crypto” thinking to “web3”.

For example, there are significant differences between L1 and L2 blockchains; different consensus models, different economic models, different objectives. Similarly in Web3 there are differences between public and private data storage protocols; different performance criteria, different security threats etc.

The distinction is important, however it doesn’t really matter what it is called. It is important we can have a shared language to efficiently communicate ideas and evolve our collective thinking.

The challenges ahead

The crypto audience is a small subset of the wider population that is more tech savvy and will do the work to get around poor user experiences. Web3 aims to cross over to mainstream adoption. This requires closing the gap between the current (poor) crypto user experiences, to something anyone with a mobile device and web browser can easily use to access the full web3 technology stack.

A significant user experience gap exists across the current crypto infrastructure stack, whereas the Web3 infrastructure stack is earlier in its development cycle. It has even more ground to make up.

For example, we require better user experiences for login that aligns more closely with web2 expectations. Users expect fast and responsive apps that are limited today by blockchain speed and data storage speed. These issues need to be addressed (and will be) on the road to mass adoption of web3.

The opportunity ahead

Where there are challenges, there are opportunities.

We are early. The introduction of decentralized technology has the potential to disrupt every industry, every governance structure and break the monopolistic control of existing incumbents.

The next generation of infrastructure and applications are in their nascent stages right now. Due to the community oriented nature of crypto and web3, everyone has an opportunity to participate regardless of their experience or skills.

Find a problem where you can add value and jump in!

Follow me on substack

Here’s a quick demo of a collaboration I helped pull together with funDAOmental and Verida.

It showcases an early build of Hyperbox, a collaborative metaverse project leveraging the Verida network to access decentralized data storage, messaging, identity and profiles… All powered by Web3.

The vast majority of “Web3” applications provide the perception of decentralization by asking you to login with a blockchain address, but in reality they are centralized behind the scenes. These applications don’t enforce end-to-end encryption of user data or guarantee data is stored on decentralized infrastructure.

As a result, in many instances users do not own or control their application data.

We are swimming in a sea of “Mullet Web3”. Decentralized at the front, but centralized at the back.

What is a Decentralized Identity?

A decentralized identity is a concept which can be multiple things depending on the context. At a basic level a decentralized identity can be created by anyone, is anonymous by default and contains a secret (ie: private key) that can be used to prove ownership of the identity. This enables cryptographically trusted relationships and communication, owned and controlled by the holder.

Decentralized identifiers (DIDs) are similar to usernames in Web3, but with extra features. They are the basis for sharing public keys controlled by the DID holder, creating trusted connections, storing data and many other capabilities.

Here is an example DID using the “Ethereum” DID Method: did:ethr:0x690b9a9e9aa1c9db991c7721a92d351db4fac990

DIDs play a critical role in Web3 ecosystems, which don’t have a centralized authority playing the role of gatekeeper. They enable multiple decentralized identities to establish trusted communication channels, share information and build composable services.

Given a DID, it’s possible to use a software library to lookup an associated DID Document (JSON) that provides lots of extra metadata. This document can define an unlimited number of public keys for different use cases, it supports key rotation and supports listing API’s or service endpoints where you can interact with the identity.

A common use case is for a DID Document to point to a location of an encrypted personal data store where user data is stored; owned and controlled by the user. This is an essential requirement for us to reach the promised land of “owning your own data”.

There is a working group that has established the DID-Core standard under the stewardship of W3C. This allows protocols to define a “DID method” that provides different ways to construct DID identifiers and documents. This allows a software library that can take the identifier and resolve the DID Document. There is a range of working groups supporting discovery related specifications at the DIF.

This DID standard is the leading technology being used by emerging Web3 protocols like the Ceramic Network, Web5, At Protocol by Bluesky and Verida.

Blockchain addresses as DIDs

The emergence of blockchain has pushed forward the technology and broader awareness of public / private key pairs being used as decentralized identifiers. The identifier is a blockchain address and the private key remains a secret kept by the owner.

At first glance, this seems really awesome. Not only do we have a decentralized identity, we also have a key pair allowing us to sign messages or data to create trusted, secure protocols.

Metamask and other crypto wallets have brought this technology to a large user base. (Yes, PGP enabled this a long time ago, but the timing and tooling wasn’t right).

The DID-Core standard provides a very specific way to use a blockchain address as a feature rich decentralized identity with the help of a DID Document. This provides security via key rotation, allows for standardization of data storage and accessing services relating to the user.

However, the vast majority of Web3 projects are simply asking users to sign a message using MetaMask to prove they control a blockchain address rather than using the DID-Core standard.

This gives the perception to a user that they are using a decentralized service, however the user is just logging into a centralized service that stores their data — just like a Web2 application.

This is not a decentralized application!

Sign-in with Ethereum makes things worse!

This concept of signing a message with Metamask to login has been taken even further with the introduction of the “Sign-in with Ethereum” (SIWE) standard.

SIWE requires a user to sign a message with a timestamp and nonce proving they currently control the secret (private key) for an account. This is equivalent to signing in with a username and password to a centralized system.

In fact, that is the underlying purpose of SIWE. To enable a blockchain address to sign into Web2 applications:

Here we hit a major issue.

While this “sign-in” process works well, the architecture is just a front to a centralized system for storing data and interacting with the application. SIWE does not mean your Web3 application data is decentralized. It does not mean you have ownership / control over your data, nor that it is being encrypted using your blockchain keys.

In fact, the design of SIWE makes it impossible to support end-to-end encryption of user data using your blockchain private key.

The application must then store a cookie or a session on a server to maintain information about you as a “logged in” user.

We have the Web3 mullet. It looks like decentralization at the front, but it’s centralized at the back!

SIWE also introduces numerous other issues:

1. Using a public blockchain address as the identifier is a security and privacy risk.

2. A user’s public blockchain assets and activity is now linked to their private Web3 application activity.

3. A user is locked into using a particular blockchain network and private key.

The concept of a DID Document in the DID-Core standard is designed to solve all these issues (and many more).

However… DID-Core implementations also have problems!

The DID-Core standard is not perfect, but it’s a pretty damn good improvement on the current way we handle identities.

The standard introduces the concept of DID Documents that must be publicly discoverable and securely stored somewhere. Developers can define a “DID Method” that outlines different types of identifiers (ie: did:ethr or did:web ) and how the DID Document can be discovered. Each DID method typically has a software library that developers can use to “resolve” the DID Document for a given identifier.

Here’s our first problem. There are lots of DID Methods (see the full list here). No software will support all of those methods, it’s just not feasible. In fact Google and Mozilla objected to the DID-Core specification on this basis, but was overruled by the W3C.

Over time, we will see a necessary consolidation of these DID methods into the ones with the best technical characteristics, flexibility, community and adoption…. but for now it’s a bit of a mess.

Let’s look deeper at the technical requirements that must be considered when implementing a DID Method. It’s critical that DID Documents have the following properties:

• Access; Documents must be public to discover and read, but it must be enforced that only the DID controller (user with the secret) can change the document (ie: rotate their keys)

• Performant; It must be fast to read and write (seconds), otherwise there will be unacceptable delays when creating a new account or signing into Web3 applications.

• Cost; Web3 is competing with Web2. The cost must be very low (ideally free), without the user becoming beholden to a centralized entity paying on their behalf. If the user has to pay, that introduces a huge barrier to entry that makes it infeasible.

• Revocable; A user must be able to delete their DID document in accordance with the “right to be deleted”. This is a critical requirement that is missed by the vast majority of DID method implementations.

• Full support; The implementation must support the full suite of DID-Core specifications for maximum flexibility and security.

Bluesky’s AT Protocol has a great summary of their criteria around selecting a DID method:

AT Protocol on DID Methods:

At present, none of the DID methods meet our standards fully.

The current leading DID methods fail on both my high level criteria and that of the AT Protocol on many levels. They are not suitable for widespread mass adoption.

However, let’s take a closer look at the leading contenders to better understand the issues.

DID: Ethereum

TLDR; Expensive, slow, only a partial DID-Core implementation, Non-revocable documents

The ethr-did-registry runs on Ethereum. This makes it very expensive and slow. Blockchains are not designed to store data, so storing a whole DID Document is not feasible at scale.

The current implementation tries its best to be efficient with gas fees, but this results in many compromises. As such, it only supports a subset of the DID-Core standard. This makes it a lot less useful than it appears at first glance.

DID: ION

TLDR; Complex, Requires it’s own layer 2 network, Encourages centralization of infrastructure, Slow to anchor, Non-revocable documents

ION (based on the sidetree specification, supported by Microsoft and favoured by the team behind Web5) stores DID Documents on IPFS nodes and anchors proofs to the Bitcoin blockchain. This seems like a sensible decentralized architecture, but creates a lot of complexity and introduces other interesting issues.

The ION infrastructure requires a network of node operators willing to run infrastructure. At the moment that is voluntary from a small group of organizations with a vested interest in the network continuing to operate, with no economic incentive model.

ION requires node operators to pay Bitcoin transaction fees to anchor DID Document changes:

This places an economic cost on node operators to pay for transactions, rather than empowering an individual to pay for their own. Web3 developers must pay to run their own node or pay others to use their nodes. This creates a delegation of trust which increases centralization and other third party risks across the network.

ION requires locking Bitcoin:

ION is dependent on the slow pace of Bitcoin for it’s anchoring service:

This means proof commits of new DID Document changes take ~20 minutes before they are anchored.

DID: 3ID (Ceramic)

TLDR; Similar to ION without the blockchain, Requires it’s own layer 2 network, Non-revocable documents, Limited DID standard support

3ID DID method is implemented on the Ceramic network which is a stream based mutable storage network that leverages IPFS. As such, it inherits the limitations of IPFS such as the inability to support revocable documents.

The DID method generates a DID document from an object containing multiple public keys. As a result, there is no support for service endpoints or fine grained control over the rest of the DID document, severely limiting its usefulness in a composable Web3 ecosystem.

The DID method is also tightly coupled with the Ceramic network itself, making it challenging for an implementer to use the DID method in projects not using Ceramic.

DID: Cheqd

Cheqd DID method is an honourable mention. Running on top of the Cosmos blockchain and with Hyperledger Indy origins it is a well thought out DID method implementation.

The DID document is stored on chain, however the blockchain key pairs are separated from the identity payloads providing increased privacy and separation between off-chain DIDs and on-chain keypairs.

Cheqd have a well thought through decentralized overnance framework, one of the only on this list.

They also provide infrastructure for other identity related metadata (schemas, assets etc.) and have a privacy preserving payment model for credential verification on their roadmap. Such payment rails will be necessary for creating viable credential business models at scale.

It’s refreshing to see Cheqd have clear pricing available in their documentation, however at current pricing the cost of creating a DID is around $2.00. That being said, Cheqd use cases are more focused on feature rich identity and credentialing where organizations will be creating DIDs more so than individuals, so that price point is not unreasonable.

In a world where there are likely to be multiple DID methods, Cheqd provides a solid option for enterprise use cases.

DID: Web

TLDR; Simple, Cheap, Fast, Fragile.

The Web DID method (currently used by AT Protocol) is simple to implement as it can point to a URL that can be managed by a centralized entity. For example: did:web:acme.com:user:alice is a valid identifier.

On the surface this seems great, however it’s not suitable long term. If the third party website hosting your DID Document goes down, suddenly you have lost your identity! This could be as a result of a temporary outage, the hosting service shutting down or a DNS registrar taking down a domain name. As your DID identifier is hardcoded to that address, there is no way to recover your identity.

The path to true decentralization

There are a variety of other blockchain based DID methods, but they all suffer from some combination of high cost, low speed or limitations to functionality.

For true decentralization of Web3 applications we require three key things:

1. A DID method that meets the necessary standards for widespread adoption

2. Applications to start using a suitable DID method instead of “faking” it with blockchain based signatures

3. Enable applications to be decentralized in the back by leveraging user encrypted data storage and other decentralized services linked to a DID document

It’s hard to blame app developers as they are focused on building products and are currently constrained by the lack of a suitable DID method. This technology is new, so it’s understandable there are trade-offs made on the path to true decentralization.

It’s time to trim the mullet! We must no longer compromise on identity. It’s incredibly difficult to backtrack on identity infrastructure once deployed. Compromises made today will only compound as Web3 adoption grows.

We need a suitable DID method as soon as possible to enable application developers to use fully featured decentralized identity solutions and unlock the ability for fully decentralized end-to-end encrypted Web3 applications.