Ghost Blogging Platform on Sandstorm
By Kenton Varda - 22 Jul 2014
Today we’re releasing a major new app on Sandstorm: Ghost.
Ghost is a blogging platform featuring beautiful design, and which was funded by its own crowdfunding campaign last year. We’re extremely excited to bring it into the Sandstorm fold, in particular because we’ve been wanting to use it ourselves!
You can use Ghost on Sandstorm to publish a blog to an arbitrary domain. It uses Sandstorm’s web publishing features.
If you have a Sandstorm server, go install Ghost from the app list now. Don’t have one? Try our demo server.
Open Source Web Apps Aren't Viable; Let's Fix That
By Kenton Varda - 21 Jul 2014
The Motivation for Sandstorm
We talk a lot about the need for privacy, security, and control of your cloud data. Let me let you in on a secret: These aren’t the reason for Sandstorm. They are pleasant side effects.
The real motivation for Sandstorm is, and always has been, making it possible for open source and indie developers to build successful web apps.
In today’s popular software-as-a-service model, indie development simply is not viable. People do it anyway, but their software is not accessible to the masses. In order for low-budget software to succeed, and in order for open source to make any sense at all, users must be able to run their own instances of the software, at no cost to the developer. We’ve always had that on desktop and mobile. When it comes to server-side apps, hosting must be decentralized.
But today, personal hosting is only accessible to those with the time, money, and expertise necessary to maintain a server. Even most techies don’t bother, because it’s a pain. Sandstorm exists to fix that, making personal hosting easily accessible to everyone.
"The only solution is to make sure everyone has a server where they can install any software they want."
Open Source has worked on the desktop and mobile.
On my desktop, I run Debian Linux. My system is composed of several thousand packages. I have browsers, text editors, IDEs, chat clients, office suites, development tools, photo editors, and media players. Remarkably, every single one of these is open source. Even more remarkably, I can’t remember the last time I felt any need to use a non-open-source desktop app.
I’m no zealot. I don’t impose open source on myself, nor would I do so on others. I’ll use proprietary software when it gets the job done, and I have spent plenty of time as a Windows user and as a Mac user in my past, but these days I’m simply happiest on a Linux system. That’s my personal preference and it’s not for everyone, but the fact that this choice is available to me and that I can run an all-open-source desktop without pain is pretty amazing considering how things looked fifteen years ago.
Even Windows and Mac users these days use lots of open source software. By some measures, a majority of people now use an open source browser. VLC, BitTorrent, and other “indie” open source desktop apps are widely used even among non-technical people. Mobile seems even more full of open source and low-budget indie apps, as the various mobile app stores make it extremely easy for small developers to reach large audiences.
Yet, somehow, the web today is nearly completely devoid of open source software. Every day I use apps like GMail, Facebook, Twitter, Feedly, and others. None of these are open source. Granted, these apps often run on open source infrastructure, but that’s different. Most proprietary desktop apps use open source components and tools as well. But web apps, as the users see them, are almost invariably proprietary.
Why are all my web apps proprietary?
Open source web apps exist. For example, webmail apps like SquirrelMail and RoundCube have been around for a while. If you look hard enough, you can find open source online document editors, RSS readers, and even a few social networks. But even among techies, hardly anyone seems to use these, probably because they all require running your own server, and few people have the time, patience, and expertise for that.
There are a few success stories. Wordpress is open source and widely-used for blogging. But this seems to be the exception rather than the rule. And it’s questionable at that: most people who use Wordpress are not actually able to edit the code, because they are using it through a Wordpress hosting service and can only use the version of Wordpress that that host provides. Naturally, all hosts will likely only use the “official” version. So in practice, it’s almost not really “open source” but “visible source” – you can see the code and request changes, but you only get to use your changes if they’re officially adopted.
Why does no one use “indie” web apps?
Even on Windows, people commonly install little open source apps to get things done. Need to tag some mp3s? Want to connect to multiple chat networks with one client? Need to unpack a weird archive format? You’ll probably use an open source app. Sometimes it’s hard to build a business case around a niche purpose, yet little apps written by random people in their spare time are abundant. But on the web, it doesn’t seem to work this way. Any significant service with a server-side component can really only be run by a funded corporation.
Let me describe a case in point: I know a certain prolific coder by the name of Brad Fitzpatrick. You may know him as the author of LiveJournal, Camlistore, memcache, OpenID, and other things. But I want to talk about a project of his you probably haven’t heard of.
scanningcabinet is a little web app that helps you organize your paper mail. You drop your mail into your scanner, and the app scans it and uploads it to “the cloud”, where you can access, label, and search it later. Brad wrote this on a weekend several years ago and threw the code up on github.
This app could be useful to just about anyone. But sadly, no one can really use it. To set it up, you have to configure a server (App Engine, in this case) and deploy the code to it. Even for someone like me, who knows how to do that, it’s not something I really want to do.
By today’s model, if Brad wanted to make this app accessible to the masses, he’d have to run it as a service. He’d have to build in multi-user support, make sure it’s secure, deploy it, and monitor it. Worse, he’d have to pay for it, which means he’d have to monetize it, which probably means he’d have to start analyzing people’s mail to build advertising profiles, or set up billing. Brad obviously doesn’t want to do any of that.
And even if he did, who would use it? Do you want to upload your paper mail to servers run by some guy on the internet? I’m certainly not going to trust my personal data to any service that isn’t at least backed by an identifiable organization with something to lose if it screws up.
The problem is hosting.
By this point the problem is becoming clear: for open source software to make sense, the user has to be running their own instance. Software-as-a-Service and open source just don’t make sense together. It’s not really open source if you can’t run modified code, and the high barrier to entry shuts out hobby projects or anything unwilling to be monetized.
The only solution is to make sure everyone has a server where they can install any software they want. They don’t necessarily have to administer that server – it could be run by a friend, or a service – but each user must be able to install arbitrary software. And that software must be securely sandboxed to prevent buggy or malicious software from harming the rest of the server.
Today, this doesn’t exist in any practical form. Servers require time and technical expertise to set up, while turnkey hosting services only allow you to run a fixed set of software.
There is no place for open source web apps to run.
We’re making decentralized hosting viable
Sandstorm is a web app hosting platform that enables non-technical end users to install and run arbitrary software. Apps may be downloaded from an app store and installed with one click, like installing apps on your phone. Each app server runs in a secure sandbox, where it cannot interfere with other apps without permission.
We talk a lot about privacy, security, and control, but to me these have always been pleasant side-effects of Sandstorm’s model. My main motivation for starting this project has always been to enable open source software, hobby projects, niche applications, and indie developers. Even if each individual app in this category ultimately has a small impact compared to GMail or Facebook, the collective value lost by not giving these apps a platform is enormous. We need open source software to fill the niches that big companies aren’t interested in, and to push the boundaries they find too risky. We need software that can be tweaked without permission to try new things without starting from scratch. It honestly seems absurd to me that we don’t really have this on the web today.
Help us get there
We’ve already come a long way. We have a demo that does most of what we’re talking about already. But we’re coming up on the limits of what we can self-fund. We can get Sandstorm into production, but we need your help.
Please check out our campaign on Indiegogo, and spread the word.
We're Crowdfunding!
By Kenton Varda - 17 Jul 2014
Sandstorm is already working and useful (this very blog is hosted on it), but to get it the rest of the way to production, we need your help!
Sandstorm on Indiegogo »
Demo box; App updates
By Kenton Varda - 11 Jul 2014
A few quick updates today.
New Demo server
It’s now possible to try out Sandstorm without an invite, and without installing it locally. Just go to demo.sandstorm.io.
On the demo server, anyone can create a one-hour trial account. We hope that this will make it much easier for people to understand what Sandstorm does, before they install it or wait in line for an invite. If a picture is worth a thousand words, a demo is worth ten thousand.
App updates
We’ve posted updates to several apps with bug fixes and other improvements. Currently, in order to update an app, you must re-install it from the app list. (Push updates for apps are on our todo list.) So, if you’ve installed any of the following, install them again.
- Mailpile: Fixed bug where sent mail sometimes wasn’t saved.
- IPython Notebook: Added numpy and plotting packages, so you can now plot graphs.
- Etherpad: Minor UI tweaks.
New features and fixes
- We’ve added a “reset” button to the top bar, which lets you restart an app if it somehow gets wedged. This is rare, but otherwise really annoying when it happens.
- Apps now receive the user’s display name and a unique stable identifier, which are useful for collaborative apps meant to be used by more than one user.
- We fixed a crash that happened when updating a Sandstorm instance that runs as non-root, and tightened some security knobs in this mode.
License is now Apache 2.0
Several people told us they were not comfortable contributing to Sandstorm when licensed under the GNU AGPL, or that their employers were hesitant to allow them to contribute. We think this is entirely understandable. We have always intended to switch to Apache 2.0 after gaining some momentum (which is why we have asked contributors to sign a CLA allowing us to make this change). So, we’ve gone ahead and made the switch now.
Mailpile on Sandstorm
By Jason Paryani - 07 Jul 2014
Hello, I’m Jason, a new member of the Sandstorm team. Today I’m excited to announce that I’ve extended Sandstorm to support e-mail, and ported Mailpile Alpha II to demonstrate. Mailpile is available on the Sandstorm app list right now, so go ahead and try it out.
You may know Mailpile from their successful Indiegogo campaign last year. They’ve been working hard to create a web mail app that is designed to be self-hosted, which makes it a perfect fit for Sandstorm. It’s worth noting that Mailpile itself is, like Sandstorm, still in alpha. It is still somewhat rough around the edges, and may not quite be ready to replace your regular e-mail client yet. We will be updating our port as Mailpile matures, and we’re also looking at porting some other web mail apps so that you can choose the one that’s right for you.
How Sandstorm does e-mail
We know that switching people over to using Sandstorm for e-mail will take time. So, we are starting with a design that makes it safe and easy to try out Sandstorm without committing.
When you launch an e-mail application on Sandstorm, it is assigned a random e-mail address at your server, like “[email protected]”. Any e-mail sent to that address is delivered to the app. The idea is not that you’d actually use this address publicly, but rather that you should set up e-mail forwarding from your real address to this address. For example, GMail allows you to set up such forwarding while still keeping a copy in your GMail inbox, and even lets you do the forwarding conditionally based on a filter. Additionally, most domain registrars have the ability to set up basic e-mail forwarding, so if you have your own domain, it’s easy to set up an address that redirects to a Sandstorm app.
When you send e-mail from a Sandstorm app, we allow you to set the “From” header either to your app’s random address or to your verified Sandstorm login address. In the future, we’d like to add the ability to attach additional verified addresses to your account. Either way, the message’s envelope return address is always the app’s address. As a result, the mail recipient may see that the message was sent “via” your server.
For more details on how to write an app that uses e-mail, and how to set up your Sandstorm server to support e-mail, check out the docs:
A note on encryption
A key feature of Mailpile is its support for PGP / GPG encryption and signatures. Unfortunately, this is not yet supported by our Sandstorm port, as we need to do more work to get crypto right.
The simplest way we could support crypto would be to have you upload your private key into the app, to be stored on the server. This is not a good idea! In an ideal world, your private key would live only on a physical token or smart card and never even touch the storage of a real computer. Barring that, you should at least keep your key only on systems you own. If you run your own Sandstorm server, then uploading your key might be OK, but for anyone using a shared server, it’s not a good idea. We want a solution that works for everyone.
Therefore we are looking into how we can make crypto available to Sandstorm apps without sending your key to the server. We are hopeful that the nascent WebCrypto API might solve this problem, but at present the standard is still under development and there is apparently some controversy over its design. In the meantime, browser-extension-based approaches like Google’s End-To-End provide an intriguing alternative, although Chrome’s decision to kill off NPAPI may make it impossible to access hardware tokens or your local GPG agent in this way.
In any case, this is something we’ll be investigating further in the future.