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.
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.
Macaroons are probably more interesting to people who don't already have a CapTP-like capability framework to build on. While you could express sturdy refs and live refs in terms of Macaroons, you can also express all sorts of things with less-than-ideal security properties too. There's a very nice conceptual purity to object capability systems like Cap'n Proto.
That said, Sandstorm is doing some pretty impressive mappings of capabilities to web applications. Really interesting work!
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?
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.
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.
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?
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/, 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.
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.
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...