[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.