

Delegation Is the Cornerstone of Civilization: Sharing in Sandstorm.io - mjs
https://blog.sandstorm.io/news/2015-05-05-delegation-is-the-cornerstone-of-civilization.html

======
evancordell
Capability-based access control is fascinating. Here's an interesting article
about capabilities vs. ACLs:
[http://www.erights.org/elib/capability/duals/myths.html](http://www.erights.org/elib/capability/duals/myths.html)

I'm also a fan of Macaroons for this purpose, which I was disappointed to see
weren't being used here. But for an example of using macaroons as capabilities
in practice, see: [http://hackingdistributed.com/2014/11/23/macaroons-in-
hyperd...](http://hackingdistributed.com/2014/11/23/macaroons-in-hyperdex/)

~~~
kentonv
This particular article was discussing user-to-user sharing, which generally
happens through the user interface between authenticated users interacting
with the live Sandstorm server. Since all the actual work happens inside the
Sandstorm server, there isn't much need for Macaroons.

App-to-app sharing is a different matter. We are working on allowing an app to
receive a capability to access another app, and it should of course be able to
delegate that capability to other apps. (Delegation is even more important
between apps than it is between users, because we want to be able to write
small, modular apps that work together rather than monolithic apps.)

At this level, Sandstorm sharing is based on Cap'n-Proto-style capabilities.
Cap'n Proto has concepts similar to macaroons but takes a different approach
in that we prefer that all sharing must happen "live" so that the server can
keep track of who has what.

When you have an open Cap'n Proto RPC connection and have received a
capability (object reference) over that connection, that's called a "live
ref". Cap'n Proto allows live refs to be passed from machine to machine
(delegated) in RPC messages. But if the connection dies, all live refs are
lost. So, to keep it long term, you want to convert it to a "study ref", which
is a byte string you can save to disk.

A sturdy ref, however, can only be restored to a live ref by the same entity
who saved it, where "entity" is some course-grained authenticatable identity.
The idea here is that if a hacker manages to obtain a raw copy of your
database, you don't want to have to revoke every sturdy ref contained therein.
A course authentication component prevents them from doing anything with any
of those tokens.

Macaroons are also a byte string that grant access to a resource, with a
format that allows you to attenuate the capability offline. That is, if I have
a macaroon allowing read-write access to a document, I can create a new
macaroon that gives only read access, and then pass that to someone else, all
without consulting the document's server.

For Sandstorm, we actually don't quite want that, because we want the document
owner to be able to see how their document has been shared. So, to share a
sturdy ref, we require you to restore it to a live ref and delegate that. The
recipient can save a new sturdy ref tied to them.

~~~
evancordell
Thanks for the detailed comparison! Sounds like you are doing some really
interesting things and sandstorm.

I've looked at Capnproto in the past but did not read through the
documentation thoroughly enough to see the bits about capabilities (or the
link to the pdf version of the same myths article I linked above!)

>For Sandstorm, we actually don't quite want that, because we want the
document owner to be able to see how their document has been shared. So, to
share a sturdy ref, we require you to restore it to a live ref and delegate
that. The recipient can save a new sturdy ref tied to them.

@bascule alluded to this, but this can actually be very nicely modeled with
macaroons! The idea would be to create a capability-granting macaroon but
attach a "third party caveat" that asserts the grantee must be able to prove
they are the "authenticatable identity". You end up with the same properties
as the live/sturdy refs, if I understand properly.

Mostly it's just cool to see different implementations of capability-based
access control.

------
jonahx
From their homepage, "this is the only way to make Open Source web apps
viable." What does viable mean in this context? Why is this service different
from hosting on heroku or my own free Amazon instance? Is it just convenience
or is there something more?

~~~
kentonv
Basically, heroku or random IaaS providers require some level of technical
expertise and time commitment to run. That drastically limits who will use
them, leading proprietary SaaS providers to dominate the market. If open
source and federated web apps were easy and safe for everyone to run, they'd
have a wider audience. Sandstorm aims to make that the case.

Longer version: [https://blog.sandstorm.io/news/2014-07-21-open-source-web-
ap...](https://blog.sandstorm.io/news/2014-07-21-open-source-web-apps-require-
federated-hosting.html)

~~~
jonahx
Thank you for answering. After reading that, it sounds very cool and is a
great vision. Please take it as constructive criticism that I had _no idea_
based on the homepage that the product was anything like what is described in
the blog. I get that it's not necessarily easy to describe a new paradigm in a
few tag lines, but there's probably room for improvement.

~~~
kentonv
Yeah, I think we need to convince more people to try the demo, or maybe just
throw a video of the demo on the front page. Out of curiosity, what made you
not try it at first? Did you expect it to take a long time? What might have
convinced you to try?

~~~
jonahx
Actually, one of my first actions was to click the demo button in the top nav,
then I got the page with the big blue button that said "Start Demo," and at
this point I was already a little skeptical because typically I expect "Demo"
in a web app to take me right into some app I'm about to use. But I clicked
the big blue button and then saw this page:
[https://demo.sandstorm.io/](https://demo.sandstorm.io/), which felt like an
admin panel that was going to take some effort to understand -- at this point
I gave up.

This is, of course, totally unfair to you, and was based on assumptions that
don't apply to your product, but there you have it. It's even worse, because
I'm a developer and with just a little effort could have understood
everything, but since it wasn't immediately obvious, I made the assumption
that the business model itself was vague, or didn't apply to me, as is often
the case with SaaS products.

Pretty standard Steve Krugg "Don't Make Me Think" stuff, but accurate to my
experience when I'm just casually checking something out.

~~~
kentonv
Thanks, that's great feedback. Yeah, I guess we need some way to show that
clicking "install apps" will be easy and fast.

~~~
jonahx
To offer a couple of hopefully useful ideas, you could:

1\. Have the demo take you directly to the page where you choose an app,
rather than to the admin page which manages your installed apps.

2\. Focus even more on the "like installing phone apps but for websites"
metaphor. I think that metaphor works very well as soon as you understand it,
and elicits a "Yeah... why _don 't_ web apps work like that?" epiphany.

3\. Continuing 2., you might consider focusing the home page advertising on
the most popular apps themselves (more than you do currently), rather than the
conceptual idea that you can install your own apps (which is harder to grok,
or at least to differentiate from heroku et al). Ie, "Run your own X in 10
seconds", where X is something I already know and think is cool, might be
easier to understand, and more motivating. Just as most users think of their
phones as indistinguishable from the specific apps they love and use every
day, rather than as an abstract platform for running those apps.

