Phil Windley's Technometria

May 22, 2012

Moving Toward a Relationship Network

Braided channels of Matanuska river near palmer

In Facebook Domination Isn’t Inevitable—It’s Not Even Likely, I made a case that just as SMTP-based email represented a decentralization of systems like AOL Mail, it is likely, given market forces, that Facebook will face a protocol-based, decentralized service that performs similar features. This system—for lack of a better word, let’s call it a relationship network—will provide more flexibility and greater scale than what can even be achieved with a centralized system, regardless of how much money Facebook has.

In some ways, Facebook is like email, except it provides multiple channels. Think of each relation in your social graph as a channel. By friending someone, you’ve essentially opened a symmetric channel between your Facebook account and theirs. By virtue of that link, you can post on their wall and they can post on yours. No link, no post. If someone keeps posting things you don’t like, you can sever the link—close the channel—and they can no longer use it to contact you.

Email, of course, is single channel. You have a single email address and once you’ve given it to someone, they can continue to contact or harass you forever unless you’re willing to close the account. Sure, you can write rules to ignore their email but they can easily work around that by using, or even forging, a different “from” address. Email’s single channel design is the reason SPAM exists.

If we classify communication systems along two axes, one saying whether the system is centralized or decentralized and the other indicating whether the system uses a single channel or multiple channels, we might visualize the following matrix:

This matrix gives us a tidy way of exploring the idea of a decentralized relationship network. Whether you view a relationship network as an evolution of email or an evolution of Facebook, the progression is a natural one.

The forcing function is simple: the nature of relationships in the Facebook system can never be as varied and rich as relationships in the real world because people aren’t free to define those relationships on Facebook. Rather, Facebook defines them. As a walled garden, Facebook will always be unable to match the richness and variety of the real world.

In Ranking for signal to noise ratio, Seth Godin says:

Signal to noise ratio is a measurement of the relationship between the stuff you want to hear and the stuff you don’t. And here’s the thing: Twitter and email and Facebook all have a bad ratio, and it’s getting worse.

The clickthrough rates on tweets is getting closer and closer to zero. Not because there aren’t links worth clicking on, but because there’s so much junk you don’t have the attention or time to sort it all out.

Spam (and worse, spamlike messages from organizations and people that ought to treasure your attention and permission) are turning a medium (email) that used to be incredibly rich into one that’s becoming very noisy as well.

And you really can’t do much to fix these media and still use them the way you’re used to using them.

From Seth’s Blog: Ranking for signal to noise ratio
Referenced Tue May 22 2012 14:58:59 GMT-0600 (MDT)

The answer to noise is more flexible channels that can serve their purpose more closely. You can easily control the noise, but more importantly you can define the nature of the relationship and automate interactions.

A bigger problem is trust. Facebook’s channels are fine for talking about your vacation, but not appropriate for other topics. For example, would you have electronic bills delivered by Facebook or Twitter? Not likely. You bank won’t trust them and neither will you. You need a channel that is designed for banking with the right security, privacy, and legal foundations. A open standards-based, decentralized, multi-channel relationship network, however, could easily be used for this purpose because the banks and companies delivering bills could define the nature of the channel. They don’t have to wait for Facebook to get around to it and then hope they do it “right.” Relationship networks will support multiple, competing trust frameworks in the same way that the Web supports multiple, competing search engines. Such trust frameworks will provide the reputation systems that enable new relationships to form.

In the matrix I show above, I put relationship networks emerging in 2016. I don’t have any science behind that, it’s a complete SWAG. Nevertheless, I believe that market forces are driving us inexorably toward them even if my time-frame is off. I simply don’t believe that humans will allow the entirety of their lives to be prune, manicured, and domesticated inside someone else’s walled garden for long. Relationship networks provide a compelling alternative to today’s so-called social networks.

May 21, 2012

Facebook Domination Isn't Inevitable—It's Not Even Likely

Someone recently asked me why I thought the vision I’ve been promoting around personal clouds can come to fruition in the face of Facebook’s awesome power. With 900 million members and $18 billion in the bank, isn’t Facebook becoming the one identity provider to rule them all? Won’t everyone just use Facebook as their cloud? Shouldn’t we all just get used to writing Facebook apps and forget about the business of personal clouds? These points (and others) are hard to argue with. Facebook seems like an unstoppable juggernaut.

