Discovery and QR Codes

Phil Windley // Mon May 20 09:59:00 2013 // qr+codes squaretag discovery personal+clouds

Some people hate QR codes. Certainly Kevin isn't alone in this. Doc relates a conversation with JP with essentially the same emotion. I have to admit that I'm ambivalent about them: I see them as a useful tool that will be replaced by better tools in the future. That might surprise you if you know anything about SquareTag, a personal cloud product from my company, Kynetx.

I won't go into the details of what SquareTag does. You can read my recent blog post Using Products to Build Customer Relationships to understand that better. One thing to note as you read it, however, is that QR codes play only a bit part in the narrative.

I describe the QR codes in SquareTag as a time machine. QR codes allow me to jump past the problem of "how do I discover the cloud associated with this thing" and get right to thinking about "what if every thing had a cloud?" What role do QR codes play in SquareTag? Discovery. QR codes provide SquareTag with a convenient way for people to discover and claim the clouds associated with a thing. Let me unpack that a bit.

The underlying idea of SquareTag is to give everything (and I mean every thing, place, concept, organization, etc.) an online presence—a little virtual machine that can store data about the thing and run programs on it's behalf. There are lots of reasons to do this from cool new features and functionality to better relationships between manufacturers and their customers. I've even written about why giving clouds to potholes makes sense.

The problem is: how do I discover a thing's cloud so that I can interact with it? The thing's cloud has a unique identity, but that's a long string of characters that humans won't reliably or happily enter into their mobile phones. So, we give each cloud a short code. For example, the short code for my Bose noise canceling headphones is U7VHQP. You can either type that code in at SquareTag or enter a URL directly: http://sqtag.com/U7VHQP.

But even that is a little unwieldy to type in, so we encode it in a QR code on the SquareTag for people who want to scan it. Every short code on every tag, and hence every QR code on every tag is unique. Each tag is printed to let people know they have the option of scanning or entering the code. For example, here's the current luggage tag we have:

We could certainly change the message, use NFC, or whatever. The goal is to make it easy for humans to be able to discover the cloud associated with the thing and use it from their mobile devices. I'm not an expert in design so, I'd be happy to take whatever suggestions people have.

QR codes present a dilemma for SquareTag. They are, as near as I can tell, the easiest way to do cloud discovery right now, but they arouse significant emotion in many people. I constantly remind people that SquareTag isn't really about the tags. It's about the clouds. SquareTag isn't a QR code play. It's a personal cloud play. We just happen to use QR codes.

Building an App Using the Personal Cloud Application Architecture

Phil Windley // Thu May 16 10:36:00 2013 // forever todo personal+clouds squaretag cloudos

Last week, I released a white paper that introduced the personal cloud application architecture (PCAA). A PCAA is a post-Web 2.0 architecture.

The traditional Web 2.0 application architecture looks like this with the database in the back of a front-end that provides UI and business logic functions:

A PCAA is more modular, allowing the data (and other standard functions like inter-cloud subscriptions and notifications) to be separated from the application like so:

This post shows how to build a PCAA-style application that conforms to the model shown above. The data and other critical functions are stored in the user's personal cloud and the application itself is hosted on a separate Web site.

I have built a simple, JavaScript-based TODO list application. If you play around with it for a minute, you'll see how it works. You can add and delete items. The problem is that there's no persistence layer, so reloading the page reinitializes the application.

In the remainder of this post, I'll show you how to use a personal cloud running CloudOS to add persistence to the TODO application (you can see the code for the TODO application on Github). There are five main changes we have to make:

1. Load and configure the CloudOS.js library
2. Add the capability to link the application to a personal cloud using OAuth
3. Initialize the application when it loads by getting any TODO items from the cloud and displaying them
4. Store new TODO items in the cloud
5. Remove deleted TODO items from the cloud

We'll cover each of these in turn.

Configuration

Configuring the applicaition to use the CloudOS.js library is straightforward. First we add the <script/> tag to load the library.

<script type="text/javascript" 
        src="http://todo.windley.com/js/CloudOS.js"></script>

