The genesis of Layr8

Our adventure begins in November 2021 in Chicago. Pace had invited a group of friends and colleagues to gather to discuss the idea of starting a company that would leverage the decentralized web, known as Web3, to dramatically improve many of the shortcomings of API integrations and centralized hub-and-spoke software as a service (SaaS) models. We enjoyed two days of incredible conversation and made some lasting connections, but perhaps emboldened by our decades of experience and the trust we’d built over the past 15 years, it was only Pace and I that decided to team up on what started as a side-gig to dramatically improve the world of API integrations. Fast-forward to today. We are the cofounders of Protocol Technologies and the creators of Layr8, a technology that offers a compelling approach to connecting software systems within and between organizations. We believe Layr8 will help pave the way to an ecosystem of companies and technologies that form the 8th layer of the internet — the identity layer.

In this post, I recall some of our journey and how we arrived at identity as the foundational concept that will revolutionize how companies integrate and people interact, and how identity will power the coming internet of AI agents and things.

The problem

The lack of identity on the internet might be the biggest problem, but I’m getting ahead of myself. The problem we set out to solve is that using REST APIs to communicate and coordinate with partners involves integrations that are costly to build and maintain and they require you to trust a 3rd party with the custody of your valuable data. These integrations tend to resemble a hub-and-spoke pattern where hubs, or SaaS providers, sit at the centre and facilitate communication and workflow between people and companies. This is the model used by Facebook and Twitter. It’s the model that Zapier helps to simplify. And… it’s a model that works, but it has its shortcomings.

The result of having centralized hubs that aggregate identities (Facebook profiles, Gmail addresses, API keys) and data, personal and corporate, is that they become fixated on the value of owning and monetizing these identities which compels them to become walled gardens, reluctant to share or integrate with competing hubs. Wouldn’t it be nice if you could post your pictures to Facebook, Instagram, and Google Photos from a single interface? This same problem plagues the corporate world causing one company’s system not to talk to the competing system chosen by their partner. This problem is “solved” today by integrating company’s systems with each other, and this is typically done using REST APIs.

The amassing of users (another word for identities) is also very lucrative, and in many cases, companies will endlessly seek ways to monetize your data and identities. In some cases, this is a win-win. You get free email, Google makes money selling ads. We understand this. However, in the business world, this often doesn’t fly, but we still see cases where organizations running centralized platforms make attempts to aggregate, analyze, and repackage data to increase revenue in creative ways.

Another subtler problem is that running a hub can be very lucrative and can tip the power scales in the favour of the company running it. This means many companies would rather try to be the hub than bend the knee to a competitor who already runs one. This incentive structure seems to lead markets to have either a single winner-takes-all hub or a highly fractured set of hubs requiring companies to integrate with multiple hubs in order to connect with partners. Add to this the fact that each hub requires a separate account (an identity) to be managed along with API keys to keep secret. Each hub’s API is also unique requiring ramp-up time for development teams who have to build logical mappings to make them work with existing systems. If that’s not enough, the APIs often change without warning.

This problem persists, in part, because there are no straightforward alternatives.

One naive alternative to the hub-and-spoke model might be point-to-point REST API integrations. This has the advantage of removing dependence on hubs, reducing risk of inappropriate access to private data, exposure to data breaches, and down-time risk. However, this is obviously more costly to the point of being untenable, with each party needing to integrate with every other party.

Web3 and the blockchain era

Initially, we had decided to focus on blockchain-based solutions. Web3 was enjoying a great deal of publicity and seemed to be the obvious solution. It seemed to tick all of the boxes. It was decentralized. It was able to build consensus, enforce rules, and share information between parties without having a single central hub. It offered compelling security guarantees backed by cryptography. Smart contracts meant we could even support custom business logic.

Web3 seemed to be the solution. The idea of running smart contracts on a global computer backed by a public ledger that forever maintained a tamper-proof copy of the recorded truth seemed like exactly what we needed. We could connect companies by connecting each to the blockchain, a single integration to replace many, then share data securely by encrypting it and broadcasting it for authorized parties to receive, and even validate the data and interactions using smart contracts to encode agreements.

Starting in early 2022, I entered deep research mode, focused on understanding the Web3 landscape, learning to program in Rust and Solidity, experimenting with novel cryptographic algorithms for securely archiving and sharing data. I was looking for ways to leverage the elements of Web3 that were emerging: smart contracts, token-based economies, and IPFS. I even experimented with building our own blockchain on Polkadot (a blockchain network of networks).

For the first half of 2022, I was juggling this research with my full-time position as VP of Programming at Yardi Systems and needed to make the decision to stay at Yardi and continue to build out the IoT platform I created along with the incredibly talented teams in Saskatoon, Santa Barbara, Boston, and Vancouver, or move on and put all of my focus on Protocol Tech? This felt like an opportunity for me to build a company from the ground up and an opportunity to make a significant and positive contribution. It was a very difficult decision, but one that I don’t regret. Yardi is an incredible company and I hope to share more in future posts.

I resigned my position, and Pace and I formed Protocol Technologies, Inc. in June of 2022. With increased time and focus, I continued to work on solving this problem, still not knowing how exactly to solve it, but Web3 was my starting point.