And yet, we’ve seen such things before. AOL in the early 90’s had that same feel to it. AOL was synonymous with going online. And yet something did upset AOL. A little thing called the Web. Note that I didn’t say “Internet.” The Internet was around in 1990, but no one on AOL cared about it. All you could do with the Internet was send mail (which AOL users could already do) and FTP stuff…whatever that was. There were lots of companies who had a presence on AOL. AOL was the gatekeeper to it’s 2.5 million members and if you wanted access, you dealt with AOL.

And yet, the world moved from a centralized system (AOL) to a decentralized system¹ (the Web) in a few years. The problem with comparing the Internet to AOL in feature-set and functionality terms was that as a decentralized, open system, the Internet had tricks up its sleeve that AOL couldn’t match. When the Web came along, AOL’s fate was sealed. Now, Facebook has created a centralized system for social interaction. Compared to what you can do with Internet-thingies—like blogs, it looks pretty sexy. And still, I think it will eventually fall to a decentralized response.

We seem to yo-yo back and forth between centralized and decentralized online interaction models. This isn’t surprising. Humans love centralized, hierarchical systems. They are easy to understand and predictable. They’re tame. They’re easily controlled. Consequently, we default to centralized when we build things.

Decentralized systems, on the other hand, are often described as wild and unpredictable. Decentralized systems are hard to understand and even more difficult to control. They defy our efforts to rein them in. But, for all their benefits, centralized systems have some big flaws. They are single points of failure, they limit freedom to participate and they don’t scale well.

The (Eventual) Fall of Facebook

Let’s focus on scale for a bit. As I said, scale is hard for centralized systems. See Geoffrey West’s talk a TED for an entertaining presentation of the surprising math of cities (decentralized) and corporations (centralized) for a great explanation of this. Still, you might argue that with 900 million members, Facebook has scaled pretty well.

But scaling is more subtle than simply adding new users. Scaling involves providing the services that keep everyone happy. Let me give an example. Suppose you’re responsible for innovation at a bank. You’re trying to figure out how over the next decade your bank can increase revenue by providing new products and services to customers. Do your think that your boss will be satisfied with a “social media strategy?” Are you going to create significant new revenue for the bank by creating a new page on Facebook or tweeting better? Even a Facebook app isn’t going to do much.

The problem is that Facebook’s centralized architecture has intermediated the banks. Facebook has the relationship with the customer, not the bank. And Facebook’s business model is to squeeze value out of that relationship for Facebook. There are things that banks will want to do that aren’t in Facebook’s interest. For example, Facebook is unlikely to enable features that make banks happy if those same features make the movie industry unhappy. A centralized system implies that decisions are made centrally for the organization’s best interest. Even more difficult, not every bank wants to pursue the same strategy, so centralized systems almost always end up leaving more and more people dissatisfied as they scale.

Replacing Facebook

Facebook is primarily in the relationship business. But relationships can be decentralized. When the Internet’s relationship infrastructure is decentralized more companies will be able to play a role in providing relationship services and those services will be more varied and customizable.

Again the case of AOL is a good example. AOL was good enough until it wasn’t. What replaced it was a decentralized system that provided much the same thing without the restrictions of the centralized system that AOL built. At the heart of that decentralized system were two protocols: SMTP and HTML. All of a sudden, anyone could stand up a server and send email or share Web pages. People quickly went beyond the simple kinds of pages that the Web provided, using HTML as the vehicle for creating the rich range of online services that constitute the Web.

Besides those two protocols, there was DNS, or the Domain Name Service and the URLs that rode atop it. Most people don’t realize that DNS wasn’t in widespread use until the early 1990s. Following quickly on the heels of DNS was the invention of URLs, a system that provided universal naming for anything you could put online.

Protocols represent a way to do things that lets anyone participate and solve their own problems. Protocols are our primary tool in moving from centralized to decentralized systems. Consequently, people and companies who are unhappy with Facebook’s offerings and service have a real choice for something else. The services Facebook offers can be replaced by a decentralized system based on protocols.

Will it happen? The history of commerce is littered with the memories of seemingly unstoppable giants. There’s always something new under the sun. That history would also tell us not to look too closely for something that looks just like Facebook but is decentralized. That’s rarely what happens. Disruption usually occurs in the weeds, where the incumbent isn’t even trying to compete. The thing that undoes Facebook likely won’t even be seen as a social network in the way we define those terms today.

Ways not Places