We need to initialize the library with the application keys and callback URL. We add these lines to the top of the <script/> element with the TODO list code:

CloudOS.appKey = "0AB2F236-B1DE-11E2-B9AC-D788FE2E5C38";
CloudOS.callbackURL = "http://todo.windley.com/linkable.html";

We got the key by registering the TODO app in the Kynetx Developer Kit (KDK) application inside SquareTag. (Instructions for doing this are in the README for the CloudOS.js library.) When we registered the app, we also registered the callback URL. Because of the way this particular OAuth flow works, you have to register your application with every personal cloud hosting provider that you want it to work with. If you use more than one personal cloud hosting service, you would chose the app key based on the provider the user has chosen rather than hardcoding as I've done above.

Linking

The most complex change is modifying the TODO application so it can link to the personal cloud since we have to handle the UI components that allow linking and unlinking the cloud.

The first step is to add the "login" and "logout" buttons to the menu bar (the TODO app uses Twitter Bootstrap):

<ul class="nav pull-right">
  <li class="nav-item nav-auth" style="display:none;">
    <a href="#" id="nav-logout">Logout</a></li>
  <li class="nav-item nav-anon" style="display:none;">
    <a href="#" class="oauth-sqtag-url">Login</a></li>
</ul>

Notice that they're both hidden by default.

Next we need to wire the buttons up. The "login" button gets a standard HTML link since it has to take the user off to their personal cloud for authentication. The "logout" button gets a click handler. The real work in the logout click handler is done by CloudOS.removeSession();, the library call for deleting the session. It also shows the login button and clears the TODO list.

var OAuth_Sqtag_URL = CloudOS.getOAuthURL();
$('a.oauth-sqtag-url').attr('href', OAuth_Sqtag_URL);


$('#nav-logout').click( function() {
    CloudOS.removeSession();
    $('li.nav-auth').hide();
    $('li.nav-anon').show();
    $('div.todo_list').html('');
    return false;
});

Besides wiring up the buttons, we need to do the real work of getting the current session if the app is already linked to a personal cloud and responding to the callback from the personal cloud as part of the OAuth flow.

CloudOS.retrieveSession();

if (CloudOS.authenticatedSession()) {
  $('li.nav-auth').show();
  $('li.nav-anon').hide();
} else {
  $('li.nav-auth').hide();
  $('li.nav-anon').show();
  CloudOS.getOAuthAccessToken(
   CloudOS.retrieveOAuthCode(window.location.search.substring(1)),
   function(json) {
     window.location.href = window.location.href.split('?')[0];
   });
}

If we're already in an authenticated session, then we just show the right button. Otherwise, we have to get an access token from the personal cloud using the code that the OAuth server sends back. Note that we're using a single URL for the entire app, including handling the OAuth callback, so after we get the OAuth access token, we reload the page using the base URL. A more complicated application would have a specific flow for handling the OAuth callback.

Initialization

We initialize the TODO list by showing the current TODO items. CloudOS provides a way to retrieve items in a given namespace. We've chosen the todo namespace for this demonstration. Technically, we shouldn't use a bare namespace (without a unique ID) to store things in the user's PDS unless it is a standard schema. This avoids applications overwriting each other's data. While there is not standard todo schema at present, we anticipate creating one.

Using the CloudOS.PDSList() function, we retrieve everything from the PDS in the todo namespace and loop over them (using the jQuery.each() operator) calling the helper function add_todo_list_item() that was already part of the application's JavaScript:

CloudOS.PDSList ('todo', function(json){
    $.each(json || [], function(id, desc) {
       add_todo_list_item(id, JSON.parse(desc))
    });
});		    

This places each TODO item in the PDS in the list.

Adding

When the user types in a new TODO item and clicks "Add", there is a click handler in the application JavaScript that uses the add_todo_list_item() to put the new item in the list. The following shows the click handler with the new code in red:

