Sandstorm Blog

Nominate Apps for Sandstorm

By Jade Wang - 25 Aug 2014

What app would YOU like to see on Sandstorm?

We’d love to hear from you. From now until the end of the campaign, you can tweet in your favorite apps to our app survey. Just nominate them with a tweet, and they’ll make the short-list for the App Committee to consider. For instance: “I’d love to see @joindiaspora on @SandstormIO! http://igg.me/at/sandstorm”

The apps will be presented in a list to the App Committee with the number of votes (tweets) it received, starting with the most highly requested. The App Committee will then decide what makes sense to work on first.

How it works:

• If the app has a twitter handle, please use it (or include a link to the app, if they don’t).
• You can tweet multiple apps, and ask your friends for retweets.
• Retweets count as votes.
• For your vote to be counted, your tweet should begin with a character other than @ and contain @SandstormIO and a link to the Indiegogo campaign.
• Hint: Use the “tweet” button on the campaign page to get your personalized referral link so that you can receive referral bonuses.

We’re in the home stretch, 83% of our way there, with just one more week left in the campaign! We need your help to make Sandstorm happen.

P.S. Of course, you can always port the app yourself rather than wait for us. Please drop us a line if you do. :)

Campaign Recap

By Kenton Varda - 22 Aug 2014

There are just under 10 days left in our campaign. As of this writing, we are 78% funded. If you haven’t contributed yet, now is the time! Go to Ingiegogo »

Let’s take this moment to recap everything that’s happened over the campaign so far. But first, some brief announcements.

Quick Announcements

App committee seats are sold out. We had been doubling the price for every 10 seats sold, but we’re all out of perk slots on Indiegogo, so we’ve stopped at 30. However, you can still get a seat on the committee by becoming a Key Individual Sponsor ($2048 includes-everything perk) or by being our top referrer (see referral program, below).

Heading for the playa? We know a lot of you San Francisco geeks might not have internet for the next week. Don’t forget to contribute before you leave, because the campaign will be over when you get back!

We finally added an RSS feed. The Sandstorm blog now has an RSS feed. Looking for an RSS reader? Try TinyTinyRSS on Sandstorm. :)

Our Core Sponsors

Our first Key Individual Sponsor ($2048 level) is Roger Wagner. Roger is known for many things, including having written the first book on Apple II programming and creating HyperStudio. As a sponsor, he’ll be featured along side our own team on our web site and in our credits. Thanks, Roger!

Our first Corporate Sponsor ($4096 level) is draw.io, a powerful web-based diagramming tool. As a sponsor, their logo will be displayed on our site and in our credits, and we’ll be helping them get draw.io on the Sandstorm app store. Thanks, draw.io!

Would you or your company like to become a core sponsor? Consider that your contribution alone could increase our funding level by four or eight percentage points, and we’ll feature you name and picture/logo on our web site and credits for at least two years. Thinking about it but not quite sure? E-mail Kenton to discuss terms.

Campaign Recap

Blog posts you should read

• Open Source Web Apps Aren’t Viable; Let’s Fix That
• Why doesn’t Sandstorm just run Docker apps?
• Let’s end walled gardens
• Sandstorm vs. Kernel Exploits
• Porting Meteor apps to Sandstorm in three minutes
• What happens if an app has security bugs?

App ports we released

• Apache Wave (real-time discussion engine)
• EtherCalc (collabortaive spreadsheet editor)
• ShareLaTeX (collaborative LaTeX editor)
• Ghost (blogging platform)
• WordPress (publishing platform)
• Mailpile (e-mail)
• Roundcube (e-mail)
• TinyTinyRSS (feed reader)
• MediaGoblin (photo/media sharing)
• Game of Y (game)
• Meteor Blocks (simple voxel scene editor)

Talks and Interviews

• Sourcegraph talk
• Redecentralize.net interview
• Meteor Devshop lightning talk

Press

• GigaOM: Sandstorm’s decentralized hosting platform could finally make indie web apps viable.
• WIRED: Sandstorm Makes It Easy to Control Your Apps in the Cloud.
• TechCrunch: Sandstorm Wants Web Users To Gain More Control Over The Apps They Use.
• Linux Weekly News: Sandstorm Personal Cloud Platform
• Opensource.com: What owning your personal cloud means for the open source movement
• GigaOM: Remember Google’s Wave? Thanks to Sandstorm, it’s easy to start using again.
• Tech News Today: Wave makes a comeback. (seek to 14:32)

Referral Program

Don’t forget about our referral program:

If you refer someone, and they contribute, we’ll give you your choice of:

a) 1GB bonus storage for every $10 referred (on our managed hosting service, for one year).

b) 10% of your referral total in app store credit. Remember that our app store will support a pay-what-you-want model for open source apps, so this basically means you can donate your credit to the developers of an open source Sandstorm app of your choice.

