Summary
Want to use CloudOS to build your Web application but don't want to learn KRL? I've got a deal for you.
Last week I wrote about the CloudOS programming model and how we could modify KRE to support other languages besides KRL, the rule language in which CloudOS is written. After more thought and some discussions with others (including Sam Curren, Joe Johnson, and Drummond Reed), I realized we don't even need to go as far as I proposed.
The problem is that the operating system metaphor is so powerful that by calling what we're building the CloudOS and showing off the CloudOS dashboard with it's desktop metaphor, I've locked everyone's thinking—including my own—into a mode of thinking about the CloudOS that is too restrictive.
In fact, the CloudOS is a set of APIs for services that are exposed as URLs and accept events that look like Webhooks. The dashboard is ancillary to that vision. In fact, the dashboard is just another service—one that the developer could ignore.
The bottom line is this: suppose you want to write a Python program that uses the CloudOS for the things it's really good at: storing personal information, creating relationships between the user and others and sending notifications to the user via email or SMS. You can do that. The only thing we're missing is the ability for users of your Python app to use their CloudOS credentials to authorize your app to access their cloud. This is easily remedied by adding OAuth to CloudOS.
The developer gains because they can access the full range of services from the CloudOS. Many apps might not even need a database. This would be perfect for Unhosted applications. What's more, as new services are added to CloudOS, all of these are available to the developer's application. For example, we're contemplating adding address book, calendar, and file system services to this year's roadmap.
The user gains because their data is not stored in the silo of yet another application, rather it's stored in their personal cloud. Other apps they use can that data in a permissioned way. For example, if the user updates her email address or phone number, every app would have access to that change without the user having to update her profile in every Web application she uses. Users would still be able to manage apps, data, and connections via their CloudOS dashboard, but it would not be the primary lens through which they are forced to interact with their personal cloud. That would apps spread around the Web.
What do you give up? The developer gives up controlling the data. But that's the whole idea. The user gives up some of the privacy-by-design benefits that exist when the apps run inside KRE. They would get, instead, privacy-by-agreement since we'd require developers who use the CloudOS to respect user privacy requirements and enforce those, as well as we can, by policy inside the system.
Ideally we'd provide client libraries for JavaScript, Python, what have you that would make raising events, storing data, and so on easier. But none of that is necessary to prove out this idea. I plan over the next few weeks to create a stand-alone Web application (probably written in JavaScript since that's what all the cool kids are doing these days) that uses CloudOS as it's foundation. Stand by for more details.