$('#add_todo').click( function() {
  var todoDescription = $('#todo_description').val();
  var todo_id = 'todo/'+now();
  // ---- add todo to PDS ---
  CloudOS.PDSAdd ('todo', todo_id, todoDescription, function(){
    console.log("Added " + todo_id + " as " + todoDescription);
  });
  add_todo_list_item(todo_id, todoDescription);
  $('#todo_form')[0].reset();
  return false;
});  

The CloudOS.PDSAdd() function adds new items to the todo namespace in the user's PDS using the application's ID and description as the key and value. We're logging the return for debugging purposes.

Deleting

Deleting items is much the same. There is a click handler for handling delete requests. The only thing that makes it more complicated is that more than one thing can be deleted at a time.

$('#del_todo').click( function() {
  $('input:checked').map(function() {
    var todo_id = $(this).val();
    // ---- del todo from PDS ---
    CloudOS.PDSDelete ('todo', todo_id, function(){
      console.log("Deleted " + todo_id);
    });
    return $(this).parent().parent().remove();
  })
  return false;
});

Note that all of the CloudOS.js functions allow callbacks. This is important because the calls to the CloudOS are made asynchronously. If you need to do something with the data, you have to process it in the callback function which is only called once the asynchronous call has returned. For example, in the initialization above, we want to show the results of the CloudOS.PDSList() function, so we do that in the callback function. For adding and deleting, there's nothing to do, so we merely log the result for debugging purposes.

Going Further

You can try the TODO list application yourself by clicking the login button and signing into SquareTag. Create an account if you need one: they're free.

The TODO application uses only the personal data services (PDS) of CloudOS. PDS is arguably the simplest part of CloudOS. CloudOS also provides notification and cloud-to-cloud subscription services. The Forever application uses this same PCAA architecture but makes use of notifications and subscriptions as well. I encourage you to play with Forever to familiarize yourself with it's operation (go ahead and send an invitation to me at pjw+forever@kynetx.com). You should also read Personal Cloud Application Architecture white paper to understand more details. The code for Forever is available on Github if you'd like to study it.

