The apps talk to the world in a different way that normal native apps would. All communication goes through a Cap'n Proto RPC connection that is handed off to the app at startup. An executable is provided that knows how to bridge this to HTTP, making it relatively easy to port in existing apps, but the real power of the platform will eventually be exposed through that RPC connection. Inter-app communication will be through Cap'n Proto RPC, which is capability-based, allowing apps to expose APIs to each other and letting the user easily and security control which apps can talk to which other apps. Compare to Docker, where you can open ports, but don't have fine-grained control over capabilities. (Sorry, this really deserves a lot more explanation...)
Also, the idea is that you don't isolate apps, you isolate individual objects. So for Etherpad, each document is in a separate sandbox. This means that the platform can implement sharing for you, by doing it at the instance level. It also means that if I share a document with you, I don't have to worry that a security bug in the app will allow you to get access to all my other documents. Only a platform bug could allow that.
Finally, there's a nice web-based UI for installing and managing apps, so even non-sysadmins can actually run their own server.
Gotcha, thanks for clarifying. This is actually pretty neat. I think Docker really missed the mark with their "links", its interesting to see more full-fledged efforts on this front (see also: CoreOS's "software defined localhost").
A "capability" is just an object reference, like a pointer in your favorite programming language, except that a capability not only identifies the object it points to, but also confers permission to use the object. So if you receive a capability, you can use it. If you don't have the capability, you can't use it.
Cap'n Proto is a capability-based RPC system in that capabilities are a first-class type. That is, any message can contain capabilities pointing to remote objects, and thus the recipient gains access to those objects upon receipt of the message.
In terms of Sandstorm, an app will be able to say "Hey platform, I have an object here that implements this Cap'n Proto interface 'Foo'. Here's a capability (pointer) to it. The user may redistribute this capability at their discretion." Later on, another app may say "Hey platform, I need a capability that implements interface 'Foo'." Then, the platform presents the user with a UI listing all of their matching capabilities and asking them which one to use.
The brilliant bit here is that when the user makes a choice, the platform then hands that capability to the app, and all of the access control _just works_. No need for an OAuth dance, no need to ask the user "Do you want to permit this?" -- obviously they do, otherwise they wouldn't have made the choice. From the point of view of both apps and the user, the whole interaction is trivial. And, critically, the permissions transferred were only for the specific object the user chose, as opposed to broad permissions for the second app to manipulate the first. No "I need access to your contact list, so that I can display a picker for you to choose which friends to invite", instead it's just "Please use the system picker to choose which friends to invite, and I'll never see anyone you didn't select in the first place."
Creative marketing though, "Personal Cloud Platform".