I was armed with the question, “How do I create a system that would allow multiple parties to interact with each other securely, where the data must be confidential and tamper resistant, all without a central hub, and in such a way that new parties could join with a single integration rather than needing to integrate with every hub in a market?” Simply put, I needed to figure out how to transition B2B integrations from a hub-and-spoke model to a peer-to-peer model.

I continued to research blockchain-based solutions for another 6 months or so, digging deeper into Polkadot, tokenomics, and NuCypher’s Umbral Proxy Re-Encryption scheme. I focused first on confidential multi-party data sharing. We knew we needed this solution to work in the logistics space as a way for companies to create, share, and update e-tickets. However, ultimately, and with great reluctance, I arrived at the difficult decision to step back from Web3 and to move away from a blockchain-based approach for a few reasons.

Why did we abandon Web3?

1. Paying for transactions using tokens is confusing for the layperson and the infrastructure (think Stripe and PayPal) to make this easy is non-existent. It would have required a lot of work to make the user experience around paying for space in a blockchain frictionless.

2. Many blockchains were too expensive for data-intensive transactions to be practical.

3. The latency between transaction submission and its delivery to receiving parties was too slow, although a few blockchains were working on solutions to address this.

Some of these problems have been solved, and it’s possible that all will be addressed in time. However, one problem stood out as the show-stopper. Despite planning for end-to-end encryption of the data, a must-have, using a public blockchain as a message bus for sharing private data is a really bad idea. Even if the data is end-to-end encrypted, once posted to a blockchain, it remains there, indefinitely, forever at risk of being decrypted if ever the secret key is compromised. EVER! This meant that a key leaked 20 years from now could, potentially unlock valuable secrets shared privately today. This was just too large an attack surface for us to accept.

Identity era

Abandoning Web3 was disheartening, to say the least, but we pressed on, and by spring of 2023, I discovered Decentralized Identifiers (DID), a W3C standard for implementing Self-Sovereign Identity (SSI). It wasn’t immediately obvious how this could be used, and I don’t recall how I stumbled into it. However, there was something compelling about it, and in time, it slowly became clear to me that using identity as the foundation could be the unlock we were looking for. The emerging standards clearly provided the ability to use cryptography to perform authentication so parties could be assured of who they were communicating with. It provides for flexible application of encryption to keep information private, and proof signing, to resist tampering.

In many ways, I think of DID as having all the elements of blockchain, without consensus. Considering that nothing stops us from using blockchains alongside DIDs means that we can be very strategic about when to use blockchains and when to avoid. There are things that require decentralized consensus, but many problems can be solved without it.

With this arsenal of tools, I felt sure we could build a peer-to-peer network that would enable companies to communicate directly with one another, securely, without a hub and without requiring each to build an untenable number of pair-wise integrations.

I began to implement a proof-of-concept for what seemed to me the right approach to solving this problem of multi-party secure messaging with the following requirements in mind:

• decentralized: no centralized platform, or account information

• peer-to-peer: parties would communicate directly, not through a hub

• privacy-enabled: end-to-end encryption of all communication

• secure: in addition to encryption, parties had to authenticate (AuthN) and be authorized (AuthZ)

• Although API keys make sense within an organization, there should be no requirement to share API keys between partners.

As I began to work on this proof-of-concept (in TypeScript, by the way, something for a future post), I started to think about how to communicate about it and what it should be called. It was early one morning in March of 2023 on a flight to Montreal where Pace and I had planned to meet that the conceptual model and name crystallized for me.

REST APIs and the internet in general centre around hosts and IP addresses, while DIDs centre around identities. The magic of the internet is in its ability to enable programmers to communicate between hosts without being mentally burdened by the complexities involved in getting the data from laptop, over wifi, to router, over fibre, to ISP, and satellite and on and on all the way to the destination and back.

DID seemed to unlock the same thing at a higher level. Rather than providing an address for each host on the internet, however, it provides the thing that the internet is missing - identity. It provides a way for every identifiable person, company, organization, team, city, street, building, device, car, and whatever else you can think of to have their own identity on the internet, and a way for them to communicate directly, and securely.

The name Layr8 is an adapted spelling of Layer 8 (yes, because after you find a good name you still have to find a good domain name). Why Layer 8? The existing internet is the realization of the 7-layer OSI model and, in my mind, what we are building is the 8th layer of the internet, the identity layer. Layr8 unlocks the ability for an identity to communicate directly with any other identity in the same way that hosts do.

The end of the beginning

Having a name and a conceptual model had a catalyzing effect on our thinking and by June of 2023 I had completed a working prototype. We held a summit in Victoria, BC, Canada and invited a few of our closest friends and smartest colleagues to join us to listen to our unveiling presentation of Layr8, about the problems it solves, and to see a working demonstration. We were looking for feedback and the feedback was positive.

I believe Layr8 and decentralized identity will play a significant role in revolutionizing digital communication for business to business (B2B), person to person (P2P), AI agent to agent (A2A), vehicle to vehicle (V2V), vehicle to everything (V2X), and internet of things (IoT).

Join me in future posts where I discuss the transition from JavaScript/TypeScript proof of concept to Elixir for the enterprise-grade production implementation and the journey from June 2023 to the end of 2024 where I spent most of my time deeply immersed in writing the core of Layr8. I’ll talk about decisions that were made, provide a look at some of the code, and talk about problems that have yet to be solved. I’ll talk more about identity too, what it is, and why we believe it is the key to unlocking multi-party communication.