The TODO list application and Forever both make use of the CloudOS.js library to speak to personal clouds based on CloudOS. You can gain a better understanding of the kinds of functionality available in CloudOS by reading the README file for CloudOS.js. The CloudOS.js library, however only captures the built-in portions of CloudOS (and frankly only those we've needed to date). The CloudOS API is extensible by developers using KRL rulesets.

The PCAA is a variant on the architecture that is being promoted by unhosted web apps and remotestorage. PCAA goes beyond that model by offering a richer API that includes not just storage, but other services that developers might need. For example, Forever makes use of cloud-to-cloud subscriptions and those doesn't need to keep track of or manage connections as well as make notification to the user and between the user and her connections. Without CloudOS, a developers would have to build all of that functionality themselves. For more information, see the PCAA white paper.

Note that while I've built the demo in this post as an unhosted application with no server side at all, that's not required. Hybrid models that store application data in a database and user data in a personal cloud also work, as do mobile applications.

Using Products to Build Customer Relationships

Phil Windley // Mon May 13 10:52:00 2013 // crm vrm crm+vrm squaretag

I was the Co-Founder and CTO of iMall.com back in the '90s. iMall was an early ecommerce tools vendor. At one point we had over 50,000 merchants using our tools to sell online. We envisioned that ecommerce would change the nature of how things were bought and sold. To some extent it has, but by and large, ecommerce sites, from the smallest to the biggest are just glorified online catalogs not significantly different from their more mundane mail-order catalog cousins. I've always thought the Internet ought to allow us to do better—to really change how merchants, companies and service organizations interact and relate to people.

Our vision for SquareTag is just that: helping people and companies have better (i.e. less dysfunctional) relationships. We believe that products are natural connecting points between companies and their customers. Because SquareTag makes those products smart and gives them an online presence, SquareTag provides a powerful tool for building vendor-customer relationships.

When I speak in my blog or on stage about the Internet of My Things, I'm highlighting the natural and powerful feelings people have about their stuff. As Doc Searls says in Chapter 21 of The Intention Economy, "possession is 9/10ths of the three-year old". Our connections with our things are primitive and deep. We spend much of our time and resources acquiring, using, managing, and disposing of things.

Because of the strong feelings people have about them, products are a natural connecting point between manufacturers, retailers, service companies, and the customer. SquareTag is designed to deepen the connection between people and things by making the interactions richer. With SquareTag, any thing becomes a programming platform. Products become more useful, more helpful with the addition of SquareTag. As an example, SquareTag gives almost anything an online social profile.

Relationships, Not Just Data

Companies need new and better ways to relate to customers. An IBM study of over 1700 CMOs in 2012 (registration required) found that marketing organizations were good at using digital marketing tools in the transaction-oriented segments of the customer life cycle (segment and buy in the diagram below) but less adept at the more relationship-oriented segments (everything else).

Moreover, outperforming organizations spent over 50% more on relationship-oriented activities than underperforming organizations. In particular, they spent 65% more in the bond and advocate phase. Good companies have discovered that investing in building relationships with customers pays dividends.

Many companies confuse "having information" about their customers with having a relationship. That might constitute customer intelligence, but it's not a relationship. Relationships are built on common interests and an exchange of value. Both parties need to see that value or it's not a relationship. People are more likely to resent the fact that you know things about them outside of a relationship.

How SquareTag Builds Relationships

I like to use this example to describe how SquareTag enables better relationships between companies and people through the product:

Say Allison has just bought a new Specialized bike. If that bike is equipped with SquareTag, it could come from the factory with a pre-established relationship to Specialized. When Allison claims the bike in her personal inventory (normally by scanning the tag), she becomes the bike's "owner" and establishes the pre-eminent relationship with her bicycle. The bike's cloud (established by Specialized at the time the bike is manufactured) comes pre-populated with a lot of information about the bike including it's component mix.

Inside her personal inventory, Allison sees the bike and can click through to its profile to see specific information about her bike as well as notifications, reminders, offers, and other information. She can record information there—either manually or automatically. Using the bike's profile, she can ask questions of Specialized customer support, access customized FAQ lists, and even schedule maintenance appointments with the bike shop.

The bike shop that sold the bike to Allison also created a relationship with the bike. Using that relationship they record any initial assembly information and modifications. Later, they can store maintenance records right on the bike for Allison to see or augment as necessary.

Allison introduced the bike to her Garmin's personal cloud and the bike and bike computer can share information about rides. As a result of that relationship, the bike knows where and how far it's been ridden. This data might be merely logged or used to give Allison reminders about needed maintenance depending on what apps she's installed on the bike's cloud.

Allison happens to be a student and allows the campus police to create a relationship with the bicycle. Through that relationship, they can help her recover her bicycle if it gets stolen or message her (without revealing her personal information) if they find her bike or need her to move it.

Because SquareTag is architected as a system of decentralized clouds, each of these relationships is unique and can cause specific interaction patterns with Allison. For example, after a few years, Allison decides it's time to replace the chain on her bike. Rather than search the Web, she asks her bike (or to be more precise, it's cloud) for recommendations. She gets back purchase options from the manufacturer, the repair shop, and others of the exact chain she needs. The bike also knows about accessories Allison might like, shares recalls and warranties with her, and provides service reminders.

The SquareTag Value Proposition

The relationships that Allison built through her bike in the previous section have several important properties:

Personal and Directed—each relationship was directed not only at Allison, but made in the context of a common interest: the bike. Because Allison values her bike, she will also value any help in making it more useful or enjoyable. The relationship is personal without being threatening because of that context.

Privacy-Enhancing—SquareTag's unique architecture assures customers that their privacy is protected and increases personalization at the same time. We call this "privacy by design".

Continuously Interactive—the relationship allows Specialized and the bike shop to interact with Allison throughout the customer lifecycle, whether she's using the bike, getting it serviced, buying accessories, or just has questions.

Extensible—SquareTag is a programmable platform and so the nature of the relationship and the amenities it provides can be enhanced and changed over time as appropriate.

Flexible—SquareTag can provide different interactions and features on a per-relationship and per-product basis. The experience that Specialized has interacting with Allison through SquareTag is different from that of the bike shop. Each product can present a different experience on each channel.