The top referrer will additionally receive their choice of a LAN party invite (see the $512 perk) or a seat on the app committee (with $256 voting rights).

In order to receive credit for your referrals, be sure that you are logged into Indiegogo, then use the buttons under the video on our campaign page to share. These buttons will generate links that track the fact that they came from you.

Apache Wave on Sandstorm

By Kenton Varda - 20 Aug 2014

In an unspeakable act of technical necromancy, we’ve revived what was once Google Wave and placed it on the Sandstorm app list. You can install it now – on your own Sandstorm server, or using our demo – and use it to… um… whatever it is that Wave is for. We’re still trying to figure that out too. We’re pretty sure it’s amazing, though!

OK, joking aside…

Put simply, Wave is a collaborative document editor with inline, nestable comment threads. What do you use it for? Well, one thing I think it’s great for is design discussions. Your root Wave is your design proposal. People can comment on individual parts, you can reply to those comments, and so on. It’s easier to keep threads organized than in an e-mail discussion. For example, here’s what a recent design discussion I had with security guru Jas Nagra might have looked like as a Wave:

As you may recall, Google released Wave back in 2009 to great fanfare only to pull the plug on it just a year later, citing lackluster user growth. Whether that was the fault of the product itself or of a botched rollout and bad messaging is hard to say. In any case, Google was kind enough to release their code, and since then the folks over at Apache have been keeping development going as Apache Wave.

Apache has made sure that Wave keeps progressing. But, how exactly does one use Wave today? Well, a few people maintain demo servers, but these are not meant for real use and have no reliability guarantees. Instead, if you really want to use Wave, you are supposed to set up your own server.

Now there’s an easier option: Install it on Sandstorm.

Moreover, with our port, it’s easier than ever to actually share a Wave with your friends. Normally with Apache Wave today, you must convince your friends to first create accounts on your Wave server so that you can then share with them. For our Sandstorm port, we’ve adapted Wave to rely on Sandstorm for sharing. What that means right now is that to share a wave with anyone, all you have to do is send them the URL. They don’t even need to have a Sandstorm account. Sandstorm’s sharing model will become more sophisticated in the future, but we consider it critical that sharing with anyone – whether they have an account or not – be as frictionless as possible.

We see companies shutting down useful apps all the time. Often, they offer users the opportunity to download their data as massive zip files full of useless XML. Wouldn’t it be great if these companies could give you not just your data, but also the app, in a format that you could easily keep using? We hope that in the future, developers will decide that it makes more sense to convert their failed SaaS offerings into Sandstorm apps. This way, companies can cut their costs without leaving users out in the cold.

If you want to see Sandstorm succeed, there are 12 days left to contribute to the campaign.

Why doesn't Sandstorm just run Docker apps?

By Kenton Varda - 19 Aug 2014

We get this question a lot. Sandstorm and Docker use the same Linux kernel features for containerization. Docker already has a large ecosystem of apps. Why introduce a new app format? Why not simply position Sandstorm as a UI for Docker? Wouldn’t that save a lot of work? Why reinvent the wheel?

The fact of the matter is, Sandstorm and Docker, despite similar underlying tech, are very different platforms. Asking why Sandstorm doesn’t run Docker apps is a lot like asking why Android doesn’t run Linux desktop apps. If it’s the same Linux kernel under the hood, shouldn’t it be able to run the same apps? Well, a Linux desktop app would have a lot of problems running on Android. Most obviously, a desktop app’s UX would be all wrong on a small touchscreen. Moreover, the app would not fit into Android’s security model. It would not understand Android’s battery-saving lifecycle rules. It would not know how to tap into the unique devices (e.g. accelerometer, GPS) and opportunities (e.g. connecting with nearby devices) commonly available on phones but not on desktop.

Asking why Sandstorm doesn't run Docker apps is a lot like asking why Android doesn't run Linux desktop apps.

Running a Docker app on Sandstorm would be much the same story. Docker is designed to run off-the-shelf server-oriented Linux software and distributions inside containers. Docker’s platform, from the app’s point of view, is just Linux. From the user’s point of view, you use Docker much like you’d use traditional VMs and compute clusters; it’s just a lot more efficient.

Sandstorm, though, is doing something completely different. We are trying to manage personal servers for end users. With Sandstorm, the person deciding what software to deploy is not necessarily a developer or system administrator. They may not know how to use a command line or edit config files. They may not know what a database is, and so aren’t likely to understand why they need to set up MySQL before they can run that app they’re interested in.

This use case calls for a completely different model, just as phones call for a different model from desktops. We need to design a bunch of things differently:

• Every app must have a web interface, and they must expose all configuration options through that interface.

