Note: this is an early work-in-progress. And yes, we are looking for help with it. Not just criticism (though the constructive kind is good). Thanks.
What is the Intention Byway?
The Intention Byway—or Byway for short—is a way to move messages of intent between customers and companies, buyers and sellers, demand and supply, anywhere in any value chain or among any collection of participants. Its goal is to maximize the quality and volume of economic signaling by everyone and to expand the range of economic activity that can take place in a networked marketplace.
The Byway’s virtues are also not just economic. They apply to all information offered or requested. For example, the byway is can support journalism by providing new paths for information to flow between sources, journalists, and consumers of news.
The Byway is also built on the Internet, and not on the Web, although it can work with the Web and with Web tools and services, much as email does the same. It is an independent framework of participants.
Where are you rolling it out?
Bloomington, Indiana. Doc and Joyce Searls, co-founders of Customer Commons with other board members, will be there at least through the current (2021-2022 Indiana University) academic year, to work with local communities of interest on ways for them to start using the Byway, and with the Ostrom Workshop (where both are visiting scholars) on research as the Byway gets understood and starts to roll out. (On 4 November 2021 this was the subject of a story in the Indiana Daily Student.)
Doesn’t e-commerce today do what the Byway does?
No, it does not. E-commerce today is a seller’s game, rigged to maximize signaling from supply to demand, especially by and within the walled gardens of Amazon, Apple, Facebook, Google, and every advertiser using the Internet. While this works very well, it also leaves money on the table in the form of signals from the demand side—customers to companies—that cannot be expressed or go unheard, because the signaling mechanisms and paths are not there.
Worse, constantly looking for ways to improve supply-to-demand signaling has had the effect of limiting customer agency to what sellers alone allow. This has made e-commerce—and the Web itself—something of a feudal system in which customers, as mere serfs (which computing, along with the drug trade, calls “users”), are forced to interact with sellers in ways that are arcane to each seller, requiring as many unique logins, passwords, opt-ins, opt-outs and relationship systems as there are websites and services.
An indicator of this model’s limitations is that it does not even occur to most developers that a customer might want a shopping cart of her own to take from site to site—or might want a dashboard of her own to manage her relationships across many sellers, in the same way as CRM (customer relationship management) systems on the sellers’ side provide ways to manage relationships across many buyers. (Such a dashboard would be an ideal VRM—vendor relationship management—tool for customers. But we don’t have VRM yet because it’s too hard for developers and their investors to think outside the client-server box.)
Worse than that, all the agreements customers make with sellers are on terms provided by the seller alone, with records kept exclusively by those sellers or their third parties. The best anyone can do in this broken system is to opt in or out of those terms, again separately for every website, app, or service—and always with records kept only by those parties, so there is no way for the person to audit compliance. Mere “users” (of others’ systems) also cannot even think about having terms of their own. This utterly fails to take advantage of the peer-to-peer and end-to-end design of the Internet itself, which can support ways for buyers to scale messaging and relationships across many sellers.
Fortunately, it’s still early. E-commerce as we know it is also barely a quarter-century old. It is not a finished or final system, but rather a young one with many new ways to grow.
Is this a new idea?
Only if you take a long view, which we recommend. Some things take time. The Byway was first described, in a way, at the “my red dot” breakout session at the third Internet Identity Workshop (IIW) in May, 2007. An album of photos from that session, including lots of whiteboarding, is here. One sample:
That red dot is the customer’s own device, and the data and apps the customer puts to use. (Note: VRM stands for Vendor Relationship Management, and has long been the focus of ProjectVRM at Harvard’s Berkman Klein Center. Customer Commons is a nonprofit spin-off of that project, which is still run by Doc Searls, who also serves on the Customer Commons board.
Can the Intention Byway work inside the familiar Web model that everyone knows and understands?
It is essential to recognize that the Internet supports freedom and independence for everyone and everything on it. But the Web, although it was designed by Tim Berners-Lee to provide that freedom, got deployed on a centralized mainframe model called client-server. This model, which might as well be called serf-lord or slave-master, is designed to give the client no more agency than what the server allows or provides. (See what Doc Searls wrote about this in Beyond the Web.)
At this stage in history, we are beginning to see that the limits of the client-server model are those put on the freedom, independence and agency of the individual.
The Byway is designed to work for free and independent actors from every end to any other end: free customers, free sellers, free suppliers, free intermediaries, free agency all around.
The client-server Web is not. Nor is the platform-based mobile device ecosystem we have with Apple’s iOS and Google’s Android devices. Both companies operate walled gardens for the apps that run on their platforms, and can only be obtained from their company stores.
This does not mean, however, that the workings of the Byway are invisible to browsers. It does mean, however, that we need new and better user interfaces than browsers alone can provide, given browsers’ obedience to the design constraints of the client-server model.
How exactly is the Byway distinctive and new?
The Byway is a pub/sub system. Rather than a client-server system such as the Web’s, it uses asynchronous intermediation, similar to the way email works. Unlike email, however, it is not limited to a single protocol or collection of them.
The Byway is also peer-to-peer between its ends, which in e-commerce will be typically between buyers and sellers. Intermediaries facilitating addressing and messaging of the Byway itself are also independent and substitutable. This also means there are not only opportunities for businesses at ends and in the middle of messaging paths, but also competition. This will incentivize and drive the growth of markets, as well as energy and activity within those markets.
This is why the whole Intention Byway is more of an economic model than a technical one.
Can you name the components within the Byway, and what each of them do?
The Intentron is a cheap and simple Linux computer designed to serve the buyer and the seller in those roles alone. It can store data, run apps (including, on the personal side, algorithms called palgorithms), message personal intentions to whole market categories and respond to replies from the other side. It can either be a stand-alone device on premise, or a virtual one in a cloud. The important thing is that it is the customer’s own, and isolated from intrusion over the Net by a firewall.
Apps do all the heavy lifting. Pretty much everything else here is a side topic. Everything one can imagine happening on the byway is embodied in apps.
Messaging services route messages to locations provided within a URN.
Addressing authorities are services that assigns addresses. There are addresses where a app can ‘cast’ (on behalf of a user) and there are addresses ‘owned’ by the apps so they can receive messages (replies to ‘casts’). Apps use distinct address spaces, even if they belong to the same user. These address spaces are requested and assigned (guaranteed to be unique) by addressing authorities.
CDNs [ Are we calling these something else now? Need a descrtiption. ]
Channels are what buyers and sellers can publish or subscribe to. These are every topic one can name.
Given the number of different products and services in the world, and variations within each of those, will this cause a vast ontology with an infinitude of channels? And how will the whole thing be made sensible to both buyers and sellers?
They don’t care, they use apps. Apps do all that.
How exactly will the apps know what channels to create?
We expect to see app sellers’ subject matter experts creating vocabularies (ontologies) of intentions that will live on both buyers’ and sellers’ intentrons.
We also expect usage—by both buyers and sellers—to populate these vocabularies as well.
There will be many specialties. These may be for locations (e.g. Auckland or Kansas City) or topics (e.g. real estate or antique cars)—or anything. When a true intention economy emerges from the widespread use of the Byway, expect everything for sale to appear on it. But not only on the Googles and Bings of the world. Instead, it will appear in any app written for that purpose without requiring a central database.
We also expect apps to make mutual sense of differing usages. For example, a “mother-in-law unit” in California is officially called an “accessory dwelling unit,” or an “ADU.” So an intentcast for one can be heard as an intentcast for the other.
How does search happen, on either end?
Search, as we have come to understand it on the Web, requires that a giant company index the entire Web—a haystack of content of every kind—in real time. That model does not apply here. Instead we call what happens simply find.
What systems are there, or do you see forming, for how customers can make sense of all their relevant data, before they issue any intentcasts? For example: contacts, calendars/scheduling, health, finances, possessions/insurance, and records of receipts, contact history, and agreements.
In the current platform-dominated Web-based e-commerce world, there is little incentive for the development of tools for those needs because nearly all developers are working for sellers, and getting sellers to scale across many buyers. Not for buyers, or for getting buyers scale across many sellers. With the Intention Byway, there are lots of incentives to develop tools that aggregate, combine and make sense of the personal data that matters most to people: their health, financial, and property data; their calendars, contacts, subscriptions, and schedules. And for making connections between these data piles. For example, matching receipts with schedules and location data. Or TV viewing practices with subscription expenses. The incentives are for buyers to get full control of their lives (which currently they do not), so fresh intelligence can be applied toward expressing intentions on an as-needed basis. [Examples go here.]
[Benefits for sellers go here.]
Can communities have intentrons?
Is surveillance possible on a Byway?
First, apps running on the Intentron have no incentive to spy on you, because it’s your own compute node alone.
A concern, however, would be for the app not to leak data outside the intentron, but the intentron firewall can catch that. Another concern would be for the app not to leak data outside the browser either, but that can also be caught and reflected in the app’s “reputation”, but if one wants take paranoia to another level (not necessarily a bad thing), you could imagine a browser that can only interact with the intentron, so it would be able to leak from the browser to any other destination.
Can you see or use the Byway on a browser?
It is possible for an Intentron to have a browser view, and to interact with Web servers. But it will help to understand that, while a browser is used mostly to display what we call “content,” the payload of unseen stuff coming from servers is often immense, and filled with cookies, ads, and other stuff serving commercial interests on the server’s side that you might not share, and in most cases know nothing about. Rather than fight that, the Byway provides a better way for parties to get along and do business: one that roughly replicates the way parties behave in an open market or other social environment in the physical world. Browsers on the Byway are not burdened by any of that, because they are nothing more than a UI for an intentron’s apps.
What is an Intentron likely to cost?
If it’s a physical device, probably less than the average ATM withdrawal. If it’s just software, it’s free.
What kind of firewall does it use?
The firewall that comes with the Linux OS. Sitting on a LAN it also benefits from the network firewall (e.g. that provided by a router for a household LAN).
What are the differences between a buyer’s intentron and a seller’s?
The intentron is the same for all users. One’s role is determined by the combination of apps and algorithms used. One might be a buyer or a seller.
What will keep parties in the message forwarding path from snooping on a customer’s intent signals?
Messages can be public, intended for a public audience, and then this is not a concern. If messages are intended for a limited audience, they should be encrypted with a key only known to that audience. Encryption and decryption happen inIthe intentron before sending and after receiving. While this is the simplest protection method, there are others.
What is the role of personal identity?
There isn’t any, beyond what the buyer and seller choose to reveal to each other in private.
This is because the Byway is a way to pass messages between addresses rather than identities. (We need elaboration here, but this will do for now.)
Who pays who for what?
Intentron owners are customers of messaging service providers. That business is the concern of service providers, and not of the Byway itself. So, while a messaging service provider will route/forward messages on behalf of its customers, how they decide to authenticate and authorize their customers is their business.
How will you attract participants (customers, sellers, intentron and app makers and retailers, messaging and addressing authorities) to this whole system?
We are starting small, working with localities and topical interest groups, first to sandbox each part of the model, and then to scale up as adoption grows.
Which, if any, participants in the Intention Byway can you live without while you scale up the model?
None, really. They are all required. App stores are the only parties not needed immediately. Of course the ISPs and DNS are also required participants.
Explain how publishing and subscribing will work.
The simplest analogy is mailing lists, but it’s not buyers and sellers who send/subscribe. It’s their apps. Buyers and sellers only see the service provided by the app, not the mechanics behind it.
Another analogy is RSS (Really Simple Syndication). As with RSS, on the Byway anyone can publish and subscribe to any feed.
What exactly are the buyers and sellers publishing and subscribing?
They are publishing and subscribing to expressions of intent.
How is it different than Solid?
Actually, we would love for this to work with Solid, so the data your Intentron uses is in your Solid pod.
Does this involve client-server?
Yes, but not in the way it does on the Web. Because the Web uses HTTP, which (doesn’t have to be but in this icase) is synchronous. If a server is offline, a client can do nothing. But because the Byway uses an asynchronous messaging protocol (MessaeMQ). The client;s message stays queued, awaiting the server.