Compelling—by including SquareTag with their products, companies can drive adoption and the creation of valuable customer relationships. SquareTag provides real value to customers and so they adopt it. Product registration is immediate and automatic.

Current—SquareTag links all kinds of products to the user's personal cloud. Allison's cloud doesn't just contain her bike, but lots of other products and services that she uses. This creates network effects. Apps in the bike and other product clouds use Allison's cloud to notify her of important events (e.g. "time to check your tires"). These properties provide an incentive for Allison to keep her contact information current and to maintain the relationship.

Transferable—suppose Allison sells her bike, she can transfer the bike's cloud to the new owner with no loss of data and without revealing or losing control of her own data. For high value items that might change hands several times during their lifetime, companies can engage second-hand owners in the same way they engage the original buyer.

These properties combine to create relationships that are genuine, varied, and relevant. Both Allison and the companies connected to her bike see value from the connections that SquareTag provides and thus use and maintain them.

Case Study: University of Utah

The University of Utah police department approached Kynetx with a problem. Bikes that were lost or stolen and later recovered carried no way for the police to return them to their owner. The department didn't want to run a registration program.

Using SquareTag, Kynetx created a program to help. We provide SquareTags to the University police that have a pre-established relationship between the unclaimed bike cloud and the police department. The department holds "bike rodeos" where they give out and configure tags. Every configured tag creates a chance to win a bike lock. By claiming the tag, the owner creates a personal cloud and establishes a direct relationship with the bike.

Once the tag is claimed, there are three distinct behaviors depending on who is interacting with the bike:

1. When the students scans the tag or otherwise interacts with the bike's cloud, they see the various configuration screens. They usually do this once unless the bike is lost or stolen and they want to mark the bike as "missing."
2. When a member of the police department scans the tag or enters its unique code into their computer, they see a message box that allows them to contact the student who owns the bike. They can do this without the student revealing private data.
3. When anyone else scans the tag they get an innocuous message.

This system met the University's needs as well as providing a valuable service to owners by keeping their bicycle safe.

Beyond CRM

Using SquareTag companies can engage in a new kind of customer relationship management that does more than store contact information and interaction history. SquareTag provides a way to establish genuine relationships that provide continuous interaction throughout the customer life-cycle. This changes "relationship management" into "relating."

SquareTag is open for business and ready to use. We're anxious to find new ways to use SquareTag to help businesses create better relationships with their customers. Let us know how we can help.

CloudOS Will Be Open Source

Phil Windley // Mon May 13 09:25:00 2013 // open+source kynetx krl cloudos

If you've been reading my blog for the past few years, you know I've been a big proponent of the personal cloud vision as the future of online computing. I don't just see it as minor improvement, but as a significant shift in the way the 'Net operates.

All of the work we've been doing uses a platform we call CloudOS. This screencast, The Cloud Needs an Operating System explains why we think CloudOS is important. Operating systems give developers leverage and the give people control. Both are critical in making the most of the Internet.

SquareTag is a product based on personal clouds. SquareTag is built on the CloudOS. Personal clouds give rise to a new way of building Internet applications. This model also uses CloudOS. CloudOS runs on top of the Kinetic Rule Engine, an open source rules engine with a personal twist.

Today we're happy to announce that CloudOS will be open source as well. There are still some things we need to get right in the source before we release it (small things like redacting keys). When we do it will be under the GPL license.

We're very excited about this move because we think CloudOS has great potential. But to reach that potential it has to attract developers. We feel that opening the source for CloudOS will help us achieve that goal.

Forever Demo Slides

Phil Windley // Wed May 8 14:48:00 2013 // forever squaretag slides demo

On Monday, I released a new white paper, Introducing Forever: Personal Clouds Application Architectures about a new post-Web 2.0 programming model that uses personal clouds to store user data from an application. Last week at OpenWest and this week I also gave talks that not only included a demo of Forever, but also showed how to use CloudOS to build a JavaScript TODO list. I'll have a blog post about that a little later, but for now, I wanted to share my slides from the talk.

Imagining Trillion Node Networks