I’ve become a proponent of ways over places—that is, of protocols over Web sites. When it comes down to it, Facebook is a Web site—a great big, complicated Web site. The fact that it has a programming model (apps) and an API do nothing to change the fact that it is centralized and thus ultimately limited in scale and scope.

More people—especially geeks—need to understand that protocols are worth the effort they require. And let’s not dodge that; decentralized systems are more work. They are harder to design, harder to build, and harder to bootstrap. But the forcing function, freedom, is powerful and eventually wins out.

Bonus Material

Doc Searls has a great piece on the real story of Send that discusses the importance of protocols.
Dave Winer has written We *can* do better than Facebook discussing why the seeming inevitability of a Facebook dominated world doesn’t square with history.

1 Note that I really do men decentralized. A centralized system is one where a single agent makes a single decision, a distributed system is one where multiple agents make a single decisions, and a decentralized system is one where multiple agents each make their own decision.

May 15, 2012

Standard Information Sharing Labels

Some years ago, based on an idea that came up on a train ride to the airport from OSCON, Kaliya Hamlin, Aldo Castaneda and I put together a The paper for the W3C Workshop on Transparency and Usability of Web Authentication was accepted for presentation on identity rights agreements. The idea is that you ought to be able to mark up data you share to let people know how it can be used. Think Creative Commons for personal data. Recently a number of people, including myself, Drummond Reed, and Marc Davis, discussed a similar idea at a WEF Tiger day.

Joe Andrieu has a proposal that is slightly less ambitious and serves as the launching pad for more complete solutions. Joe’s idea is simple and easy to understand. Just like we have a standard label for drugs so that people can more easily understand how to take a drug and what it does, we should have a standard label for sites that want you to share your personal information so it’s easy to understand what’s going to happen if you say yes. Contrast this with the current EULA model where people are faced with 70 pages of information in a non-standard format that they need to understand if they’re to truly be smart about what they share.

Joe has a Kickstarter project for Standard Label to get money to design the label. If you care about understanding what you’re sharing and think people should be smarter about what they share, then I encourage you to support this project, even if you can only give a $1, give something so show you’re behind the work. Here’s the video from the Kickstarter page.

Now, go and back the project!

Rich Sharing and Personal Channels

The Social Web has shown us the power of connecting. Facebook has friends, LinkedIn has connections, and Twitter has followers. These channels allow their owners to communicate with others, although their capabilities vary greatly. But the resulting relationship graphs are stilted because their proprietary nature makes interoperation and extension difficult—in spite of all of the money and time invested in creating APIs to access them.

I look forward to a relationship network that is based on open standards just as the email network and indeed the Internet itself are. The power of the Internet to serve an untold variety of purposes in a flexible way is a direct result of the open standards upon which it is based. Relationship networks based on open standards will provide unprecedented value and opportunities for people because of the new applications it will engender.

This paper will describe something called a personal channel, based on open standards and protocols, that can form such a relationship network. Personal channels link personal clouds, the subject of an earlier white paper. This paper assumes a knowledge of personal clouds, their features and their capabilities. We will share that channels have properties necessary to induce rich sharing, a hallmark of flexibility without which they would not be able to accomplish all that is needed.

Personal Channels

Long ago, personal computers were interesting in their own right. That changed in the 90’s with the emergence of widespread network connectivity. Anymore, a PC that’s not connected to the Internet is not only boring, it’s non-functional for many of the tasks that people perform every day. If you don’t believe me, just turn off the network on your computer for a day. And of course, the modern personal computer—the smartphone—makes connectivity the very foundation of the platform.

Like personal computers, personal clouds are only interesting when they are connected. Personal channels link personal clouds. The collection of channels connecting myriad personal clouds form a relationship network. On an open standard relationship network, the attributes, permissions, and capabilities of a relationship are standardized and extensible. Every relationship is a link. A link may be a simple one-way (asymmetric) subscriber relationship that does not require involvement of the second party, or it may be a stronger two-way (symmetric) relationship in which both parties act as publisher and subscriber.

In either case, when data and messages can flow in one or both directions across a link, it is called a channel. The control each party has over the channel—the terms and conditions to which they agree over how it will work—is called a link contract. Control over the channel still resides in the link contract(s) with the connected parties. The following figure shows two personal clouds connected via a channel controlled with a link contract.

Personal clouds linked by personal channels

Channels exhibit the following properties:

Personal channels provide separately revocable, separately trackable authority to share between personal clouds.
Any given personal cloud can have any number of inbound and outbound channels. Any two personal clouds may share multiple channels for different purposes.
Channels use a combination of the Event eXchange Protocol (EXP) and XRI Data Interchange (XDI) protocol that give them metaprotocol capabilities. Channels are ways of doing something instead of a place for doing something.
Link contracts are a flexible means of declaring fine-grained access control to data and services. Link contracts specify the nature and behavior of a channel.
Channels are the conduits over which messages pass between personal clouds. These messages include event notifications, data queries, and data transfers.
A channel need not be restricted to just two parties. It may connect the members of a group (e.g., email distribution lists), or access may be fully public (e.g., blogs or Twitter feeds).

Like email, channels form a point-to-point network between personal clouds all speaking the same protocol. Unlike an email server, whose sole function is usually email processing, a personal cloud is more like a general-purpose computer in the cloud; it has an operating system that runs applications, processes events, and manages data under direct control of its owner.

This is why channels on the relationship web can be dramatically more useful to individuals and businesses than ordinary email or Web connections.

Rich Sharing

Marc Stiegler of HP Labs has written (PDF) and spoken about rich sharing. Alan Karp has written about PubShare, a system Marc built that demonstrates rich sharing. Alan relates two stories that contrast our expectations about sharing in the physical and online worlds. The first takes place in the physical world:

In an emergency, Marc asked me to park his car in my garage. I couldn’t do it, so I asked my neighbor to do it for me and said to get the garage key from my son.

The second involves an online file sharing scenario:

In an emergency, Marc asked me to copy a file from his computer to mine. I couldn’t do it, so I asked my neighbor to do it for me and said to get access to my computer account from my son.

The second story is ludicrous to us because we can’t see a reasonable way for it to work even though it closely resembles the scenario from the physical world.

Rich sharing characterizes what makes human communication in the physical world work. Using this model, we can determine how to create better online communication systems. Communication systems, like email, that embody rich sharing feel natural to users and thus succeed. Systems that don’t feel stilted or unwieldy and thus don’t scale the way their designers intended.

Sharing is easy and technically uninteresting in situations where the shared item is public and there’s no need to authorize access to it. Similarly workgroup-style sharing is relatively straightforward and the tools for protecting resources in workgroups such as role-based authorization control (RBAC) and access control lists (ACLs) are well understood. For purposes of contrast, let’s call unprotected and workgroup-style simple sharing.

Sharing becomes much more nuanced when access to the shared item must be restricted and the players in the sharing scenario operate in independent security domains. Many real-world scenarios require rich sharing. Stiegler and Karp demonstrate why workgroup-style sharing can’t accommodate rich sharing scenarios.

Rich sharing is characterized by six key features:

Dynamic—Sharing can be done without reconfiguring the system or having other work done by the sharer’s IT department.
Attenuated—Sharing happens with the right permissions on the right items.
Chained—A shared item can be reshared in appropriate ways. Authority can be re-delegated. Building attenuated chains of delegated authority is difficult in simple sharing architectures.
Cross domain—Sharing can occur across security domains without the user linking the domains in an ad hoc manner or the IT department having to setup special purpose federated identity systems.
Recomposable—The shared item or service can be used in conjunction with other resources and services even if those documents and services exist in a separate security domain.
Accountable—Even though sharing can be re-delegated along a chain, the original owner must maintain the ability to audit and track the use of the shared item and hold the appropriate parties accountable for misuse.

Stiegler and Karp make a case that email succeeds because email demonstrates these six attributes. In contrast, it’s easy to find examples in other sharing architectures that fail to incorporate one or more of these and thus become difficult to use as the sharing scenarios get more complicated. Today’s popular social networks all fail to meet one or more of the above attributes.

Personal Channels Support Rich Sharing

Personal channels exhibit rich sharing. We mentioned in an earlier section of this paper that channels provide a metaprotocol for interaction. Thus they represent a way of doing things rather than a place. Rich sharing is more easily supported by ways—protocols—rather than by places. In fact, I argue that properties of rich sharing such as being cross domain and recomposable are nearly impossible to achieve using a place such as a Web site.

Let’s examine the attributes of rich sharing and see how channels stack up:

