Sandstorm: a Personal cloud platform (by Kenton Varda)

Kenton Varda, author of Cap'n Proto and the person responsible for open sourcing Protocol Buffers at Google, spoke at Talks at Sourcegraph about Sandstorm, a new project to provide a personal cloud platform for web applications.

Slides: http://sandstorm.io/slides
Video: https://www.youtube.com/watch?v=dlJYlM94fbE
Talks at Sourcegraph: http://www.meetup.com/Sourcegraph-Hacker-Meetup/

Transcript

1. Sandstorm.io Personal cloud platform Kenton Varda kenton@sandstorm.io sandstorm.io/slides
2. Personal Cloud Apps What is Sandstorm?
3. The demo tells all demo.sandstorm.io Just try it. 60 seconds.
4. Where does it run? Up to you: • Subscribe to shared hosting, or • Set up on your own machine. It’s open source! https://github.com/sandstorm-io
5. But I can already run a server... Sandstorm is different: • No config files. • No command lines. • App store. Like a phone. Ideal for techies and non-techies.
6. The Tech
7. Architecture Front-end Node.js + Meteor App Container proc proc proc App Container proc proc proc App Container proc proc proc Storage HTTP Cap’n Proto Users Filesystem
8. Architecture Sandboxing: • Linux containers (same syscalls as Docker). ◦ Native code — use any tech stack. • Reduced attack surface: seccomp, etc. • App package mapped read-only at /. • Per-instance storage at /var.
9. Architecture Fine-grained containers: • Share app code/assets read-only. • Shut down when not in use. Allows per-user or even per-document containerization.
10. Architecture Communication • RPC • Distributed objects • Promise pipelining
11. Architecture HTTP-over-RPC sandstorm-http-bridge for legacy apps.
12. Architecture Cloud “Devices” are protocols • Browser • E-mail (SMTP) • APIs • WebRTC, XMPP, IRC, BitTorrent, ...
13. Architecture User interface • App rendered in an iframe. • Unified login and sharing. • Proxy does authentication. • Shell (parent frame) can display system UI.
14. Architecture Powerbox: Mediates introductions • App A: “I implement interface Foo” • App B: “I need an instance of Foo” • System displays picker.
15. But why?
16. Why we need this End the Developer-Host
17. Why we need this 1. Developer-hosts are too powerful. • Spying/data-mining • Unwanted experiments • Privacy violations • Disappearing apps
18. Why we need this 2. Developer-hosts are walled gardens • Federated auth is hard ⇒ temptation to integrate only with first-parties. “if you want a definition of the term ‘walled garden’ as it pertains to technology, ask a man with both an iphone and a chromebook” - @malki
19. Why we need this OAuth? Painful for developers. Annoying/scary for users.
20. Why we need this 3. Enable open source and indie apps • Not all useful apps are monetizable. • Hobby projects don’t want to run servers. • You wouldn’t want to use their servers. • What good is “open source” if you can’t deploy your modified code?
21. Why we need this 4. Enterprise • Many companies won’t/can’t use SaaS. ◦ Privacy laws ◦ Competition • On-prem servers suck. ◦ High IT costs ◦ Poor integration ◦ Security
22. Why we need this 5. It’s inevitable. • 1990’s: AOL vs. WWW • 2010’s: SaaS vs. decentralized hosting We will win. Question is how soon.
23. Fund us! igg.me/at/sandstorm