Phil Windley // Wed May 8 11:31:00 2013 // personal+cloud trillion+nodes pico forever squaretag

Last week I gave the opening keynote at OpenWest, the Intermountain West's largest open source conference. In fact, it may be the largest open source conference anywhere outside of OSCON. There were almost 900 people registered before it was all over. There were many interesting sessions and lots of tracks. Look for it next May.

My talk was recorded and I wanted to post the video and the slides, so here you go:

Introducing Forever and Personal Cloud Application Architectures

Phil Windley // Mon May 6 09:32:00 2013 // forever unhosted personal+cloud javascript krl kynetx squaretag

For a more detailed look at the ideas in the blog post, see my recent white paper in the Live Web Series called Introducing Forever: Personal Cloud Application Architectures.

Kynetx has built an application called Forever to demonstrate application architectures for personal clouds.

Forever is an evergreen address book that uses personal clouds based on the Kynetx CloudOS. The profile data in the personal cloud provides the contact information. The connections between clouds provide the friend relationships that Forever displays. The following diagram shows how Forever uses personal clouds:

If Allison needs Vicky's contact information, Forever doesn't have it. Allison's cloud doesn't even have it. Only Vicky's cloud stores her profile information. Forever asks Allison's cloud to retrieve it and Allison's cloud gets it from Vicky's personal cloud. Forever is like DNS for people because each person is responsible for their maintaining their own profile information and it is retrieved as needed, just in time.

Personal Cloud Application Architectures

Forever is built using a unique application architecture that keeps people's data in their personal cloud, under their control.

Ever since the Web got CGI and cookies, web apps have used a programming model like the one shown below. In the traditional model, the application presents a Web interface to application data stored and managed in concert with the application.

The traditional Web application model has given us a wealth of exciting and useful online applications. While the details of how the application is structured differ greatly from app to app, the basic architecture wherein the application mediates access to data has not changed.

But the traditional architecture shown above has significant limitations. Storing data for users in the app's datastore creates "data silos" where the app has exclusive access to the data. This results in inconveniences to the user:

• users must fill out profile and other standard information for every application they use.
• applications that die take the user's data with them.
• more significantly, data silos prevent network effects where one app's data exhaust becomes the input for another app.
• the application necessarily has access to all of the user data it mediates, creating privacy concerns.

Apps that use personal clouds, in contrast use an architecture where the data is separated from the Web application. This is a model similar to that of Unhosted apps. The picture below shows this separation.

Apps based on a personal cloud architecture free developers from hosting and managing the data while giving the user more choice and greater control. Personal cloud app architectures are enabled by modern browser support for HTML5, CSS, and JavaScript. The browser receives the app's source code over HTTP and connects to the data using an API. Personal cloud app architecture separates the app hosting from the data hosting making the entire system more modular and more loosely coupled.

Applications built on personal clouds, on the other hand are easier to build and deploy because they don't have to account for user data—the personal cloud does that. Also, because personal cloud application architectures support greater modularity, they are more flexible and create network effects for data and other servers (like inter-cloud subscriptions).

Learning More and Helping

To introduce the idea of personal cloud application architecture, I've written a white paper that describes Forever and it's architecture in some detail.

Forever links to personal clouds that implement the service API of the Kynetx CloudOS. The easiest way to get such a personal cloud is to sign up for SquareTag. Of course, since CloudOS and the underlying KRE platform are open source, you could also run your own—either by installing it directly or using a pre-built virtual machine image. We hope that there will soon be other personal cloud hosting providers that are compatible with CloudOS.

We need developers to use the personal cloud application architecture and help drive our development efforts on the platform side. That is, we need some customers! We're looking for a few hardy developers to work with what is right now, an early alpha architecture (although the underlying platform is quite mature). If you have an idea for a application that could use this architecture, we'd love to connect and help you get started.

Personal Clouds and the Future of the Web

Phil Windley // Fri Apr 26 13:47:00 2013 // kynetx krl cloudos personal+clouds open+source

