Slide 1

Slide 1 text

Sandstorm.io Personal cloud platform Kenton Varda [email protected] sandstorm.io/slides

Slide 2

Slide 2 text

Personal Cloud Apps What is Sandstorm?

Slide 3

Slide 3 text

The demo tells all demo.sandstorm.io Just try it. 60 seconds.

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

The Tech

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

Architecture Fine-grained containers: ● Share app code/assets read-only. ● Shut down when not in use. Allows per-user or even per-document containerization.

Slide 10

Slide 10 text

Architecture Communication ● RPC ● Distributed objects ● Promise pipelining

Slide 11

Slide 11 text

Architecture HTTP-over-RPC sandstorm-http-bridge for legacy apps.

Slide 12

Slide 12 text

Architecture Cloud “Devices” are protocols ● Browser ● E-mail (SMTP) ● APIs ● WebRTC, XMPP, IRC, BitTorrent, ...

Slide 13

Slide 13 text

Architecture User interface ● App rendered in an iframe. ● Unified login and sharing. ● Proxy does authentication. ● Shell (parent frame) can display system UI.

Slide 14

Slide 14 text

Architecture Powerbox: Mediates introductions ● App A: “I implement interface Foo” ● App B: “I need an instance of Foo” ● System displays picker.

Slide 15

Slide 15 text

But why?

Slide 16

Slide 16 text

Why we need this End the Developer-Host

Slide 17

Slide 17 text

Why we need this 1. Developer-hosts are too powerful. ● Spying/data-mining ● Unwanted experiments ● Privacy violations ● Disappearing apps

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Why we need this OAuth? Painful for developers. Annoying/scary for users.

Slide 20

Slide 20 text

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?

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

Fund us! igg.me/at/sandstorm