Dynamic—A personal cloud can use a personal channel to send a message to any other personal cloud that subscribes to it at any time. Subscriptions can be formed between two personal clouds or between a cloud and another network service at will.
Attenuated—Link contracts provide a means of fine grained access control that enables attenuation.
Chained—Upon receiving a message on a channel, a personal cloud can delegate that message to other personal clouds. This delegation may be algorithmic, but is always under the ultimate control of the personal clouds owner.
Cross domain—Each personal cloud functions as its own domain in the same sense that an email inbox represents an independent domain controlled by its owner. Thus a channel carries messages from one domain to another.
Recomposable—Messages sent along a channel, be they events, queries, or data are composed with other information from other sources (e.g. APIs, other channels, etc.) as part of the processing done by a personal cloud.
Accountable—Channels are uniquely identified and individually revokable. The unique identity combined with the ability to declare authoritatively the nature and behavior of the channel via link contracts provides flexible accountability that can be tuned to a given purpose.

Conclusion

Rich sharing requires that the sharing be dynamic, accountable, recomposable, and cross-domain, while enabling the chaining (repeated redelegation) of attenuated access (including separable revokablity). We have shown that personal channels exhibit these properties and thus enable rich sharing.

Because channels support rich sharing, they are extremely flexible and can be used for many purposes. Personal channels provide a messaging system for personal clouds that provides access-controlled, filtered, trustworthy notifications, data exchange, and sharing. Future papers will expand on these benefits of personal channels.

May 9, 2012

Unlocking Data Exchange: The Long Tail of Data

Much has been made of data lately. And with good reason. Data and the ability to exchange and process it are at the heart of modern society’s productivity and prosperity. Data and algorithms are the engines that drive the economy in the 21st century.

But data is often onerous to obtain, difficult to trust, and hard to understand. Fixing these problems—making trustworthy, understandable data flow more freely, consistently, and reliably—will provide a wellspring of new ideas and companies to prosecute them.

This post makes a case that there is a structural problem standing in the way freely flowing data and describes a method for removing that structural barrier.

The Long Tail

In October 2004, Chris Anderson introduced the concept of the long tail in an article in Wired magazine. The idea, simply put is that the infinite shelf space and near-zero distribution costs brought about by the Web have revolutionized many businesses by allowing them to compete for business that was formerly too expensive to service.

The concept is called the long tail because if you plot the power law distribution of the relevant data (e.g. revenue from sales of a given book title, song title, airline ticket to a particular destination, and so on) there’s always a cut off point where it gets too expensive to service the business using traditional business models. Here’s one of the charts from the Wired article:

Notice that in the example shown there is a line on the curve and to the left of that line the words “Songs available at WalMart and Rhapsody”. The area under the curve to the left of the cut line is the head of the curve. The area under the curve to the right of the cut—the yellow sections—is the tail and since it’s long when you have infinite shelf space, it’s the long tail. The area in the long tail is the revenue available to Rhapsody but not to WalMart.

The important point is that Amazon, Rhapsody, and Netflix, to use the examples in the graph, can sell all the same product as their competitors as well as product their competitors can’t. A brick and mortar book store can’t stock every book, but Amazon can. In many cases the area—and thus the available revenue—of the tail is larger than the area in the head.

The Long Tail of Consumer Credit

In credit markets, the kings of the long tail are Visa and Mastercard. You need credit to make a purchase. Before credit cards, you would have made a deal with the local merchant to extend credit, or in the case of a large purchase, taken out a consumer loan at the bank (my parents used to do this). Now, we just put it on the card.

The credit card, largely developed in the 1950s and 1960s represents a huge leap forward in thinking about how credit is extended. Some companies, like Diner’s club and American Express developed a credit system that was based on each merchant and consumer having a direct relationship with the credit card company. Many banks did the same thing. In contrast, Visa and the Mastercard established credit networks. The following diagram depicts the relationships in the credit network.

In a credit network, both the customer and merchant have a relationship with their respective bank and their banks have relationships with the Visa network.

Table 1: Comparing Credit
	Without Credit Network	With Credit Network
Relationship	one-to-one	any-to-any
Credit Terms	per-loan	on demand
Penetration	select merchants	ubiquitous
Processing cost	expensive	cheap

Table 1 shows a few of the differences between credit before and after credit cards:

Relationship—before credit networks, credit was extended on a one-to-one basis. You made a credit arrangement with each lender. With credit cards, the arrangement is any-to-any, you can walk into almost any merchant on earth and use credit with no need for a prior relationship. Moreover, in the networked model, both customer and merchant have relationships with independent banks. Any bank will do, so long as they’re a member of the network.
Credit terms—before credit networks, credit was done on a per-loan basis. When you needed credit, you filled out the forms for a particular credit transaction. The next week you might do it all again for another. With credit networks, you get credit on demand, in real-time
Penetration—before credit networks, you had to select merchants based on what cards they accepted. This was frustrating to merchants and customers alike. With a credit network, even though there are still many cards, they are interoperable with any merchant, making their penetration nearly ubiquitous.
Processing cost—without credit networks each transaction has to be negotiated and approved individually and, often manually. With a credit network transactions costs are greatly reduced through standardized contracts and automatic approval and settlement.

