Sandstorm News

Sandstorm is a self-hostable web productivity suite. Host your own

Recommended Posts

Further Reading

Results from app update week

By Asheesh Laroia - 11 Feb 2015

Updates to the porting guide

Over the past year, the Sandstorm platform has grown new features to fit app developers’ needs. For example, Sandstorm apps can now send and receive email and export an HTTP API, enabling apps to federate across sites or communicate with a mobile app.

The process of porting an app to Sandstorm has also become better-documented and more reliable. The Porting Guide contains our collected wisdom on making an app work great under Sandstorm, including framework-specific advice to streamline the porting process. It mentions the tool that Kenton wrote last year – meteor-spk – that makes porting apps for one framework as easy as running a few commands. More recently, David’s experience maintaining apps like ShareLaTeX and GitLab resulted in a collection of tips for porting Rails apps.

I’m heartened to report that in addition to the platform and docs changes, there are three Sandstorm apps actively maintained by their authors: draw.io, EtherCalc, and LibreBoard. Those apps now appear at the top of the Sandstorm app list. In the long run, the best way for a Sandstorm port to stay up-to-date is for the app’s own community to actively maintain the app on Sandstorm as well.

App update week changelog

The core team still maintains twenty apps, and this experience allows us to continuously improve the the documentation and automation behind the porting process and prioritize which platform features to build. Those apps’ own communities have been hard at work, so we took the past week to make those changes available to users of Sandstorm.

Here’s a list of the apps that received updates.

One click to try an open source web application

By Asheesh Laroia - 06 Feb 2015

Give your potential users an instant demo of your app, easily!

If your app has a Sandstorm port, you can now use it to power a “Try this app” link on your app’s homepage. If you don’t have a Sandstorm port yet, now’s a good time to make one.

I wrote this new Sandstorm feature to help GNU MediaGoblin users try it before installing. Everyone who clicks “try a demo right now” from the MediaGoblin homepage gets a totally fresh instance to play with; it lasts an hour, like everything else on demo.sandstorm.io, then vanishes into the ether. Once you click, here’s the top of what you see:

To use this feature for any app in the app list, make a link to https://demo.sandstorm.io/appdemo/appId, where appId is the public key of the app in question, and then ask people to click that link. The link goes to a page explaining the one-hour lifetime of the demo, and then one click later, a fresh instance of the app. To learn more, check out the wiki page on demo mode.

Huge thanks to Chris Webber of MediaGoblin and Maxime Quandalle of Libreboard for testing out the feature. Libreboard and Groovebasin picked up the app demo link for their sites, too.

If you want to make a public demo of your own app and it doesn’t have a Sandstorm port yet, it’s simple to get started. Sandstorm supports any app framework that runs on Linux: Rails, Django, node, Perl CGI, you name it. Follow the porting guide and you’ll see how Sandstorm auto-detects the app’s dependencies and helps package them up. Once you’re done, let us know and we’ll add you to the Sandstorm app list. That list powers the demo as well as provides apps to people’s personal Sandstorm servers, so you’ll also be strengthening the ecosystem of self-hosting. If you’re excited about that but don’t know where to start, get in touch!

draw.io: Advanced Diagram Editor on Sandstorm

By Kenton Varda - 03 Feb 2015

Today we are releasing draw.io, an advanced diagramming editor developed by the folks at JGraph. You can install it on your Sandstorm server from the app list. Or, try it on our demo server now »

As you may recall, draw.io was one of the “Corporate Sponsors” of our Indiegogo campaign, chipping in $4096. Now, they’ve given us an app.

I’m excited about this for three reasons:

First, draw.io is an app I really want to use. I often need to create system design diagrams or UI mockups, and in the past I’ve struggled to find a good tool for these jobs. Local apps are a pain to manage (hard to share, need to make backups, etc.) but the cloud offerings I’ve used in the past were mostly unsophisticated (like Google Drive’s) or required keeping my data on the servers of a company I knew nothing about. With draw.io on Sandstorm, I know where my data lives, I can share it securely, I know the app cannot disappear on me, and I know the app is not secretly mining my data. And as far as functionality goes, it’s more powerful than anything else I’ve used.

Second, draw.io’s Sandstorm port uses the Sandstorm APIs natively, and that makes it start faster and use far fewer resources than other apps. Although Sandstorm apps are web-based, Sandstorm does not actually speak HTTP directly to apps. Instead, it converts incoming requests into Cap’n Proto requests according to the WebSession API. This brings significant security benefits. However, most apps are built on existing HTTP frameworks, and therefore most Sandstorm apps use sandstorm-http-bridge, a small program that runs inside the sandbox and converts incoming WebSession calls back into loopback HTTP requests. This allows these apps to run in Sandstorm with minimal code changes, but it’s a bit inefficient.

