[kentonv]

> The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox."

Heh, I'm not sure I'd describe Sandstorm as "leading" anything right now, but thanks. :)

I think Sandstorm made the problem more difficult for itself by not just trying to solve this UI problem, but trying to do it in a way that can be integrated into existing codebases that were never designed with capabilities in mind. This is the really difficult part: dealing with legacy code. The powerbox itself is otherwise "just a picker", a fairly straightforward concept.

For example, the standard file-open dialog box in everyone's browser, when invoked from an upload button on a web site, is actually a powerbox: the web site itself is given no access to any files except the one that the user chooses, but the file-open dialog is able to see everything.

But imagine trying to graft this approach onto an existing native app, that is used to being able to read the hard drive directly and already has its own custom file picker UI built in. You have to convince the developers of that app to remove their nice custom UI and instead invoke the system's UI. Moreover, when they invoke the file picker, they now don't get back a file name, but rather an already-open file descriptor. So their code has to be adjusted to not expect a name. This could be hard, depending on how the code is organized: maybe it uses a bunch of libraries that expect to open a file by name, etc.

Sandstorm is trying to graft this model onto apps that are used to making HTTP API requests to each other directly.

We had designs figured out to make this work, and even make most of the process look like an OAuth request, so that existing OAuth-based apps might not need to change very much... some of this is implemented, but mostly we just didn't get there before running out of money. (I am still working on it in my spare time, though!)

[urbit]

Protip: if no one's ahead of you, you're leading :-)

This is a great answer. I think the impedance-mismatch question is a big part of the problem. Personally I prefer to boil the ocean rather than drowning in the impedance-mismatch tarpit. Both of these strategies are, of course, profoundly insane.

It's true that a file-open dialog box easily becomes a powerbox. But of course, you are using the ambient authority of the user's login session to ascribe authority to the path that gets typed. So in a way it's the exception that proves the rule. And does a URL bar easily become a powerbox? What about a command-line shell?

Perhaps we're both just agreeing that there is always trivial ambient authority, and the right way to scale up to nontrivial cases is a capability model.

I just worry that when too many people discover the beautiful screwdriver that is capabilities, they decide that everything should be a screw. But the world has nails. It may even be true that the world should have nails. And then you find yourself pounding in nails with the butt of your screwdriver.

Have you considered an ICO? Asking for a friend :-)

[kentonv]

I agree that capability people tend to get too extreme, and this tends to lead to failure. With Sandstorm we've tried to be more pragmatic, but still careful not to do anything that breaks the whole model in the long run.

Whether or not the URL bar of a browser is a kind of powerbox depends on how extreme you want to get. In a pure capability model, yes, it would have to be. And hypertext would no longer be plain data -- it would be data with embedded capabilities (for each link), and would have to be transmitted via a protocol that can track capabilities. Obviously that kind of stuff, even though it would be amazingly powerful in a lot of ways, is not practical. :/

> Have you considered an ICO? Asking for a friend :-)

People keep asking me that, often citing Urbit as an example to follow. :) At the moment I'm having too much fun at my day job building Cloudflare Workers (an unusually practical project by my standards!), and want to focus my outside-of-work time on coding Sandstorm rather than fundraising for it. In the future, who knows.

[urbit]

If I can distill my objection to the pure capability model: there are two different statements of the capability manifesto, one strong and one weak.

The weak capability position is that it should be possible to construct an opaque combination of designator and authority, ie, a capability. The strong capability position is that designator and authority must always follow the same path.

So in the "pure capability model," you are actually subtracting a feature from the system. Now, of course, it's often the case that subtracting a feature makes a system better. But one needs to be really clear about confusing this with the positive virtues of just having capabilities.

Also, while I agree that capabilities are really great (Arvo has a somewhat capability-like internal communication model), it's important to point out that (a) capability vs. identity is a duality; and (b) it's cheating to compare a good capability system to a bad identity system.

For (a), note that identity systems can implement capability features like delegation and revocation; they just have to do it actively rather than passively. If I am willing to act as your deputy, I can delegate my power to act to you. Or some restricted subset thereof. Tell me what to do and I'll do it.

For (b), if you put a decent capability system next to the Internet, a network whose identity model is a burning-tire dumpster fire. If your identity system actually works and makes sense, competing is harder for the capability design.

I do think Urbit should have some kind of capability model. However, this has the feel of a 2.0 or even 3.0 feature. I hate to solve a problem until it is actually in my way. I feel we have come nowhere near the limits of the common case. A simple map from identity to privilege is certainly that.

And while capability UIs may be doable, identity UIs are trivial. This would not be the first case of humans being funky, hence screwing up our elegant architectural logic.

If you have a system software project and it can advance without being lashed to a company, definitely do it that way! It's always a poor fit -- they have to succeed on different timelines.

One thing I know: once we all have personal servers, today's cloud will look pretty lame in retrospect...

[abecedarius]

> capability vs. identity is a duality

Can you explain that more? Do you mean that both caps and ACL systems are ways to organize an access-control matrix, either by rows or by columns? Because I think that idea over-abstracts the reality.

[urbit]

Um, I think you just did. :-)

Of course, like every abstraction, this abstraction breaks down as you get into the details...

[abecedarius]

OK. For anyone else reading, the idea is a matrix "access(row, column)" where 'row' names an agent and 'column' names a resource, telling us whether the agent has permission to access the resource. A cap system breaks it out by rows: an agent has a list of capabilities; while an ACL system groups by columns: a file has a list of who can access it. This point of view seems to stand above either approach and make them look complementary.

The most important things left out of that view I think are the way an agent expresses its intent (vs. ambient authority) and the way the whole system changes over time. I started writing some more, but it's late and http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf goes into this at length, so I'll just leave that here.

[pugz]

(You're probably already much more familiar with it than I am, but if not:)

Your example of the file open dialog box is identical to what Apple did on MacOS when they implemented sandboxing. Rather than using regular paths in NSString objects, they return you an NSURL with a "security scope" - a capability. These can be saved and reused across process terminations.

The docs provide useful information how they are used: https://developer.apple.com/documentation/foundation/nsurl