These attributes are what give credit networks their long tail potential. Credit transactions of all sorts are available to a wider range of people for a wider range of goods and services from a wider range of merchants.

The Credit Network

We call Visa a “network” but that label may be confusing to people who think of networks in terms of routers and data connections. In fact Visa is two things (yes, I’m simplifying a great deal here):

A collection of contracts
A protocol

Notice there are no wires. The wires are provided by companies like First Data Corp. who actually do the processing according to the terms of Visa’s contracts and protocol. Nevertheless, a network it is because it links countless people and merchants via their banks through the mechanisms of contracts and protocols.

The magic of Visa is the realization that each bank didn’t need a contract with every merchant and every customer or even a contract with every other bank. That’s why Visa is a “network.” Visa has contracts with each bank, the banks have contracts with customers and merchants and the chain of contracts from a customer, to her bank, to Visa, to another bank, and finally to the merchant is sufficient to convince the merchant that she will be paid when she walks in a buy a new pair of shoes. Every time you use your credit card, you exercise a different path through those chains of trust. Visa is thus a trust framework.

By establishing a network that was

any-to-any,
on demand,
ubiquitous, and
cheap,

Visa was able to create a system that services the long tail of credit. Almost any transaction, almost anywhere can be handled by their network for pennies on the dollar.

Data Exchange Networks

The world of data exchange looks, in many ways, like the world of credit before Visa. Companies like Acxiom, D&B, Experian, and Lexis-Nexis sell data on a one-to-one basis, according to pre-executed contracts, in batch. And it’s not cheap. These are companies who have built profitable businesses servicing the head of the curve. But they don’t service the long tail. They can’t, because they don’t have a network.

Imagine you want to start a business that needs access to risk data (i.e. data about the trustworthiness of a business or person). First, you’ll have to go through the sales process where you’ll be screened to ensure you can sign a contract that has a monthly minimum (say $5000/month), then you’ll have to go through legal to get contracts in place, finally you’ll agree to the format for your batch of data and integrate your systems with those of the data company. Of course, you’ll pay more if you need data more frequently than the norm.

If you only need a little data, or data on demand, or from different sources depending on the transaction, you don’t fit in the head of the curve. How many startups don’t get built because their business model needs, but can’t afford, access to data? How many startups don’t get built because they can’t make data available cheaply? These are lost opportunities that need a new model if they’re to be realized.

A data network solves this problem in exactly the same way that the Visa network solves the credit problem. By putting contracts in place up front and building a trust framework upon those contracts, a data network allows cheap, ubiquitous, on demand, any-to-any access to data.

Drummond Reed has built a company around this very idea, called Respect Network Corp (RNC). The idea is that like Visa or Mastercard, RNC will use standardized contracts to create relationships with data providers and data consumers. Protocols will describe how data transactions are initiated, negotiated, and consummated. Payment will be based on the value of the data but is likely made outside the data network on an existing payment network since they’re optimized for that. As an aside, if you look at RNC’s business model, you’ll see a slightly different version of this based not on raw data transfers as I’ve described here, but more long-term relationships between merchants and their customers.

Kynetx is working closely with RNC in building the network. The model and legal framework are fairly well understood. What is less well defined at this point is the nature of the data exchange protocols. Our recent white paper, From Personal Computers to Personal Clouds, outlines what we think the nodes in the network will be like. The network itself must provide services to these nodes so that they can interact efficiently and safely. Specifically, the network must provide the following services:

Reputation—in any-to-any interactions, players will frequently do business with nodes in the network with whom they don’t have a pre-existing relationship. In the credit network, this function is performed by the banks who issue merchant accounts and by fraud algorithms that try to detect bad actors. In a data network, anyone, even the customer, might be a data provider, so a reputation system can remove some of the risk in knowing who is providing reliable data.
Discovery—finding the data provider who has the data you want at a price you’re willing to pay is tough job without some help. The network will provide discovery services to aid in this task.
Semantic Mapping—the individual nodes in the network provide semantic data interchange, but for that to work, they need semantic maps (e.g. ontologies) that have been agreed to by participants in the network.
Brokerage—the network facilitates payment, probably through an existing credit network. The network also facilitates setting up subscriptions to data services by passing channel details from publisher to subscriber when the relationship is established.

