By David Renshaw - 09 Aug 2016
Starting work on a project in Sandstorm often means creating many grains, each pertaining to a different aspect of your work. In a typical project, you might have a spreadsheet, a chat room, a kanban board, and several source code repositories. Sandstorm makes it easy to share these grains with your collaborators, but until recently, you would need to share each grain to each collaborator separately — a task that could quickly become tedious. What if you want to share the entire project as a single unit?
Now that we have released the Collections app, we have a satisfying answer to that question; to share many grains at once, you add them to a collection.
A collection is a list of grains. Any collaborator with whom you share a collection gets access to all of the grains in it. On the flip side, when you remove a grain from the collection, your collaborators lose access to that grain. Moreover, when you revoke a collaborator from the collection, that (now former-) collaborator loses access to all of the collection’s grains.
And since a collection is itself a grain, sharing one works just like sharing anything else on Sandstorm, through the “Share access” button.
The fact that we have implemented collections as an app may come as a surprise, since the notion of a collection might seem fundamental enough to deserve being baked-in as a core feature of Sandstorm. However, Sandstorm bakes in an even more fundamental notion: the idea that grains can refer to and coordinate with one another. The embodiment of this idea is the powerbox, an interface — mediated and auditable by the user — through which grains can exchange capabilities.
When you click the “Add grain” button in a collection, the collection in fact initiates a powerbox request. Sandstorm then asks you, the user, to choose a grain with which to fulfill the request.
Once you select a grain, the collection receives a reference to that grain. It can then use that reference to retrieve metadata such as the grain’s icon and the the name of the app that created the grain. Crucially, it can also offer the reference to your collaborators, so that your single “Add grain” action can result in all of your collaborators receiving access to the grain. The behind-the-scenes details of how this all works can be found in our technical documentation.
Other apps can use the powerbox in the same way. You could write an alternative implementation of collections, either by starting from scratch or by forking ours. Apps whose primary purpose has nothing to do with collections can also benefit from the ability to request and offer grain references. For example, a chat room could be enhanced by the ability to embed Sandstorm-aware links to other grains. Indeed, the latest release of Rocket.Chat does just that.
Although a fast startup time and a small memory footprint are important performance goals for any Sandstorm app, they are especially important for the Collections app, as it provides such a central piece of functionality. Collections need to be lightweight so that their integration with the rest of Sandstorm can feel seamless. Our primary strategy for achieving such performance has been to develop the Collections app using the Rust programming language, interfacing directly with Sandstorm’s Cap’n Proto interfaces . Rust has worked well so far, and along the way we have produced some libraries and examples to help others also get started using it for Sandstorm app development.
Whether or not you are a developer, now is an exciting time to get involved with Sandstorm. The powerbox is still in its early stages, and the Collections app is a hint at the kinds of things it will enable. So try it out and let us know what you think!
By Asheesh Laroia - 03 Aug 2016
In July, we introduced a new Sandstorm feature: Apps can notify users when something interesting happens within a grain. For example, Etherpad uses this to tell you when someone leaves a comment on a document. This ActivityEvent API was designed by Kenton Varda and its visual elements were designed by Néna Nguyễn. You can read more in its Cap’n Proto definition; any app within Sandstorm can use it. The easiest way to try it out is to make a new Etherpad document, then open it in an incognito window, and use the incognito window to leave yourself a comment.
This change, and many more, went live during July. To keep your Sandstorm server updated, you can sit back and relax. In the default configuration, Sandstorm’s automatic updates will install updates within 24 hours of a new release.
Here’s the full July changelog!
X-Sandstorm-App-
. Also, X-OC-Mtime
is whitelisted in responses, to improve Davros’ compatibility with ownCloud clients.By Asheesh Laroia - 13 Jul 2016
June’s big change is that we’ve reworked what first-time users see when using Sandstorm. There are speech bubbles guiding them to install an app, create a grain, and to take a look at the “Share access” interface, all powered by intro.js. I’m hopeful this helps people become productive and comfortable with Sandstorm faster than before.
It applies to all users, including demo users, so test it out by opening demo.sandstorm.io in an incognito window and click Try a quick demo.
Some readers will appreciate that this month, we also chased down a subtle memory leak caused by a lack of flow control in the HTTP implementation spread across proxy.js and sandstorm-http-bridge. You’ll find the details in pull request #2056.
Read the full changelog here, or visit your own Sandstorm server’s “About Sandstorm” section for a changelog at any time.
By Nena Nguyen - 29 Jun 2016
On July 19th, Sandstorm core dev Asheesh Larioa will be giving a talk about web packaging at our South Bay Sandstorm meetup.
Talk details
This talk covers how web app packaging works for Sandstorm.io. Asheesh will compare and contrast Sandstorm packaging against the typical install process on a Linux/Apache/MySQL/PHP system. This talk was featured at Debconf16, the yearly Debian conference.
He will outline how Sandstorm’s packaging tools do a few strange things to allow unprivileged users to install apps with one click:
• Every app package is a tiny Debian derivative, often as small as 20MB.
• Apps have no Internet connectivity to the outside world.
• Sandstorm uses a FUSE filesystem to identify which files are needed to run the app.
• An app bundles all its needed services, as well as files, resulting in one MySQL service per app.
• Users click and run one instance of an app like Etherpad per document, which is all handled transparently via a web app, a strategy that has neutralized 95% of 0-day web app vulnerabilities, based on our analysis.
• Developers on Mac OS and Windows can create packages for Sandstorm, even though Sandstorm is Linux-only, due to an emphasis on Linux VMs in our development tools.
Somehow we manage to make this scale reasonably well. Additionally, it is popular with upstream authors: of the >58 web apps packaged for Sandstorm, about 1/3 are maintained by their upstreams.
This talk focuses on how the Sandstorm packaging tools work, with community insights as well as technical ones, with the hopes of showing Debian how to more effectively package web apps for end users.
Come for the opportunity to meet others in the Sandstorm community, and work on your project with guidance from our core devs. This event will be held at RethinkDB in Mountain View on July 19. RSVP here.
By Nena Nguyen - 20 Jun 2016
At our Sandstorm meetup on June 16th, Sandstorm core dev Drew Fisher talked about an object-oriented programming inspired technique for designing secure systems called object-capability security.
Object-capability security is a technique for designing systems that lets us apply object-oriented design principles to security policies, reducing cognitive overhead and risk of errors that lead to vulnerabilities. In this talk, Drew explains capabilities, how they work, and what cool things they make possible for your systems, with real-world examples from Sandstorm.io.
Watch the full talk here:
To see the slides: http://zarvox.org/pycon2016-talk
To read more about capability-based security: https://sandstorm.io/how-it-works#capabilities
To read more on Cap’n Proto: https://capnproto.org/
We also have an upcoming meetup on July 19 where Asheesh is giving a talk entitled, “Web app packaging in Sandstorm: It’s not LAMP.” RethinkDB is kind enough to host our event at their office in Mountain View, and all are invited. Read the details & RSVP here.