draw.io on Sandstorm does not use sandstorm-http-bridge; instead, it implements the Cap’n Proto interfaces directly, avoiding a step. Moreover, this makes the code much simpler – draw.io does not need to include an HTTP server framework at all. The whole server is actually implemented in one C++ file, based closely on our Raw API Sample App. As a C++ program, draw.io’s server also uses only a couple megabytes of RAM, whereas most apps written in dynamic languages use on the order of 100MB – this means that on our upcoming managed hosting service, draw.io will use almost no compute units.

Third, draw.io is our third app whose Sandstorm port is maintained directly by the upstream authors, joining LibreBoard and EtherCalc. Ports maintained by upstream authors tend to be higher-quality and get more timely updates, since it’s tough for us to closely track our 20+ app ports while working on Sandstorm itself. (Speaking of which, this week is App Update Week: we’ll be refreshing most of our app ports to their latest versions. Today we published updates to GitLab, GitWeb, MediaWiki, Groove Basin, and Telescope. We’ll talk more about this in another blog post later this week.)

It’s worth noting that draw.io is our first proprietary app. It’s “free as in beer”, but the code is not open. For many people, as long as they have control of the server, whatever gets the job done is fine. But, we know some of you would prefer to use only Free / Open Source Software. To that end, we’ve implemented a new filtering feature on our app list which allows you to choose to see only open source apps.

Wiki permissions and community docs

By Asheesh Laroia - 22 Jan 2015

The Sandstorm wiki is now world-writable, and I made a new page to help people get involved.

I realized the wiki should be world-writable when phildini remarked on IRC that the porting guide could give better advice for Mac OS users. What I really wanted to do was ask him to update the page himself, but I discovered I would first need to grant him access. So I made it writable by anyone logged into GitHub, and I configured a script to email a mailing list whenever it gets changed. Within forty-eight hours, I saw a new person contribute to the wiki!

The wiki is one of the things I mention on the new Get Involved page. In writing it, I took a lot of inspiration from Meteor’s – it’s a particularly great one. My goals are to showcase all the ways to contribute to Sandstorm across diverse skill sets and to have a contextualized listing of all the places that project members communicate. I’m excited to watch the community build great things on Sandstorm, and extraordinarily grateful to people who share the platform with friends. I think the most important thing Sandstorm needs right now is more people knowing about the project.

So please give it a read and get involved!

Gitweb and Gitlab

By David Renshaw - 21 Jan 2015

When I write software, Git is usually at the core of my workflow. Therefore I’m particularly excited to announce today that we are releasing not one but two Git apps for Sandstorm.

With either of these apps, you can host a Git repository on a Sandstorm server, connect to it with a Git client, and browse it through a web interface. Furthermore, both apps make it easy to share access to a repository without any need to manage SSH keys.

The first app is a simple wrapper around GitWeb, the minimalist Perl CGI script that comes bundled with Git.

Gitweb

The second is a port of GitLab, a sophisticated Ruby on Rails app whose features include an issue tracker, a wiki, and an editor that allows you to compose and submit commits entirely from a web interface.

Gitlab

Both apps can now be found on the Sandstorm app list. If you don’t have your own server already, try the demo.

The Rise of Modular Frontends

These two apps bring into focus some distinguishing characteristics of the Sandstorm platform.

Web software today tends to consist of monolithic, centralized services – at least when viewed from a user’s perspective. As the number of users grow, the demand for scalability and easy deployability can drive developers to put a lot of effort into modularizing backends. So the software often gets split into reconfigurable components like databases, caches, webservers, and message queues, and we see lots of clever ways to organize and orchestrate all of these things. However, as far as the user can tell, the only benefit is that, well, the service still works.

Sandstorm enables a more fundamental kind of modularization. Because it is decentralized and carefully designed to take full advantage of Cap’n Proto’s object-capabilities, Sandstorm allows web software to be split into fine-grained components along user-facing concerns. The components can be so finely grained, in fact, that scalability ceases to be a major concern. When each app instance (a “grain” in Sandstorm jargon) contains only a single document, app developers can instead focus on user-facing functionality, and can start thinking seriously about cooperation between apps.

And that’s why we’ve set up the GitWeb and GitLab apps to provide only a single repository per grain. This setup means that sharing a Git repository with another user through these apps works just like sharing anything else in Sandstorm. Although it does imply that some GitLab features, like forks and merge requests, are not supported within our port, it also means that once we’ve fully implemented Sandstorm’s Powerbox interface for sharing capabilities between grains, “fork” and “merge request” can be actions that are allowed to take place between instances of any Git app.