I've been dark for a few weeks. Things have been busy. I'm retiring from BYU (after 29 years, albeit with some interruptions) and starting a new job with Amazon Web Services (AWS). The job is in AWS Identity, and involves automated reasoning (formal methods). My Ph.D. dissertation was on using formal methods to verify the correctness of microprocessors. So the new job combines two things I've spent a good portion of my professional life working on. I'm loving it.
The name of what I and the larger group (Automated Reasoning Group) are doing is "provable security." AWS Provable Security automatically generates mathematical proofs to assert universal statements about the security properties of your AWS application. For example, Access Analyzer uses automated reasoning to analyze all public and cross-account access paths to your resources and provides comprehensive analysis of those paths, making statements like "None of your S3 buckets are publicly available."
To understand this better, and get a glimpse of where it could go, I recommend this talk from AWS re:inforce by Neha Rungta and Andrew Gacek.
When I was doing formal methods, we dreamed of the day when automated reasoning would handle real problems for people without access to highly trained Ph.D. researchers. Now, that's possible and available in 1-click, for many problems. I'm excited to be working on it.
I read about the Open Network for Digital Commerce (ONDC) on Azeem Azhar's Exponential View this week and then saw a discussion of it on the VRM mailing list. I usually take multiple hits on the same thing as a sign I ought to dig in a little more.
Open Network for Digital Commerce is a non-profit established by the Indian government to develop open ecommerce. The goal is to end platform monopolies in ecommerce using an open protocol called Beckn. I'd never heard of Beckn before. From the reaction on the VRM mailing list, not many there had either.
The README on the specifications indicates that buyers (identified as BAPs) address a search to a Beckn gateway of their choice. If the search doesn't specify a specific seller, then the gateway broadcasts the request to multiple sellers (labeled BPPs) whose catalogs match the context of the request. Beckn's protocol routes these requests to the sellers who they believe can meet the intent of the search. Beckn also includes specifications for ordering, fulfillment, and post-fulfillment activities like ratings, returns, and support.
ONDC's goal is to allow small merchants to compete with large platforms like Amazon, Google, and Flipkart. Merchants would use one of several ONDC-compatible clients to list their catalogs. When a buyer searches, products from their catalog would show up in search results. Small and medium merchants have long held the advantage in being close to the buyer, but lacked ways to easily get their product offerings in front of online shoppers. Platforms hold these merchants hostage because of their reach, but often lack local options. ONDC wants to level that playing field.
I am focused on serving the next 500 million customers. Therefore, I look forward to innovations, which will lift all the boats in the ecosystem.
At this stage, we are engaging very closely with the ONDC group, and we are quite committed to what the government is wanting to do, which is to digitize kiranas, local stores...I spoke about some of our initiatives, which are preceding even ONDC... So yes, excited by what it can do. It's a nascent industry, we will work closely with the government.
An open network for ecommerce would change how we shop online. There are adoption challenges. Not the least of which is getting small merchants to list what they have for sale and keep inventory up to date. Most small merchants don't have sophisticated software systems to interface for automatic updates—they'll do it by hand. If they don't see the sales, they'll not spend the time maintaining their catalog. Bringing the tens of millions of small merchants in India online will be a massive effort.
I'm fascinated by efforts like these. I spend most of my time right now writing about open networks for identity as I wrap up my forthcoming O'Reilly book. I'm not sure anyone really knows how to get them going, so it takes a lot of work with more misses than hits. But I remain optimistic that open networks will ultimately succeed. Don't ask me why. I'm not sure I can explain it.
When I got word that Craig Burton had died, the news wasn't unexpected. He'd been ill with brain cancer for a some time and we knew his time was limited. Craig is a great man, a good person, a valued advisor, and a fabulous friend. Craig's life is an amazing story of success, challenge, and overcoming.
I first met Craig when I was CIO for Utah and he was the storied co-founder of Novell and the Burton Group. Dave Politis calls Craig "one of Utah's tech industry Original Gangsters". I was a bit intimidated. Craig was starting a new venture with his longtime friend Art Navarez, and wanted to talk to me about it. That first meeting was where I came to appreciate his famous wit and sharp, insightful mind. Over time, our relationship grew and I came to rely him whenever I had a sticky problem to unravel. One of Craig's talents was throwing out the conventional thinking and starting over to reframe a problem in ways that made solutions tractable. That's what he'd done at Novell when he moved up the stack to avoid the tangle of competing network standards and create a market in network services.
When Steve Fulling and I started Kynetx in 2007 we knew we needed Craig as an advisor. He mentored us—sometimes gently and sometimes with a swift kick. He advised us. He dove into the technology and developed applications, even though he wasn't a developer. He introduced us to one of our most important investors, and now good friend, Roy Avondet. He was our biggest cheerleader and we were grateful for his friendship and help. Craig wasn't just an advisor. He was fully engaged.
One of Craig's favorite words was "ubiquity" and he lived his life consistent with that philosophy. Let me share three stories about Craig from the Kynetx days that I hope show a little bit of his personality:
Steve, Craig, and I had flown to Seattle to meet with Microsoft. Flying with Craig is always an adventure, but that's another story. We met with some people on Microsoft's identity team including Kim Cameron, Craig's longtime friend and Microsoft's Chief Identity Architect. During the meeting someone, a product manager, said something stupid and you could just see Craig come up in his chair. Kim, sitting in the corner, was trying not to laugh because he knew what was coming. Craig, very deliberately and logically, took the PM's argument apart. He wasn't mean; he was patient. But his logic cut like a knife. He could be direct. Craig always took charge of a room.
We hosted a developer conference at Kynetx called Impact. Naturally, Craig spoke. But Craig couldn't just give a standard presentation. He sat, in a big chair on the stage and "held forth". He even had his guitar with him and sang during the presentation. Craig loved music. The singing was all Craig. He couldn't just speak, he had to entertain and make people laugh and smile.
At Kynetx, we hosted Free Lunch Friday every week. We'd feed lunch to our team, developers using our product, and anyone else who wanted to come visit the office. We usually brought in something like Jimmy Johns, Costco pizza, or J Dawgs. Not Craig. He and Judith took over the entire break room (for the entire building), brought in portable burners, and cooked a multi-course meal. It was delicious and completely over the top. I can see him with his floppy hat and big, oversized glasses, flamboyant and happy. Ubiquity!
I've been there with Craig in some of the highest points of his life and some of the lowest. I've seen him meet his challenges head on and rise above them. Being his friend was hard sometimes. He demanded much of his friends. But he returned help, joy, and, above all, love. He regretted that his choices hurt others besides himself. Craig loved large and completely.
The last decade of Craig's life was remarkable. Craig, in 2011, was a classic tragic hero: noble, virtuous, and basking in past success but with a seemingly fatal flaw. But Craig's story didn't end in 2011. Drummond Reed, a mutual friend and fellow traveler wrote this for Craig's service:
Ten years ago, when Craig was at one of the lowest points in his life, I had the chance to join a small group of his friends to help intervene and steer him back on an upward path. It was an extraordinary experience I will never forget, both because of what I learned about Craig's amazing life, and what it proved about the power of love to change someone's direction. In fact Craig went on from there not just to another phase of his storied career, but to reconnect and marry his high school sweetheart.
Craig found real happiness in those last years of his life—and he deserved it.
Craig Burton was a mountain of a man, and a mountain of mind. And he moved the mountains of the internet for all of us. The digital future will be safer, richer, and more rewarding for all of us because of the gifts he gave us.
Starting with that intervention, Craig began a long, painful path to eventual happiness and redemption.
Craig overcame his internal demons. This was a battle royale. He had help from friends and family (especially his sisters), but in the end, he had to make the change, tamp down his darkest urges, and face his problems head on. His natural optimism and ability to see things realistically helped. When he finally turned his insightful mind on himself, he began to make progress.
Craig had to live and cope with chronic health challenges, many of which were the result of decisions he'd made earlier in his life. Despite the limitations they placed on him, he met them with his usual optimism and love of life.
Craig refound his faith. I'm not sure he ever really lost it, but he couldn't reconcile some of his choices with what he believed his faith required of him. In 2016, he decided to rejoin the Church of Jesus Christ of Latter-Day Saints. I was privileged to be able to baptize him. A great honor, that he was kind enough to give me.
Craig also refound love and his high school sweetheart, Paula. The timing couldn't have been more perfect. Earlier and Craig wouldn't have been ready. Later and it likely would have been too late. They were married in 2017 and later had the marriage sealed in the Seoul Korea Temple. Craig and Paula were living in Seoul at the time, engaged in another adventure. While Craig loved large, I believe he may have come to doubt that he was worthy of love himself. Paula gave him love and a reason to strive for a little more in the last years of his life.
As I think about the last decade of Craig's life and his hard work to set himself straight, I'm reminded of the parable of the Laborers in the Vineyard. In that parable, Jesus compares the Kingdom of Heaven to a man hiring laborers for his vineyard. He goes to the marketplace and hires some, promising them a penny. He goes back later, at the 6th and 9th hours, and hires more. Finally he hires more laborers in the 11th hour. When it comes time to pay them, he gives everyone the same wage—a penny. The point of the parable is that it doesn't matter so much when you start the journey, but where you end up.
I'm a believer in Jesus Christ and the power of his atonement and resurrection. I know Craig was too. He told me once that belief had given him the courage and hope to keep striving when all seemed lost. Craig knew the highest of the highs. He knew the lowest of the lows. The last few years of his life were among the happiest I ever saw him experience. He was a new man. In the end, Craig ended up in a good place.
I will miss my friend, but I'm eternally grateful for his life and example.
In 2007, I co-founded a company called Kynetx and realized that the infrastructure necessary for building our product did not exist. To address that gap, I invented picos, an internet-first, persistent, actor-model programming system. Picos are the most inventive thing I've done. Being internet-first, every pico is serverless and cloud-native, presenting an API that can be fully customized by developers. Because they're persistent, picos support databaseless programming with intuitive data isolation. As an actor-model programming system, different picos can operate concurrently without the need for locks, making them a natural choice for easily building decentralized systems.
Picos can be arranged in networks supporting peer-to-peer communication and computation. A cooperating network of picos reacts to messages, changes state, and sends messages. Picos have an internal event bus for distributing those messages to rules installed in the pico. Rules in the pico are selected to run based on declarative event expressions. The pico matches events on its bus with event scenarios declared in each rule's event expression. The pico engine schedules any rule whose event expression matches the event for execution. Executing rules may raise additional events which are processed in the same way.
As Kynetx reacted to market forces and trends, like the rise of mobile, the product line changed, and picos evolved and matured to match those changing needs, becoming a system that was capable of supporting complex Internet-of-Things (IoT) applications. For example, we ran a successful Kickstarter campaign in 2013 to build a connected car product called Fuse. Fuse used a cellular sensor connected to the vehicle's on-board diagnostics port (OBD2) to raise events from the car's internal bus to a pico that served as the vehicle's digital twin. Picos allowed Fuse to easily provide an autonomous processing agent for each vehicle and to organize those into fleets. Because picos support peer-to-peer architectures, putting a vehicle in more than one fleet or having a fleet with multiple owners was easy.
Fuse presented a conventional IoT user experience using a mobile app connected to a cloud service built using picos. But thanks to the inherently distributed nature of picos, Fuse offered owner choice and service substitutability. Owners could choose to move the picos representing their fleet to an alternate service provider, or even self-host if they desired without loss of functionality. Operationally, picos proved more than capable of providing responsive, scalable, and resilient service for Fuse customers without significant effort on my part. Fuse ultimately shut down because the operator of the network supplying the OBD2 devices went out of business. But while Fuse ran, picos provided Fuse customers with an efficient, capable, and resilient infrastructure for a valuable IoT service with unique characteristics.
The characteristics of picos make them a good choice for building distributed and decentralized applications that are responsive, resilient to failure, and respond well to uneven workloads. Asynchronous messaging and concurrent operation make picos a great fit for modern distributed applications. For example, picos can synchronously query other picos to get data snapshots, but this is not usually the most efficient interaction pattern. Instead, because picos support lock-free asynchronous concurrency, a system of picos can efficiently respond to events to accomplish a task using reactive programming patterns like scatter-gather.
The development of picos has continued, with the underlying pico engine having gone through three major versions. The current version is based on NodeJS and is open-source. The latest version was designed to operate on small platforms like a Raspberry PI as well as cloud platforms like Amazon's EC2. Over the years hundreds of developers have used picos for their programming projects. Recent applications include a proof-of-concept system supporting intention-based ecommerce by Customer Commons.
The architecture of picos was a good fit for Customer Commons' objective to build a system promoting user autonomy and choice because picos provide better control over apps and data. This is a natural result of the pico model where each pico represents a closure over services and data. Picos cleanly separate the data for different entities. Picos, representing a specific entity, and rulesets representing a specific business capability within the pico, provide fine grained control over data and its processing. For example, if you sell a car represented in Fuse, you can transfer the vehicle pico to the new owner, after deleting the Trips application, and its associated data, while leaving untouched the maintenance records, which are isolated inside the Maintenance application in the pico.
I didn't start out in 2007 to write a programming language that naturally supports decentralized programming using the actor-model while being cloud-native, serverless, and databaseless. Indeed, if I had, I likely wouldn't have succeeded. Instead picos evolved from a simple rule language for modifying web pages to a powerful, general-purpose programming system for building any decentralized application. Picos are easily the most important technology I've invented.
I love getting Azeem Azhar's Exponential View each week. There's always a few things that catch my eye. Recently, he linked to a working paper from Alberto F. Alesina, el. al. called Persistence Through Revolutions (PDF). The paper looks at the fate of the children and grandchildren of landed elite who were systematically persecuted during the cultural revolution (1966 to 1976) in an effort to eradicate wealth and educational inequality. The paper found that the grandchildren of these elite have recovered around two-thirds of the pre-cultural revolution status that their grandparents had. From the paper:
[T]hree decades after the introduction of economic reforms in the 1980s, the descendants of the former elite earn a 16–17% higher annual income than those of the former non-elite, such as poor peasants. Individuals whose grandparents belonged to the pre-revolution elite systematically bounced back, despite the cards being stacked against them and their parents. They could not inherit land and other assets from their grandparents, their parents could not attend secondary school or university due to the Cultural Revolution, their parents were unwilling to express previously stigmatized pro-market attitudes in surveys, and they reside in counties that have become more equal and more hostile toward inequality today. One channel we emphasize is the transmission of values across generations. The grandchildren of former landlords are more likely to express pro-market and individualistic values, such as approving of competition as an economic driving force, and willing to exert more effort at work and investing in higher education. In fact, the vertical transmission of values and attitudes — "informal human capital" — is extremely resilient: even stigmatizing public expression of values may not be sufficient, since the transmission in the private environment could occur regardless.
There are certainly plenty of interesting societal implications to these findings, but I love what it tells us about the interplay between institutions, even very powerful ones, and more decentralized systems like networks and tribes1. The families are functioning as tribes, but there's like a larger social network in play as well made from connections, relatives, and friends. The decentralized social structure or tribes and networks proved resilient even in the face of some of the most coercive and overbearing actions that a seemingly all-powerful state could take.
Last September, China seemed to finally be serious about banning cryptocurrencies, leading miners to flee the country for Kazakhstan. Just eight months later, though, things might be changing again.
Research from the University of Cambridge's Judge Business School shows that China is second only to the U.S. in Bitcoin mining. In December 2021, the most recent figures available, China was responsible for 21% of the Bitcoin mined globally (compared to just under 38% in the U.S.). Kazakhstan came in third.
When China instituted the crackdown, some of my Twitter friends, who are less than enthusiastic about crypto, reacted with glee, believing this would really hurt Bitcoin. My reaction was "Bitcoin doesn't care what you think. Bitcoin doesn't care if you hate it."
What matters is not what actions institutions take against Bitcoin2 (or any other decentralized system), but whether or not Bitcoin can maintain coherence in the face of these actions. Social systems that are enduring, scalable, and generative require coherence among participants. Coherence allows us to manage complexity. Coherence is necessary for any group of people to cooperate. The coherence necessary to create the internet came in part from standards, but more from the actions of people who created organizations, established those standards, ran services, and set up exchange points.
Bitcoin's coherence stems from several things including belief in the need for a currency not under institutional control, monetary rewards from mining, investment, and use cases. The resilience of Chinese miners, for example, likely rests mostly on the monetary reward. The sheer number of people involved in Bitcoin gives it staying power. They aren't organized by an institution, they're organized around the ledger and how it operates. Bitcoin core developers, mining consortiums, and BTC holders are powerful forces that balance the governance of the network. The soft and hard forks that have happened over the years represent an inefficient, but effective governance reflecting the core believes of these powerful groups.
So, what should we make of the recent crypto sell-off? I think price is a reasonable proxy for the coherence of participants in the social system that Bitcoin represents. As I said, people buy, hold, use, and sell Bitcoin for many different reasons. Price lets us condense all those reasons down to just one number. I've long maintained that stable decentralized systems need a way to transfer value from the edge to the center. For the internet, that system was telcos. For Bitcoin, it's the coin itself. The economic strength of a decentralized system (whether the internet of Bitcoin) is a good measure of how well it's fairing.
Comparing Bitcoin's current situation to Ethereum's is instructive. If you look around, it's hard to find concrete reasons for Bitcoin's price doldrums other than the general miasma that is affecting all assets (especially risk assets) because of fears about recession and inflation. Ethereum is different. Certainly, there's a set of investors who are selling for the same reasons they're selling BTC. But Ethereum is also undergoing a dramatic transition, called "the merge", that will move the underlying ledger from proof-of-work to proof-of-stake. These kinds of large scale transitions have a big impact on a decentralized system's coherence since there will inevitably be people very excited about it and some who are opposed—winners and losers, if you will.
Is the design of Bitcoin sufficient for it to survive in the long term? I don't know. Stable decentralized systems are hard to get right. I think we got lucky with the internet. And even the internet is showing weakness against the long-term efforts of institutional forces to shape it in their image. Like the difficulty of killing off decentralized social and cultural traditions and systems, decentralized technology systems can withstand a lot of abuse and still function. Bitcoin, Ethereum, and a few other blockchains have proven that they can last for more than a decade despite challenges, changing expectations, and dramatic architectural transitions. I love the experimentation in decentralized system design that they represent. These systems won't die because you (or various governments) don't like them. The paradox is that they don't care what you think, even as they depend heavily on what everyone thinks.
You know the conventional wisdom that the "close" button in elevators isn't really hooked up to anything. That it's just there to make you feel good? "Keep me logged in" is digital identity's version of that button. Why is using authenticated service on the web so unpleasant?
Note that I'm specifically talking about the web, as opposed to mobile apps. As I wrote before, compare your online, web experience at your bank with the mobile experience from the same bank. Chances are, if you're like me, that you pick up your phone and use a biometric authentication method (e.g. FaceId) to open it. Then you select the app and the biometrics play again to make sure it's you, and you're in.
On the web, in contrast, you likely end up at a landing page where you have to search for the login button which is hidden in a menu or at the top of the page. Once you do, it probably asks you for your identifier (username). You open up your password manager (a few clicks) and fill the username and only then does it show you the password field1. You click a few more times to fill in the password. Then, if you use multi-factor authentication (and you should), you get to open up your phone, find the 2FA app, get the code, and type it in. To add insult to injury, the ceremony will be just different enough at every site you visit that you really don't develop much muscle memory for it.
As a consequence, when most people need something from their bank, they pull out their phone and use the mobile app. I think this is a shame. I like the web. There's more freedom on the web because there are fewer all-powerful gatekeepers. And, for many developers, it's more approachable. The web, by design, is more transparent in how it works, inspiring innovation and accelerating it's adoption.
The core problem with the web isn't just passwords. After all, most mobile apps authenticate using passwords as well. The problem is how sessions are set up and refreshed (or not, in the case of the web). On the web, sessions are managed using cookies, or correlation identifiers. HTTP cookies are generated by the server and stored on the browser. Whenever the browser makes a request to the server, it sends back the cookie, allowing the server to correlate all requests from that browser. Web sites, over the years, have become more security conscious and, as a result, most set expirations for cookies. When the cookie has expired, you have to log in again.
You've used OAuth if you've ever used any kind of social login like Login with Apple, or Google sign-in. Your mobile app doesn't just ask for your user ID and password and then log you in. Rather, it uses them to authenticate with an authentication server for the API using OAuth. The standard OAuth flow returns an authentication token that the app stores and then returns to the server with each request. Like cookies, these access tokens expire. But, unlike cookies, OAuth defines a refresh token mechanism that the app can be use to get a new access token. Neat, huh?
The problem with using OAuth on the web is that it's difficult to trust browsers:
Some are in public places and people forget to log out.
I'm hopeful that we may really be close to the end for passwords. I think the biggest obstacle to adoption is likely that these technologies are so slick that people won't believe they're really secure. If we can get adoption, then maybe we'll see a resurgence of web-based services as well.
Adede Sonaike is another Lagos-based Bolt user since 2018, and said she gets frequently harassed and shouted at by its drivers over even the simplest of issues, such as asking to turn down the volume of the car stereo. Sonaike said these incidents have become more common and that she anticipates driver harassment on every Bolt trip. But on March 18, she told Rest of World she felt that her life was threatened. Sonaike had ordered a ride, and confirmed the vehicle and plate number before entering the car. After the trip started, she noticed that the driver’s face didn’t match the image on the app. “I asked him why the app showed me a different face, and he said Bolt blocked his account and that [he] was using his brother’s account, and asked why I was questioning him,” she recalled. She noticed the doors were locked and the interior door handle was broken, and became worried. Sonaike shared her ride location with her family and asked the driver to stop, so she could end the trip. He only dropped her off after she threatened to break his windows.
The problem is accounts are easily transferable and reputations tied to transferable accounts can't be trusted since they don't reflect the actions of the person currently using the account. Making accounts non-transferable using traditional means is difficult because they're usually protected by something you know (e.g., a password) and that can be easily changed and exchanged. Even making the profile picture difficult to change (like Bolt apparently does) isn't a great solution since people may not check the picture, or fall for stories like the driver gave the passenger in the preceding quote.
Verifiable credentials are a better solution because they're designed to not be transferable1. Suppose Bob wants to sell his Bolt account to Malfoy. Alice, a rider wants to know the driver is really the holder of the account. Bolt issued a verifiable credential (VC) to Bob when he signed up. The VC issuing and presenting protocols cryptographically combine an non-correlatable identifier and a link secret and use zero-knowledge proofs (ZKPs) to present the credential. ZKP-based credential presentations have a number of methods that can be used to prevent transferring the credential. I won't go into the details, but the paper I link to provides eight techniques that can be used to prevent the transfer of a VC. We can be confident the VC was issued to the person presenting it.
Bolt could require that Bob use the VC they provided when he signed up to log into his account each time he starts driving. They could even link a bond or financial escrow to the VC to ensure it's not transferred. To prevent Bob from activating the account for Malfoy at the beginning of each driving period, Alice, and other passengers could ask drivers for proof that they're a legitimate Bolt driver by requesting a ZKP from the Bolt credential. Their Bolt app could do this automatically and even validate that the credential is from Bolt.
Knowing that the credential was issued to the person presenting it is one of the four cryptographic cornerstones of credential fidelity. The Bolt app can ensure the provenance of the credential Bob presents. Alice doesn't have trust Bob or know very much about Bob personally, just that he really is the driver that Bolt has certified.
The non-transferability of verifiable credential is one of their super powers. A lot of the talk about identity in Web 3 has focused on NFTs. NFTs are, for the most part, designed to be transferable2. In that sense, they're no better than a password-protected account. Identity relies on knowing that the identifiers and attributes being presented are worthy of confidence and can be trusted. Otherwise, identity isn't reducing risk the way it should. That can't happen with transferable identifiers—whether their password-based accounts or even NFTs. There's no technological barrier to Bolt implementing this solution now...and they should for the safety of their customers.
I'm speaking of features specific to the Aries credential exchange protocol in this post.
Recently Vatalik el. al. proposed what they call a soul-bound token as a non-transferable credential type for Web3. I'm putting together my thoughts on that for a future post.
// Mon May 30 09:24:00 2022 // blogging
Leslie Lamport said "If you think you understand something, and don’t write down your ideas, you only think you’re thinking." I agree wholeheartedly. I often think "Oh, I get this" and then go to write it down and find all kinds of holes in my understanding. I write to understand. Consequently, I write my blog for me. But I hope you get something out of it too!
I started blogging in May 2002, twenty years ago today. I'd been thinking about blogging for about a year before that, but hadn't found the right tool. Jon Udell, who I didn't know then, mentioned his blog in an InfoWorld column. He was using Dave Winer'sRadio Userland, so I downloaded it and started writing. At the time I was CIO for the State of Utah, so I garnered a bit of noteriety as a C-level blogger. And I had plenty of things to blog about.
Later, I moved to MovableType and then, like many developers who blog, wrote my own blogging system. I was tired of the complexity of blogging platforms that required a database. I didn't want the hassle. I write the body of each post using Emacs using custom macros I created. Then my blogging system generates pages from the bodies using a collection of templates. I use rsync to push them up to my server on AWS. Simple, fast, and completely under my control.
Doc Searls, another good friend who I met through blogging, says you can make money from your blog or because of it. I'm definately in the latter camp. Because I write for me, I don't want to do the things necessary to grow an audience and make my blog pay. But my life and bank account are richer because I blog. Jon, Dave, and Doc are just a few of countless friends I've made blogging. I wouldn't have written my first book if Doug Kaye, another blogging friend, hadn't suggested it. I wouldn't have started Internet Identity Workshop or been the Executive Producer of IT Conversations. I documented the process of creating my second startup, Kynetx on my blog. And, of course, I've written a bit (402 posts so far, almost 10% of the total) on identity. I've been invited to speak, write, consult, and travel because of what I write.
After 20 years, blogging has become a way of life. I think about things to write all the time. I can't imagine not blogging. Obviously, I recommend it. You'll become a better writer if you blog regularly. And you'll better understand what you write about. Get a domain name so you can move it, because you will, and you don't want to lose what you've written. You may not build a brand, but you'll build yourself and that's the ultimate reward for blogging.
Philosophy discussions are the black hole of identity. Once you get in, you can't get out. Nevertheless, I find that I'm drawn to them. I'm a big proponent of self-sovereign identity (SSI) precisely because I believe that autonomy and agency are a vital part of building a new web that works for everyone. Consequently, I read Web3 Is Our Chance to Make a Better Internet with interest because it applied John Rawls's thought experiment known as the "veil of ignorance1," from his influential 1971 work A Theory of Justice to propose three things we can do in Web3 to build a more fair internet:
Promote self-determination and agency
Reward participation, not just capital
Incorporate initiatives that benefit the disadvantaged
Web3, self-sovereign authority enabled by self-certifying protocols, gives us a mechanism for creating a digital existence that respects human dignity and autonomy. We can live lives as digitally embodied beings able to operationalize our digital relationships in ways that provide rich, meaningful interactions. Self-sovereign identity (SSI) and self-certifying protocols provide people with the tools they need to operationalize their self-sovereign authority and act as peers with others online. When we dine at a restaurant or shop at a store in the physical world, we do not do so within some administrative system. Rather, as embodied agents, we operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. Web3, built in this way, allows people to act as full-fledged participants in the digital realm.
There are, of course, ways to screw this up. Notably, many Web3 proponents don't really get identity and propose solutions to identity problems that are downright dangerous and antithetical to their aim of self-determination and agency. Writing about Central Bank Digital Currencies (CBDCs), Dave Birch said this:
The connection between digital identity and digital currency is critical. We must get the identity side of the equation right before we continue with the money side of the equation. As I told the Lords' committee at the very beginning of my evidence, "I am a very strong supporter of retail digital currency, but I am acutely aware of the potential for a colossal privacy catastrophe".
Now, whether you see a role for CBDCs in Web3 or see them as the last ditch effort of the old guard to preserve their relevance, Dave's points about identity are still true regardless of what currency systems you support. We don't necessarily want identity in Web3 for anti-money laundering and other fraud protection mechanisms (although those might be welcomed in a Web3 world that isn't a hellhole), but because identity is the basis for agency. And if we do it wrong, we destroy the very thing we're trying to promote. Someone recently said (I wish I had a reference) that using your Ethereum address for your online identity is like introducing yourself at a party using your bank balance. A bit awkward at least.
If you look at the poster children of Web3, cryptocurrencies and NFTs, the record is spotty for how well these systems reward participation rather than rewarding early investors. But that doesn't have to be the case. In Why Build in Web3, Jad Esber and Scott Duke Kominers describe the "Adam Bomb" NFT:
For example, The Hundreds, a popular streetwear brand, recently sold NFTs themed around their mascot, the "Adam Bomb." Holding one of these NFTs gives access to community events and exclusive merchandise, providing a way for the brand's fans to meet and engage with each other — and thus reinforcing their enthusiasm. The Hundreds also spontaneously announced that it would pay royalties (in store credit) to owners of the NFTs associated to Adam Bombs that were used in some of its clothing collections. This made it roughly as if you could have part ownership in the Ralph Lauren emblem, and every new line of polos that used that emblem would give you a dividend. Partially decentralizing the brand's value in this way led The Hundreds's community to feel even more attached to the IP and to go out of their way to promote it — to the point that some community members even got Adam Bomb tattoos.
NFTs are a good match for this use case because they represent ownership and are transferable. The Hundreds doesn't likely care if someone other than the original purchaser of an Adam Bomb NFT uses it to get a discount so long as they can authenticate it. Esber and Kominers go on to say:
Sharing ownership allows for more incentive alignment between products and their derivatives, creating incentives for everyone to become a builder and contributor.
NFTs aren't the only way to reward participation. Another example is the Helium Network. Helium is a network of more than 700,000 LoRaWAN hotspots around the world. Operators of the hotspots, like me, are rewarded in HNT tokens for providing the hotspot and network backhaul using a method called "proof of coverage" that ensures the hotspot is active in a specific geographic area. The reason the network is so large is precisely because Helium uses its cryptocurrency to reward participants for the activities that grow the network and keep it functioning.
Building web3 ecosystems that reward participation is in stark contrast to Web 2.0 platforms that treat their participants as mere customers (at best) or profit from surveillance capitalism (at worst).
Incorporating Initiatives that Benefit the Disadvantaged
The HBR article acknowledges that this is the hardest one to enable using technology. That's because this is often a function of governance. One of the things we tried to do at Sovrin Foundation was live true to the tagline: Identity for All. For example, we spent a lot of time on governance for just this reason. For example, many of the participants in the Foundation worked on initiatives like financial inclusion and guardianship to ensure the systems we were building and promoting worked for everyone. These efforts cost us the support of some of our more "business-oriented" partners and stewards who just wanted to get to the business of quickly building a credential system that worked for their needs. But we let them walk away rather than cutting back on governance efforts in support of identity for all.
The important parts of Web3 aren't as sexy as ICOs and bored apes, but they are what will ensure we build something that supports a digital life worth living. Web 2.0 didn't do so well in the justice department. I believe Web3 is our chance to build a better internet, but only if we promote self-determination, reward participation, and build incentives that benefit the disadvantaged as well as those better off.
The "veil of ignorance" asks a system designer to consider what system they would design if they were in a disadvantaged situation, rather than their current situation. For example, if you're designing a cryptocurrency, assume you're one of the people late to the game. What design decisions would make the system fair for you in that situation?
Last month was the 34th Internet Identity Workshop (IIW). After doing the last four virtually, it was spectacular to be back together with everyone at the Computer History Museum. You could almost feel the excitement in the air as people met with old friends and made new ones. Rich the barista was back, along with Burrito Wednesday. I loved watching people in small groups having intense conversations over meals, drinks, and snacks.
Also back was IIW's trademark open space organization. Open space conferences are workshops that don't have pre-built agendas. Open space is like an unconference with a formal facilitator trained in using open space technology. IIW is self-organizing, with participants setting the agenda every morning before we start. IIW has used open space for part or all of the workshop since the second workshop in 2006. Early on, Kaliya Young, one of my co-founders (along with Doc Searls), convinced me to try open space as a way of letting participants shape the agenda and direction. For an event this large (300-400 participants), you need professional facilitation. Heidi Saul has been doing that for us for years. The results speak for themselves. IIW has nurtured many of the ideas, protocols, and trends that make up modern identity systems and thinking.
Last month was the first in-person CTO Breakfast since early 2020. CTO Breakfast is a monthly gathering of technologists in the Provo-Salt Lake City area that I've convened for almost 20 years. Like IIW, CTO Breakfast has no pre-planned agenda. The discussion is freewheeling and active. We have just two rules: (1) no politics and (2) one conversation at a time. Topics from the last meeting included LoRaWAN, Helium network, IoT, hiring entry-level software developers, Carrier-Grade NATs, and commercial real estate. The conversation goes where it goes, but is always interesting and worthwhile.
When we built the University API at BYU, we used decentralized decision making to make key architecture, governance, and implementation decisions. Rather than a few architects deciding everything, we had many meetings, with dozens of people in each, over the course of a year hammering out the design.
What all of these have in common is decentralized decision making by a group of people that results in learning, consensus, and, if all goes well, action. The conversation at IIW, CTO Breakfast, and BYU isn't the result a few smart people deciding what the group needed to hear and then arranging meetings to push it at them. Instead, the group decides. Empowering the group to make decisions about the very nature and direction of the conversation requires trust and trust always implies vulnerability. But I've become convinced that it's really the best way to achieve real consensus and make progress in heterogeneous groups. Thanks Kaliya!