• Users expect their data to be organized in units of documents or other semantic objects, not in units of databases or relational tables. Apps must set up their own database and encapsulate it appropriately; the user won’t do it for them.

• Users should not have to log into every app separately, especially when the app instance already belongs specifically to them and Sandstorm is already protecting access. So, apps must integrate with Sandstorm’s unified login system.

• It would also be nice if users did not have to master a different sharing model for every app. Sandstorm supports fine-grained containers, such that every document can actually be in a separate container. This way, the platform can handle sharing consistently across all apps, by applying sharing to the containers. But, apps have to be designed for this.

• Permission grants must be expressed in a way that users can understand. A user does not know what it means to allow an app to communicate on port 25, but they do know what it means to allow an app to send and receive e-mail under a particular e-mail address. In order for such permissions to be enforceable, the platform’s security model must actually operate in terms of these semantic permissions, not arbitrary TCP connections.

• Updating an app must be a one-click (or even automatic) process. This means there must be a clearly-defined separation between the app “image” and its instance data, so that the platform is able to replace the former without harming the latter.

• Users will install malicious apps from time to time, and they must be protected from these. The regular Linux kernel interface is far too wide, and critical exploits are found too often. We must instead present a much narrower interface and force apps to adapt. See our previous post on this.

For all these reasons, a Docker app simply would not be able to run under Sandstorm without modification. The modifications needed for typical Linux web apps tend to be light, but they are necessary.

Why not at least use the container tech?

So, we’ve seen that it wouldn’t make sense to run a regular Docker app on Sandstorm. But, why don’t we still use Docker’s tech, and simply define an extra set of rules which Sandstorm apps much follow? Sandstorm would only be able to run the apps explicitly targeted for it, but at least we wouldn’t be reinventing the wheel technically, right?

Well, first of all, we do use a lot of the same tech as Docker. Namely, we use the Linux kernel sandboxing features, such as namespaces and (soon) cgroups. These features do all of the heavy lifting of containerization.

When it comes to userspace tools, it turns out that we just don’t really need anything Docker provides. Docker’s tools are designed to be highly adaptable and configurable in order to accommodate a wide range of Linux software without modification. Sandstorm, however, isn’t trying to run arbitrary Linux software. Apps already have to be adapted to Sandstorm’s environment. So, we are actually better off providing minimal configurability in order to keep the core system simple.

Setting up a Sandstorm sandbox, based on raw Linux system calls, takes only a few hundred lines of code. Using Docker, it would probably be a few hundred lines of configuration instead, while adding a huge new dependency and all the maintenance issues that come with that. We would probably regularly find ourselves needing to push features upstream to Docker which Docker doesn’t otherwise need or want. It’s a lot of burden that wouldn’t buy us anything.

We do often use Docker’s build tools in the process of building Sandstorm packages, simply because they provide a structured and reproducible way to gather an app and its dependencies into a chroot environment, which we can then package up. This is a fine option for app developers that does not affect the runtime system.

To be clear, Docker is awesome

We aren’t trying to dis Docker here. For what it’s trying to do – replace VMs with something not as horribly inefficient – Docker is amazing. We are excited to see it replace legacy IaaS solutions, and we will likely be targeting it as a way to run Sandstorm itself.

But despite an initial appearance of similarity, Docker and Sandstorm simply aren’t the same thing, and forced sharing of code for very different purposes would not benefit either project.

If you want to see Sandstorm succeed, there are 13 days left to contribute to the campaign.

WordPress on Sandstorm

By David Renshaw - 18 Aug 2014

WordPress is the world’s most popular web publishing platform, and we are excited to announce today that we’ve ported it to Sandstorm.

You can try it now in the demo or on your personal Sandstorm server.

Like the existing HackerCMS and Ghost apps, WordPress on Sandstorm lets you publish content to a custom domain. You can use it to create all kinds of web sites, including blogs, magazines, and webcomics. WordPress has an enormous ecosystem of themes and plugins, and our port grants you the power to install any of them and to modify them through the built-in editor.

Moreover, the app’s integration with Sandstorm’s login system makes it easy to collaborate with multiple authors; you can add new authors simply by sharing a link.

A few features of WordPress require us to make more progress on Sandstorm before we can support them. We would like to allow the app to make remote HTTP requests – a feature that would simplify the process of installing add-ons and importing media content – but we also want to tightly control that capability, so that an evil plugin can’t leak data. This will require the Powerbox. We would also like to integrate WordPress’s comment system with SandStorm’s web publishing, but before that’s possible Sandstorm apps need to be able to export public HTTP APIs.

Fortunately, these are things we’d like to add to Sandstorm anyway. And, of course, the more help we get from you in our crowdfunding campaign, the sooner we will be able to add them.

In any case, we think that among WordPress hosting options, WordPress on Sandstorm offers a uniquely high degree of convenience, freedom, and security.