Building this network is a tall order compared to building credit networks. Financial transactions, for example, have simple semantics compared to data transactions. A few well-established protocols suffice for authorizing and settling credit transactions. In contrast, data transactions may need multiple protocols depending on the exact exchange, even with semantic data interchange in place. Nevertheless, such a network would open up the long tail of data transactions for dozens, even hundreds of companies in the same way that the Web opened up the long tail to ecommerce companies.

The good news is that in the second decade of the 21st century, we’re ready to take on this task. The Web provides a foundation for transport and recent advances in the understanding of APIs and data interchange have prepared countless developers and companies to work in this new world. The technologies and systems described in From Personal Computers to Personal Clouds including the Event eXchange Protocol (EXP), Kinetic Rule Language (KRL), and XRI Data Interchange (XDI) are the key components in building this network. The legal framework being put in place by Respect Network Corp provides the glue that binds them together.

Public and Private

There may be some reading this who have grave misgivings about what I’ve described because it envisions a private, rather than public, data network. I believe that this network has to be, at least partially, private for the same reasons that no one has ever created a public credit network to rival Visa and Mastercard. The primary reason is trust.

The protocols that underlie the network I’ve described are all public or open source and thus available to anyone. What can’t be open source is the legal framework that engenders that trust. There will necessarily be an organization that is the foundation of those contracts. While there may be several of these data interchange networks over the next few years, I believe this will likely devolve to duopoly as most other quasi-public utilities seem to do.

Unlocking Data Interchange

The network I’ve described in this paper solves a structural problem in data interchange that limits current business models to one-to-one, heavyweight relationships. Building an open data interchange network underneath a trust umbrella, enables new business models to thrive by reducing the friction and expense through lightweight, any-to-any interactions.

May 2, 2012

PDS Interoperability

Last week in London, I attended a workshop Iain Henderson put on at Innovation Warehouse on Personal Data Store interoperability. He used the following illustrative use cases to talk about what interoperability means for a personal data service (PDS):

As an individual, I want to be able to pick up my data from one personal data service (locker etc.) and drop it into another with minimal fuss
As an individual, I want to be able to have applications run on my personal data, even when it exists in multiple different services
As an individual, I want the apps I had running on my personal data in one locker service, to work when I move my data to another one
As an application developer, I want the apps I build to run, with minimal overhead, across multiple personal data services
As an organisation willing to receive and respond to VRM style data feeds; I don’t want to have to set up different mechanisms for each different VRM provider
As an organisation willing to provide/ return data to customers as part of our proposition to them; I want to be able to make this data available in the minimum number of ways that meet the users needs, not a different format for each personal data service provider
As an organisation willing to provide/ return data to customers as part of our proposition to them; I don’t want to have a different button/ connection mechanism for each personal data service provider on the ‘customers signed in’ page of my web site

These are worth striving for. Just having a place to put personal data isn’t much use to me unless I can use it, move it, etc. As more and more companies become personal data service providers, they will do well to think through how they’re planning for these. Kynetx is working on a project over the next 6 months to specifically address the developer side of this. Specifically, I think developers need two things:

location independent references—applications will be easier to write if the developer doesn’t have to know where the user’s data is stored and the particulars of the API, authorization scheme, and so on.
semantic data interchange—The developer shouldn’t have to parse the semantics of each data services particular tags, field names, and so on. A simple example is “cell” vs. “mobile” in a contact data store.

The particular technology we’re using to do this is XDI. We’ll be experimenting with how an XDI server can be integrated with the Kinetic Rules Engine and how XRI references and XDI statements can be incorporated into KRL.

April 27, 2012

Starting a High Tech Business: Being Startup Compliant

I’m the founder and CTO of Kynetx. This series of articles relates my discoveries and feelings about starting a high-tech business. This is the thirty-second installment. You may find my efforts instructive. Or you may know a better way—-if so, please let me know!

I run into people all the time whose lives are not startup compliant. They express a desire to start a company and have ideas, but they’ve made choices that limit their ability to live the startup life. They say “I’d like to start a company, but I need a salary.”