Bastian Allgeier paints a picture of a near-future Internet in The Future Of The Web—A Draft that is clearly in line with the vision of personal clouds that I and others have been espousing. I'm seeing more and more of this: people from all over realizing the the future of the Internet doesn't have to—indeed shouldn't—look like the world that Web 2.0 has given us.

The heart of Bastion's article is a scenario in the near future that posits a decentralized app infrastructure that provides most of the features and functionality that Web 2.0 provides without the silos. I encourage you to follow the link and read it all.

Of course, I hope CloudOS will be a player in that world. We're busy building the infrastructure and initial apps that will make that world a reality. We'll be demoing some of them at IIW on May 7—9.

But whether my ideas win out or not, I'm encouraged by the explosion of views that support the basic premise that we have to build decentralized, protocol-mediated systems to maximize individual freedom.

Bastian finishes with a call to developers that echoes my own Build the World You Want to Live In:

It might be just my dream and an illusion. But I really believe that it's up to us developers, engineers and designers to decide what's up next. We are in control. We just need to implement it and seize that chance. We are not doomed to be slaves of a centralized web forever just because it's popular right now.

IMAP as the Proto Personal Cloud

Phil Windley // Mon Apr 15 14:25:00 2013 // personal+clouds imap email kynetx unhosted squaretag cloudos

When I talk about personal clouds, people sometimes don't quite get the model. Today Steve Fulling made a connection between what we're doing with personal clouds and IMAP. If you've ever used an email client to access your email on a server, then you've probably used IMAP. IMAP implements a proto personal cloud because it has many of the features we want in a personal cloud, but they're limited to just email. Here are a few of them:

• The user picks and controls the email server—With an IMAP email client, your have a choice of multiple email providers. You can even run your own email server if you like.
• Data is stored in the cloud—The mail client needn't store any user data beyond account information. While many email clients store email data locally for performance reasons, the real data is "in the cloud."
• Mail client behavior is the same regardless of what IMAP server it connects to—As long as the mail client is talking to a mail server that speaks the IMAP protocol, it can provide the same functionality.
• The client is fungible—I can pick my mail client on the basis of the features it provides without changing where I receive email.
• I can use multiple clients at the same time—I can use one email client at home and a different email client at work and still see a single, consistent view of my email. I can even access my mail from a Web client if I don't have my computer handy.

If we add SMTP (and a dash of DNS) to the mix, we get additional benefits:

• I can send you email without knowing anything but your email address.—none of the details about how you receive and process email are relevant to me. I simple send email to your address.
• Mail servers can talk to each other across ownership boundaries—I can use GMail, you can use Yahoo! mail and the mail still gets delivered.
• I can change email providers easily.—I receive email windley.org even though I use GMail. I used to run my own server. If GMail went away, I could start running my own server again. And no one else needs to know.

In short, email was designed with the architecture of the Internet in mind. Email is decentralized and protocol-mediated. Email is open—not necessarily open-source—fbut open in that anyone can build clients and servers that speak IMAP and SMTP. As a result, email maximizes freedom and control for the user and minimizes the chance of disruption. The features and benefits that email provides are exactly the same as those we want for personal clouds. Designed right, any application built on a personal cloud would provide similar functionality.

Web 2.0 has given us a model that is exactly the opposite of email. The model encourages user data to be stored in separate silos. You cannot easily migrate from one service provider to another. And when a service provider goes away, you are abandoned and marooned. You are not in control. Of course, it doesn't help that this is all in the service provider's best interest. They make money from the fact that the predominant model for building online applications leaves their users powerless.

There's no technical reason why the functionality of Facebook, Flickr, LinkedIn, Twitter and a thousand other Web 2.0 applications couldn't be provided by a decentralized, protocol-mediated network of providers and compatible application clients. In fact, they would be more powerful and more fit for purpose if it were. Personal clouds provide the same benefits that IMAP and SMTP do, but in a way that any application can take advantage of.

