Sandstorm Personal Cloud Platform
sandstorm.io
sandstorm.io
Docker seems like a great step: give people a docker container image, and they can spin it up and hit a web interface to configure it with almost no extra knowledge needed.
Sandstorm seems like a great step too: now you can imagine a network of applications/plugins that know how to talk to each other, but all run on the user's server. And it can be made very friendly to non-techies. Nice work.
Docker is awesome for what it does (and I'm extremely happy that they are forcing the Linux containerization stuff to improve, because Sandstorm uses the same features), but to really make per-user (or, better yet, per-document) containerization work, we need to change the programming model a bit. Lots of stuff that every app does itself currently (authentication, sharing, OAuth) really needs to be pushed down into the platform, which is what Sandstorm is doing. And, of course, it needs a UI friendly enough for non-programmers.
In short; It's a platform that started after Eben Moglen's talk "Freedom in the Cloud" - to establish a platform for running a decentralized network of Free Software social/personal services. It happened at the same time that so called "plug computers" (ie. small, somewhat cheap and decent System-on-Chip computers (think Raspberry Pi but with casing)).
The thought was and is (but I'm not all too up to date on the project) was to offer software and hardware in a easy package for whoever to setup easily and get started with.
This makes it easy for developers to distribute cloud apps without having to manage users, billing, hosting, security or any of that SaaS boilerplate. Just code the app and distribute it for your users. This changes everything.
Of course, the users probably won't pay and you can't use ads, so there may not be much business here.
No ads? Awesome!
No incentive other than 'build something cool?' Awesome!
No defective by design? Awesome!
Who cares about business? It's a means to an end, nothing more. If we can get the end without the business, the paperwork, the ads, the politics - i say good riddance.
(Unless I'm misunderstanding the model...?)
Let's face it, Linux should not try to win the battle for the desktop. Not only it is already lost, its is pretty much irrelevant. I feel that instead of producing another fork of desktop office package, efforts of open source contributors would be much better spent on creating Open Source counterpart of Google Apps.
I do a lot of things with my linux-based NAS already: it is backup server, git server, hub for online and offsite backup, media storage, and much more. But I wish more apps would be easily available for an easy installation, without fiddling with database settings and ruby versions. I want my own pinboard.in, I want my own RSS reader, I want my own mint.com installable on my NAS with few clicks. I would definitely pay for good commercial apps too! I just want them to run on my server with the data I control.
But if I could just install an e-mail client on Sandstorm with a couple clicks... I'd totally do that.
Brian K. Vaughan's The Private Eye [1] was on my mind when I was thinking about an individual being entirely in control of all their data without compromising on functionality or usability.
I concur and this is the kind of thing I'm working on but we're looking at the components from the ground up. Given how the cloud works today and the coming wave of connected devices (aka internet of things), it's worth re-evaluating the assumptions we've made and looking for ways to improve (even if this takes us somewhere radical). There's a post with some background [1] but in essence we're starting out by creating the basic building blocks to deal with deploying applications, managing identity and connectivity as well as co-ordinating sync/history.
That is kind of a narrow view in regards to today's architectures.
I think another way to look at is once you have a nice backend with a good API you can then build:
* A desktop app
* A web-page
* A command line utility
* An SDK in a number of languages or frameworks.
How pluggable any of those are is another axis. You can make it monolithic or make it so you can plug in functionality. Plugins are harder than it seems to get right, and so is a good stable API.
Think about Android, are some of the native apps that just deliver HTTP REST-ful requests back and forth really a Desktop app or closer to a single page app. Maybe there is nothing to win on the Desktop anymore.
Either way, cool idea! I definitely see web apps moving in this direction.
Sandstorm does use the same underlying kernel features as Docker, so any advances there should benefit both. Above that, I'm not actually sure if trying to share userspace tools would benefit either project, given the very different design decisions. It might just become a tug-of-war, like Chrome and Safari sharing Webkit while going in different directions with their sandboxing model.
I'd rather skip the hyperbole and just get to the value proposition.
Also since when does "billions of people use it" mean something isn't broken? Lots of ubiquitous things are very, very dysfunctional.
Anyways this all seems very pie-in-the-sky but Kenton Varda is an incredible person. I'm very interested.
The idea here is that for many people, maintaining a Linux instance on which to run Sandstorm just isn't feasible. It's too expensive (you don't really need a whole VM just for yourself), requires sysadmin expertise, and is time-consuming. So for those people who don't want to do all that, the next-best option seems to be to get a cheap managed instance from someone else -- maybe the Sandstorm group, or maybe a friend.
I don't want Sandstorm to be something that only developers and Linux sysadmins are able to use, even if the early adopters are likely to be mostly from these groups.
Another option might be to sell physical devices pre-loaded with Sandstorm, although speaking for myself I really do want my cloud services to be in "The Cloud", not on my home network.
In any case, I want to make it as easy as possible to transition from a managed instance to a self-run instance, so if you ever decide you don't trust your host anymore (whether that host is us or someone else), you can easily leave. That's definitely not something you can do with most web apps today, even with Google Takeout and whatnot, because they don't let you transfer the software that makes the data useful.
Bottom line, the pieces needed to run your own personal instance will always remain open source. But not everyone actually wants to do that.
Also, a VPS is only $5/month so sharing one among several users seems like a premature optimization.
Ultimately, as a Linux-based project, Sandstorm cannot really save you from the complication of installing Linux itself, or keeping it running and updated, or making backups. It just saves you the complication of installing and configuring individual apps. So the "managed instances" service is appropriate for people who don't even want to manage a Linux instance at all.
To imagine the Cadillac product: double as a WiFi router and put a small cellphone screen on the thing. The screen gets rid of the admin setup bootstrapping pain - the screen is default admin user. Making it a wifi router lets you consolidate your initial configuration into just two questions: a name for the network and a password. Name becomes ssid, shared login, dyndns name, etc. Password becomes remote shared login password, WiFi password, etc. Admin panel can create other admin or regular users, also having a screen right on the device would be convenient for backups - just plug in the detachable storage and the backup wizard begins.
I've given this way too much thought. I just want a zero-config device.
[1]: https://developer.mozilla.org/docs/HTML/Using_the_applicatio...
Yes, you're right that it's very far from perfect without browser support for decrypting files, but it reduces the amount of files on the server you need to monitor to one (or a couple) and it would make targeting someone harder (by using appcache). I'm not a security researcher, though.
Currently, there are no permissions; apps are totally isolated. Soon, it will become possible to grant permissions to apps through a powerbox interface. This is a bit different from -- but IMO superior to -- the Chrome Extension and Android models. http://plash.beasts.org/powerbox.html http://en.wikipedia.org/wiki/Capability-based_security
> how are apps updated?
All packages are cryptographically signed. Two packages signed with the same key represent versions of the same app. You specify the version number in the app manifest. When a user installs an updated package, the platform offers to replace the old package.
Automatic/push updates will be implemented eventually.
> does it use zerovm?
No, Sandstorm has a custom sandbox implemented on the same Linux kernel features underlying Docker. This means that existing Linux binaries can run in the Sandstorm sandbox. In fact, many of the existing apps were created by just copying over binaries from my local Linux installation.
Currently the sandbox is mostly based on chroot() and unshare(). In the future we'll lock it down more with seccomp-bpf syscall filtering.
> how are unresponsive apps managed?
Currently, an app server is killed off after a few minutes of the app not being open in any users' browsers. The server starts back up the next time you open the app.
Perhaps it also makes sense to stick in a "reset" button for apps that are wedged. That would be pretty easy to implement, but hasn't been needed yet. (You can also just "killall sandstorm-supervisor" if you have shell access to the box, then refresh the app. It should come back up gracefully.)
> can apps use protocols like websocket, webrtc?
WebSocket is implemented now. WebRTC is not, but certainly could be some day.
> how are data backed up/restored?
Nothing has been implemented yet on that front, but eventually it will be possible to download a tarball of a particular app (or all your apps) easily, and then re-upload it to the same or a different host later.
Of course, hosts should also implement a backup solution so that users don't have to worry about data security. Any existing solution that just dumps the hard drive should work fine with the current Sandstorm implementation (just back up /var/sandstorm).
Yes please don't emulate the Chrome/Android permissions functionality (particularly Android).
Android apps often ask for broad permissions upfront just to do a one-off thing, like inviting your friends to use the app. Then they get to keep that permission for as long as the app is installed.
And it's "take it or leave it". If you're not happy you get to stop using the app/service, or you just have to bite your tongue and install anyways. Ugh.
I can't wait to see where this goes, and if the above is indeed possible. That would be truly awesome.
What about "big" users? Scaling is not just for multi-tenant systems.
But a lot of what users need from day to day fits quite well.
Also, Sandstorm does potentially have an answer for things that do really need multiple machines: you can have multiple instances of the app that talk to each other through Cap'n Proto RPC. But obviously, at that point, it's not so much simpler than the status quo.
If you have a Sandstorm server, you can install your own instance of this game by grabbing "Duoludo" from the Sandstorm "app store": http://sandstorm.io/apps
Can you give a brief example of a (real or imaginary) app that would run on Sandstorm and how I would benefit from the Sandstorm model in this case? I'm a programmer but I'd appreciate a "layman's terms" explanation if possible.
I was trying to wrap my head around how to create something like this with CoreOS, but found myself lacking the know-how to turn it into more than a half-baked toy/concept for myself.
Looking forward to trying this out and learning something from the repo.
There have been attempts to build federated social networks over the past few years, such as Diaspora, but they have not really taken off primarily because it's too hard to get users to run their own servers. Sandstorm potentially fixes that.
OwnCloud is a great idea and has a lot of great features, but as a platform for "apps" it has some big limitations:
- AFAIK, there is no sandboxing. All apps can access all data, apps can "phone home" without permission, and one bad app can break your server. Under Sandstorm, each app instance runs in a separate sandbox and can only talk to other apps (or the internet) with permission.
- OwnCloud apps must be written in PHP, whereas Sandstorm can support any Linux-based tech stack.
That said, it would totally make sense to see OwnCloud as an app running inside Sandstorm.
At present, Sandstorm's sandboxing is incomplete. Malicious code probably can escape. Malicious code definitely can DoS your server by consuming all available resources.
Its good to run our own server for control, freedom, security and so on. Makes sense. I have been doing that for decades but ok.
So now we add the term "cloud" to it, and wrap it up. Some great ideas that I like sure.
But.. I can rent my own private server on their cloud platform...... HOw is that different from almost every other vendor.
Inside my house/business sure.
Creative marketing though, "Personal Cloud Platform".
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.
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."
See also: http://en.wikipedia.org/wiki/Capability-based_security
Could that server be one's mobile phone?
:)