Starting a company requires extreme flexibility in personal finances. You will likely work for long stretches with no or greatly reduced salary. Debt is the number one impediment to being flexible. Whether it’s a high mortgage, student loans, child-support payments (not exactly debt, but still a future payment obligation), car loans, or credit cards, many people are not able to start a company because they’ve given away their freedom by going into debt in one way or another.

I estimate that since starting Kynetx five years ago, there has only been a 18 month period where I was at full salary. How do we get by? We have a very low debt load; we have no debt besides a mortgage. When you have a low debt load, slashing expenses is as simple as not buying stuff. There’s all kinds of room in a typical family budget to do this. But when you have a high debt load, much of your income goes to servicing debt. As a consequence, there’s just not as much room to slash expenses.

Young people are naturally more flexible in their finances because they don’t have as many kids, a mortgage, and so on. I tell students that the best time to start a company is right when they graduate. They’re already used to being poor, so it’s not a big change. This is a point that I think is largely overlooked in discussions about how to unleash more innovation: student debt reduces the number of people who can afford to start a company. (Note: student loans are especially pernicious for other reasons.)

If you want to be an entrepreneur, you have to stay out of debt. If you’re in debt, use the snowball method to get out of debt and save an emergency fund. Once that’s done, you’ll be free to enjoy starting a company because you’ll have less worry about what happens if things don’t go well. Debt is a form of enslavement that you just can’t afford.

April 24, 2012

The Multiple Passport Problem: Declaring Digital Sovereignty

This morning Patrick Towell mentioned the multiple passport problem. I’d never heard that phrase before, so I asked him to explain. The multiple passport problem describes the world where we have multiple accounts, identifiers, and copies of data at every Web site. I was familiar, of course, with the problem, but not the name he’d given it. I think describing it as multiple passports is brilliant because that name accounts for some of the frustration we all feel. We have to keep credentials—passports, if you will—for every site. We are citizens of every Web site and thus have a home at none of them.

Logging in with Facebook, Google, or Twitter via OAuth makes the problem somewhat more palatable as we now can use our citizenship at one Web site to enter and participate in another. Still this, at most, saves us having separate identifiers, but we still usually duplicate attributes.

The clear alternative to all this is for us to each be sovereign, issuing our own passports, or at least choosing the place where we are citizens of (our identity provider) and using that passport everywhere. That model is better because that’s all how we view ourselves—at the center of our experience. Any model that better aligns with the vision people bring to the Web is bound to better serve them and, in the long run, the Web sites and applications as well.

To carry this point a little further, any identification is a model. Most are fairly limited and thus limited in what they can achieve. Facebook has a much better model of me—merely by including my relationships—than almost any other Web site. I don’t think it’s an accident that they are able to thereby provide greater perceived value to their members. I think it stands to reason that if we were to give users tools that make it easy to self-model and thus put more and more of the data about themselves online, then the model that results would more accurately match truth and thus even more value would be unlocked.

This is the promise of user-centric identity and personal data: greater value for everyone without people having to sacrifice their privacy, a rare win-win. If this is at all interesting to you, come to IIW next week and discuss it with us.

April 23, 2012

From Personal Computers to Personal Clouds

I’ve created a white paper from the series of blog posts I did over the past few weeks. If you’ve read those, this will all be familiar. The white paper is a convenient way to get the whole thing in a single package or share the ideas with someone else. Here’s the description:

From Personal Computers to Personal Clouds explains why the future of personal clouds will be very different from what you have imagined. As more and more of our interactions move online, we increasingly have need of an online place that operates for us. Personal clouds must become more than appliances to achieve their real potential. While appliances provide value, they can’t anticipate every need. They aren’t flexible enough. This paper outlines a vision of personal clouds as general purpose virtual computers. Making that vision real requires an operating system so that developers have a framework to work within. Operating systems provide a core set of services around identity and data as well as a programming model. Download a copy now to learn how those services will work.

This paper is the first in a series that will explain how all of this fits with what we’re calling The Live Web. You can download the white paper in a number of formats (I think the iBooks version looks the best):

Please feel free to share this white paper widely. I’m interested in hearing what you think of the ideas.

Organizations Get the IT They Deserve

Technometria

About Phil

Essays

Visit Count

Software

Topic Guides

Categories

Archives

Utah Tech Organizations

Friends

Copyright

Buy My Book

I'm CTO of Kynetx

Dates for IIW

Free Newsletter!

Search

Find Me Elsewhere

Digital Identity

Upcoming Events

Recent Entries