I believe that Web 2.0 is a temporary cul-de-sac. We will soon find our way out of it and again start building applications that are true to the architecture of the Internet. A number of projects are already moving that direction. Check out unhosted web apps, remotestorage, ownCloud, Cloudstore, and Respect Network's Zephyr. Our own SquareTag is built on personal cloud technology (the Kynetx CloudOS). When you sign up for SquareTag, you're creating a personal cloud. We'll be showing off how SquareTag and Kynetx CloudOS can be used for building personal cloud applications at Open West and IIW in May.

Pot Holes and Picos

Phil Windley // Tue Apr 9 11:09:00 2013 // pico krl kynetx

Imagine a pot hole in the street outside your house. Imagine that you have Google Glass and that as you drive into your neighborhood, a small bubble appears above the pot hole informing you that it was reported to the city last Thursday and a crew is scheduled to come out and patch it next Monday. That's a vision of the world that we've long been promised by science fiction authors and it's rapidly becoming a reality.

Now imagine what kind of engineering goes into making that scenario real. First, the pot hole has to have a unique identity in time and space (i.e. it's a Spime). Further, we need a way for information to be posted and read about the pot hole. Maybe there are different kinds of information so that you, as someone who lives in the neighborhood, sees the schedule for fixing it, while the crews that come out to fix it will see special instructions or notices. A road engineer might see the historical pot holes in the street to start envisioning the overall state of the road and how often it's been repaired. Someone will want a report of all the pot holes and their status. The pot hole is in a particular street in a particular neighborhood. The road has a history of use and repair. All these relationships are recorded. It's like Facebook for pot holes.

You might imagine that all we need is for the city to put an API on their pot hole database and wait for a few programmers to get busy building a new pot hole reporting business. But I think the problem and opportunity are bigger than that. The problem with seeing the world as an unstructured collection of APIs is that all the structure has to be layered on after the fact in ad hoc ways.

A better way to build this system of relationships between pot holes, streets, people in the neighborhood, drivers, repair crews, the city, and so on is to build a model of the real world—what Galertner calls a "mirror world." The model is as detailed as it needs to be for your needs and is extensible so that it's easy to add pot holes to the street model when the need for modeling pot holes comes along.

I believe the best way to build this model is with decentralized networks of what I call persistent compute objects, or picos. A pico has a unique identity, can store information, and run programs. And picos can have networked relationships with other picos. From these small means, one can build a great model of the city, it's streets, and the pot holes that invariably inhabit them. Picos allow this model to be shared and used by many people and organizations for many purposes.

The pico that represents our pot hole gets created when the pot hole is first noticed. It need never go away. Even after the pot hole has been fixed, its pico gets updated as "fixed" but the pico and its relationship to the street, the person who reported it, and the crew that fixed it remains, ready to be used. Want to use your Google Glass to see a time lapse of all the pot holes that have come and gone on your street? A road engineer might. In a mirror world built with picos, all the data is available.

The pot hole is an example of a connected thing that is sometimes ignored in favor of sexier, active, connected devices. When Cisco talks about the Internet of Things having 50 billion devices by 2020, they're talking about active devices like your phone or your car. When we add things like pot holes to the mix, there will be orders of magnitude more than 50 billion things on the Internet of Things. There will be trillions.

SquareTag is an early attempt to start understanding what such models look like and how they work. Using SquareTag you can create a personal inventory of the things you care about, store data about them, and run programs on their behalf. After all, if we're going to start modeling the world, we ought to start with the things we care most about. SquareTag is built on picos. Every thing in your personal inventory has it's own virtual machine and runs it's own programs.

This may seem like overkill at first, but there are numerous modeling activities that become easier when we give everything it's own identity and the ability to create relationships with anything or anyone else. For example, my wife and I both own the F-150 truck I drive. Sometimes she drives it. We both want a relationship with it. And I want the service shop I use to be able to record maintenance in the truck's pico. When I sell the truck, I need to transfer the truck's pico—and it's attendant data—to the new owner. And so on. This is much easier to do when the truck stores its own data, runs its own programs, and has it's own relationships.

As you walk around, try to imagine everything—and I mean everything—being on the Internet of Everything. Think about everything you own or use being in the Internet of My Things. Imagine what would happen if literally everything were connected and had an online presence. The ramifications are stunning.