Facebook for My Stuff

Phil Windley // Thu Jun 13 21:41:00 2013 // facebook iot kynetx krl squaretag

In a blog post from 2011, I transcribed a quote from a keynote by Marc Benioff where he says:

"The car needs to become your friend. How does the car speak to me? How does the car integrate with the dealership and the factory? How does the car help me get to the service station? ... I want a relationship with the car in the same way I have a relationship with my friends. ... The car is going to become social. All our products are going to become social." (emphasis mine)

I went on to describe what I thought it meant to create a "Facebook of things" where products and services could "be social."

Two years on, we've made tremendous progress on that vision. We've built a social product platform that we call SquareTag. Over the last four months, the feedback we've gotten from users has given us a better idea of what it takes to make SquareTag useful and interesting. Our vision for SquareTag is a tool that helps people enjoy their things more and reduces the headache of ownership.

For a thing to be social, it needs relationships. Social products don't just have relationships with their owner. They might, for example, have relationships with other, related things or people. One of the primary relationships that my things have is with the company or person who designed and made them. For many things, another key relationship is with the service agents who maintain them. Manufacturers—brands—and service agents can do a lot to help me reduce the effort and expense of owning things and get more satisfaction from the experience. And that, in turn, makes it easier for me to buy and own more.

Even though both the manufacturer and I both have a relationship with something, our viewpoints are very different: a company side and a people side. As the owner, I have the primary relationship, but I want the manufacturer to be able to share useful things like warranty and recall notices, replacement parts, enhancements, new releases, related articles, and so on. And I want to be able to ask questions, find information, look for service agents, buy replacement parts and accessories, share experiences with my friends, offer the thing for sale and so on.

When I talk about the people side and the company side, I really mean just that. Any product is a place where companies and people come together: a common interest upon which they can establish a relationship. I use the following picture in discussions about SquareTag to illustrate that point:

If you can imagine a bike, or anything else, having it's own place online, the customer and the company both have a different, but connected view of that product. We think that for companies it looks much like customer relationship management (CRM), which is why we've built a SalesForce.com integration to show that side off.

The owner's side looks and feels like a Facebook wall where messaging and other interactions happen in the context of the thing itself. Things have profiles that they share with other like things. The profile contains pictures, product Web pages, manuals, how to videos, and other useful information. But the product profile is individual—made for a single instance of the product. It also contains information specific to that thing such as custom configurations, serial numbers, purchase history, maintenance history, and relationships to anyone or anything that is relevant. One of the most interesting thing that the product profile holds is notifications, reminders, and other interactions with the things and people it has relationships with.

SquareTag is, as I said, a social product platform, designed to support a multitude of uses. While it remains in beta and we continue to tweak it to better suit the vision we have for it, SquareTag is available now and free to use. Sign up and let us know what you'd like to do with it.

Using Dropbox and OAuth 1.0a in KRL

Phil Windley // Thu May 30 11:26:00 2013 // krl dropbox kynetx oauth cookbook

I've added a new entry to the KRL cookbook that shows how to access the Dropbox API, which is protected with OAuth 1.0a, from CloudOS applications. There's lots of KRL goodness there. My primary reason for doing this is to show CloudOS developers how to deal with OAuth protected APIs from within CloudOS applications. While this is for OAuth 1.0a, OAuth 2 is considerably simpler and the techniques in this recipe will be apropos there as well.

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.