By Asheesh Laroia - 12 Jan 2015
I’ll be in the Boston area next week, and I’ll be organizing a web app self-hosting meet-up on Tuesday, Jan 20, from 7:30pm to 9:30pm at Clover Harvard Square. If you’re in town, I hope you can escape the cold and come by! First beverage (beer/hibiscus lemonade/iced coffee/etc.) is on us. Please RSVP for free here!
If you’ve read this far, you might appreciate the following personal note:
I used to live in the Boston area, so it’ll be nice to see old friends and meet new people as well. If you haven’t heard of Sandstorm, but you care about personal servers or self-hosting, then I’d love to meet you.
In 2009, I once knew that the authors of a web application I used a lot, and had complicated feelings about, were coming to town. I read an announcement just like this one, and I thought, “Whatever, those people are too fancy to want to talk to me.”
I should have gone. And you should come to this one. RSVP here.
By Asheesh Laroia - 07 Jan 2015
I’m Asheesh Laroia, and I’m excited to say I’m joining Sandstorm as a member of the technical staff.
For most of my career, I’ve worked in open source: I’ve been a software engineer at Creative Commons, and I co-founded OpenHatch, a non-profit that helps people get involved in open source. I got my start in open source by reporting a bug against a Linux filesystem check tool, made my first visible contribution in 2003 when I created the Xbox-Linux wiki, and I mentor others as a Developer in Debian. I did a one-year stint in web startup-land to hone my security knowledge, and now I find myself in the coolest possible position: working at Sandstorm on tools and community to build the easiest, most secure system ever to run a personal server.
Personal servers mean a lot to me. I’ve been running one since 2001; in 2006, I found a way to move it out of my parents’ basement into friend’s apartment in Tokyo (that’s another story). I’ve been through it all – RAID failures, difficult package upgrades, and getting compromised – for the pride of knowing I’m running my own real Internet site, so it’s amazing to be working on Sandstorm’s mission of creating the easiest way to run a personal server.
I first heard about Sandstorm when Kenton visited San Francisco to discuss it with me and get my feedback. We talked about about what Sandstorm can learn from efforts like Freedombox, and I was impressed to discover that the Sandstorm vision seemed to be ahead of my own thinking. So last summer, I came to the Sandstorm Hackathon (app port-a-thon), and rather than port an app, I added a Vagrantfile to make it easier to port apps to Sandstorm from a Mac. You might have seen me talk about it in the video for the Indiegogo campaign.
Sandstorm’s mission has two pillars: the codebase, and the community, and I’m lucky to be working on both. As my first act, I’ve given us an IRC channel. Come find me in #sandstorm on freenode as “paulproteus” – ping me about parts that need improvement, or about how to get involved. If you already have a client, great – join in! And if you don’t, visit us via this web chat link and say hello! I’m looking forward to meeting all of you.
By Kenton Varda - 15 Dec 2014
Cap’n Proto is an open source serialization and RPC protocol being developed as part of the Sandstorm project. Today, we’ve released version 0.5 of Cap’n Proto with lots of goodies, including new features like generics and support for additional compilers and languages like Visual C++, Java, and C#. Much of the work comes from a large number of awesome open source contributors.
So, what does this have to do with Sandstorm?
Many developers are excited by Cap’n Proto for being “like Google’s Protocol Buffers, except infinity times faster”. When it comes to Sandstorm, though, the design of Cap’n Proto’s RPC system is far more important than the speed of its encoding. Sandstorm is a capability system: applications can send each other object references and address messages to those objects. Messages can themselves contain new object references, and the recipient implicitly gains permission to use any object reference they receive. Essentially, Sandstorm allows the interfaces between two apps, or between and app and the platform, to be designed using the same vocabulary as interfaces between objects or libraries in an object-oriented programming language (but without the mistakes of CORBA or DCOM). Cap’n Proto RPC is at the core of this.
This has powerful implications: Consider the case of service discovery. On Sandstorm, all applications start out isolated from each other in secure containers. However, applications can (or, will be able to) publish Cap’n Proto object references to the system representing APIs they support. Then, another app can make a request to the system, saying “I need an object that implements interface Foo”. At this point, the system can display a picker UI to the user, presenting all objects the user owns that satisfy the requirement. However, the requesting app only ever receives a reference to the object the user chooses; all others remain hidden. Thus, security becomes “automatic”. The user does not have to edit an ACL on the providing app, nor copy around credentials, nor even answer any security question at all; it all derives automatically and naturally from the user’s choices. We call this interface “The Powerbox”.
Moreover, because Sandstorm is fully aware of the object references held by every app, it will be able to display a visualization of these connections, allowing a user to quickly see which of their apps have access to each other and even revoke connections that are no longer desired with a mouse click.
Cap’n Proto 0.5 introduces primitives to support “persistent” capabilities – that is, the ability to “save” an object reference to disk and then restore it later, on a different connection. Obviously, the features described above totally depend on this feature.
The next release of Cap’n Proto is likely to include another feature essential for Sandstorm: the ability to pass capabilities from machine to machine and have Cap’n Proto automatically form direct connections when you do. This allows servers running on different machines to interact with each other in a completely object-oriented way. Instead of passing around URLs (which necessitate a global namespace, lifetime management, firewall traversal, and all sorts of other obstacles), you can pass around capabilities and not worry about it. This will be central to Sandstorm’s strategies for federation and cluster management.
By Kenton Varda - 05 Nov 2014
Today we have a few announcements regarding Sandstorm and mobile.
First, we’ve updated Sandstorm’s web interface to be mobile-friendly. Whereas before the UI was mostly unusable on mobile, now you should be able to get around reasonably well. Not all of our apps are optimized for mobile, but at least now that the Sandstorm shell works well, apps can follow.
Second, we’ve implement the ability for applications to export HTTP-based APIs, which among other things can be used to allow a mobile client application to access a Sandstorm-based server. To learn how to make your own application export an API, check out the documentation.
As an example of the new functionality, we’ve updated our port of TinyTinyRSS to support an Android client. Install the latest version of the TinyTinyRSS app and check out the preferences to learn more!
We’ve ported Telescope – a Reddit / Hacker News clone – to Sandstorm; find it in the Sandstorm app list now. Being a Meteor app, Telescope was, of course, easy to port using meteor-spk.
We are using Telescope to power the Sandstorm app committee voting app, where those people who purchased seats on the app committee during our Indiegogo campaign have been voting on the next apps for us to port. So far, they have chosen Gitlab and Diaspora.
Want to follow the action? Visit the app committee group.
We’ve updated the Groovebasin app to allow batch uploads of multiple songs. (This was previously disabled due to a limitation in Sandstorm, which we’ve now fixed.) Re-install Groovebasin from the Sandstorm app list to get the update. Now you can upload your whole music library more easily!
By Kenton Varda - 09 Oct 2014
It’s been a while since our last post, but we’ve been doing a ton of stuff. It’s been a mad scramble here at Sandstorm HQ to get things organized after our successful crowdfunding campaign. Let me fill you in on some of the things we’ve been doing!
The Sandstorm app list now stands at 20 apps. While we will continue adding more, it’s also important to keep the ones we have up to date. To that end, today we’ve pushed updates to several apps which have seen upstream changes since our original releases:
We have more updates coming soon, including Mailpile, Groovebasin, and ShareLaTeX.
We are also excited to say that our EtherCalc port will henceforth be directly maintained by the upstream maintainer, Audrey Tang.
We don’t have automatic “push” updates yet (they’re coming), so to update your copy of a Sandstorm app, you must go to the app list and install it again. Sandstorm will recognize that you’re installing an update and will upgrade your existing files.
Curious to see what’s going on with Sandstorm on a day-to-day basis? We have started posting our daily meeting notes to the Sandstorm dev list. Feel free to subscribe for updates. (And yes, we do hope to move the mailing list to a Sandstorm app as soon as we have one. ;) )
The App Committee will begin voting on new Sandstorm Apps soon. You can follow the action on the App Committee group (but only committee members can post there).
Sandstorm recently gained the ability to host apps which expose APIs. This means that it’s now possible to do things like have a mobile client app which talks to your Sandstorm server. We will soon be updating some of our existing apps to take advantage of this feature, at which point we’ll do a larger announcement. Check out the sandstorm-dev post for details.
Credits: Everyone who contributed and who responded to our questionnaire is now named in the Sandstorm about page and on our home page. If you contributed but missed the questionnaire we sent out, please e-mail us to let us know how you want your name to appear.
Stickers and t-shirts: We’ve collected everyone’s shipping addresses and t-shirt sizes and will be shipping these out soon. It took a little longer than expected to get everyone to respond, but we’ve now passed the info off to the fulfillment company and expect these to ship within the next five weeks or so.