Comparing capability systems

[Alan Karp]

I've been asked to write a pros and cons of different types of capability systems.  

The first piece is listing the types.  I have object references, such as endosjs.org, opaque tokens, such as waterken, and certificates, such as zcaps and Macaroons.  Are there other categories?

The next piece is listing the actual pros and cons.  I'd appreciate any input you have.

--------------
Alan Karp

[Pierre Thierry]

Le 05/03/2026 à 17:05, Alan Karp a écrit :

The first piece is listing the types.  I have object references, such as endosjs.org, opaque tokens, such as waterken, and certificates, such as zcaps and Macaroons.  Are there other categories?

Maybe opaque tokens could be divided among swiss numbers and encrypted certificate-like data? In the certificates category, Biscuit should probably be mentioned.

The next piece is listing the actual pros and cons.  I'd appreciate any input you have.

I'd say among the most prominent features of certicates is a dual of pros and cons: they don't need a SPOF/bottleneck, but if you choose them because that property is important to you, it means you can't have up-to-date revocation lists. I think macaroons don't make this possible, but zcaps and Biscuits can be attenuated without communicating with anyone in the delegation chain.

When capabilities are tokens made of bits, an important cons is that you lose the confinement property.

Curiously,
Pierre Thierry
--

pie...@nothos.net
0xD9D50D8A

[Chris Hibbert]

On 3/5/26 8:05 AM, Alan Karp wrote:
>
> The first piece is listing the types.  I have object references, such as

> endosjs.org <http://endosjs.org>, opaque tokens, such as waterken, and

> certificates, such as zcaps and Macaroons.  Are there other categories?

Do hardware solutions, where the reference is an address count as a
different type?

Chris
--
It is easy to turn an aquarium into fish soup, but not so
easy to turn fish soup back into an aquarium.
-- Lech Walesa on reverting to a market economy.

Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
http://mydruthers.com

[Alan Karp]

On Thu, Mar 5, 2026 at 9:10 AM Pierre Thierry <pie...@nothos.net> wrote:

Le 05/03/2026 à 17:05, Alan Karp a écrit :

Maybe opaque tokens could be divided among swiss numbers and encrypted certificate-like data? In the certificates category, Biscuit should probably be mentioned.

The only significant difference between a swiss number like token and an encrypted certificate that the holder can't decrypt seems to me to be where you hold the associated metadata.  

Nice catch on Biscuit.  I've added it to the list.

The next piece is listing the actual pros and cons.  I'd appreciate any input you have.

I'd say among the most prominent features of certicates is a dual of pros and cons: they don't need a SPOF/bottleneck, but if you choose them because that property is important to you, it means you can't have up-to-date revocation lists.

I haven't seen SPOF used to justify certificates.  Offline delegation is the usual reason.

The best justification for opaque tokens is performance because you don't need to validate signatures.  We designed an opaque token system for HPE because they wanted to handle many thousands of requests per second per server.  Each request needed only one hashmap lookup per element in the delegation chain.

Isn't the freshness of the revocation list the same?  For both types, you send a message to the resource saying to stop honoring the delegation.

I think macaroons don't make this possible, but zcaps and Biscuits can be attenuated without communicating with anyone in the delegation chain.

The holder of a Macaroon can create a new one with attenuated permission as with zcaps and Biscuits. 

When capabilities are tokens made of bits, an important cons is that you lose the confinement property.

Why don't you also lose the confinement property with others, such as zcaps?  If I can share a token made of bits with you, I can share a zcap and the corresponding secret key with you.

--------------
Alan Karp

[Mark S. Miller]

There are (at least) two orthogonal dimensions. The abstract access control model and the implementation substrate.

Capability Myths Demolished https://papers.agoric.com/papers/capability-myths-demolished/full-text/ distinguishes 4 main access control models: ACLs as columns, Capabilities as rows, Capabilities as keys, and Object-Capabilities. It differentiates these by 6 criteria. 

I would add Alan's Split Capabilities as a distinct capability-oriented access control model.

Cap Myths Demolished then classifies several actual systems according to these same six criteria

This classification is still orthogonal to the implementation substrate.

The primary implementation substrates, in chronological order of invention, are:

OS (Dennis and Van Horn 1965), Capability OS golden age in the 1970s, KeyKOS, EROS, CapROS, Coyotos, seL4, Capsicum

Hardware or mixed Hardware/OS (Cambridge CAP system 1970), Intel 432 (horror), CHERI and CHERI-like (ARM)

Dynamic Language (Gedanken "Protection in Programming Languages" 1973), Actors, Vulcan, Joule, W7, E, Monte, HardenedJS. (Erlang is close to caps.)

"Static" languages (Emily 2006), Joe-E, Tamed PICT, local-Midori. (Rust without libraries is close to caps.)

Live cryptographic protocols (DCCS 1970s I think), Indra (for Joule), CapTP family (E's CapTP, Midori, Cap'n Proto, ocapn)

Offline cryptographic certificate systems (SPKI/SDSI 1996), CapCert (never implemented)

Alan, there were two generations of Client Utility. The first was split capabilities are the second started with SPKI/SDSI. I'll leave it to you to expand on how it fits.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1s9-D_XnF7wr1toLBPqCDWuQfPDqx2OA-ZkCrYRbOzAA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

I listed E as in the language category. You likewise listed Endo as in the language category. In fact, both are a combo of a local dynamic ocap language (local-E, HardenedJS) and a live crypto-cap protocol (E's CapTP, ocapn)

I am also inclined to include ocap-oriented UIs, first, as another implementation substrate. Due to human limitations, these usually have a different abstract access control model (petnames, transitive selective revocability as the default form of delegation). These include CapDesk, SCoopFS, The Familar (Endo's in progress UI).

Above, I also failed to give enough credit to Waterken and Spritely.

Waterken used Joe-E as the local language and introduced its own live crypto-cap protocol, which I would still classify as being in the CapTP family. YMMV. 

Spritely started with W7 and therefore Scheme as its local language, but then added builtin time travel. Spritely and Endo jointly use ocapn as the live crypto-cap protocol.

A third orthogonal axis is the persistence and upgrade model.

Agoric's use of Endo starts with orthogonal persistence just to ensure that all honest validators produce the same deterministic computation, independent of whether they crashed and started or they just continued. This leaves upgrade as a separate problem. Agoric does both state-based upgrade (via Exos) and relay based "Manchurian" upgrade (via async-flow). We expect that both forms of upgrade will migrate to Endo, but we do not expect non-consensus use of Endo to support orthogonal persistence. Rather, the durable state of state-based upgrade will also provide persistence.

Mostly separately, Endo supports formula-based persistence and upgrade, already reflected in the Endo cap-oriented UI, the Familiar.

--

  Cheers,
  --MarkM

[Mark S. Miller]

Yes, zcaps definitely falls in the offline cert caps category. Yes, Macaroons is close enough that it is at least adjacent to that category.

Spritely also has an ocap-oriented UI (the Agency) with at least petnames. I don't know about revocability.

Plash is both a dynamic language and a command-line UI, depending on how you want to describe it.

--

  Cheers,
  --MarkM

[Mark S. Miller]

See also Part IV (Related Work) of Robust Composition (2006) https://papers.agoric.com/papers/robust-composition/abstract/

--

  Cheers,
  --MarkM

[Mark S. Miller]

Part V that is.

--

  Cheers,
  --MarkM

[Mark S. Miller]

Much more comprehensive lists at https://github.com/dckc/awesome-ocap

--

  Cheers,
  --MarkM

[Mark S. Miller]

In the UI category: Belay https://www.youtube.com/watch?v=2_5p6S2eW8s&t=1s

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Thu, Mar 5, 2026 at 12:14 PM Mark S. Miller <eri...@gmail.com> wrote:

I listed E as in the language category. You likewise listed Endo as in the language category. In fact, both are a combo of a local dynamic ocap language (local-E, HardenedJS) and a live crypto-cap protocol (E's CapTP, ocapn)

I am also inclined to include ocap-oriented UIs, first, as another implementation substrate. Due to human limitations, these usually have a different abstract access control model (petnames, transitive selective revocability as the default form of delegation). These include CapDesk, SCoopFS, The Familar (Endo's in progress UI).

Above, I also failed to give enough credit to Waterken and Spritely.

Waterken used Joe-E as the local language and introduced its own live crypto-cap protocol, which I would still classify as being in the CapTP family. YMMV. 

Spritely started with W7 and therefore Scheme as its local language, but then added builtin time travel. Spritely and Endo jointly use ocapn as the live crypto-cap protocol.

A third orthogonal axis is the persistence and upgrade model.

Agoric's use of Endo starts with orthogonal persistence just to ensure that all honest validators produce the same deterministic computation, independent of whether they crashed and started or they just continued. This leaves upgrade as a separate problem. Agoric does both state-based upgrade (via Exos) and relay based "Manchurian" upgrade (via async-flow). We

Not "relay based". Should be "replay based"

 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYgR%2BGkidv8v6jMSi5%2Bk80DiOEFEGkDhzoL7SiBeEXt%2BDw%40mail.gmail.com.

[Mark S. Miller]

From Robust Composition:

> Object-capability systems differ regarding concurrency control, storage management, equality, typing, and the primitiveness of messages, so we avoid these issues in our model.

Thus, each of these are further dimensions of classification.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD57_zwLRTfQ1fa%3DtaPZJTr04ycShGMtZObNOXJJm9pRpA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Matt Rice]

On Thu, Mar 5, 2026 at 8:54 PM Mark S. Miller <eri...@gmail.com> wrote:

From Robust Composition:

> Object-capability systems differ regarding concurrency control, storage management, equality, typing, and the primitiveness of messages, so we avoid these issues in our model.

Thus, each of these are further dimensions of classification.

I also feel like you could perhaps argue that whether messages cross either trust boundaries, or fault boundaries or reliability guarantees could be a dimension of classification.  In the sense that Alice's machines may be within the same trust boundary, yet crash independent of one another, compared with Alice and Bob's machines individually being within different trust boundaries. Others exist only in isolation. *shrug*

[Alan Karp]

The focus of the group is on cross domain delegation to, by, and between AI agents, so I don't know how much interest there is in UI issues.  I've thrown the link in my document just in case.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYj0NvHkoe-zc5SjxZQKEyd_9JphAsmeOci9q5PHRQFbig%40mail.gmail.com.

[Mark S. Miller]

Thanks, I missed that. Where it comes up repeatedly for me is the issue of network partition and endpoint crash/revival. This dimension is somewhat distinct from persistence/upgrade, but obviously the two must be co-designed. E and Waterken are both communicating event-loops with a local ocap language and a distributed live ocap protocol. However, they took opposite stances on distributed error handling:

Waterken masks partition and crash/revival. A network partition is, to the Waterken programmer, just a slow network. Every crashed machine is just a slow machine. Every sent message is still delivered exactly once, independent of these low-level problems. Agoric's use of Endo following the Waterken failure model.

E had live refs vs sturdy refs. You send messages on live refs, until the connection carrying the live ref breaks. Connections are broken when a keep-alive exceeds a timeout. Live refs once broken stay broken.

Sturdy refs are long lived caps that do not depend on connection liveness. But you don't send a message on a live ref. Rather, you use it only to get a new live reference to the object designated by the sturdy ref.

distributed error model is entangled both with persistence and upgrade model and with the distributed deallocation model, such as distributed acyclic gc, which is another dimension of variation.

Also entangled with message ordering, such as FIFO vs E-Order.

 

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CACTLOFqf0wMY%3D_LNgDyDPGuVPYWOHPAzQfHJpZcD9aXF_VCYsg%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Bakul Shah]

What is the purpose of this exercise?

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1s9-D_XnF7wr1toLBPqCDWuQfPDqx2OA-ZkCrYRbOzAA%40mail.gmail.com.

[Alan Karp]

On Thu, Mar 5, 2026 at 1:54 PM 'Bakul Shah' via friam <fr...@googlegroups.com> wrote:

What is the purpose of this exercise?

That's the right question, and I should have answered in my original email.  I'm also glad that I didn't because I might not have gotten the wealth of material sent by Mark Miller.

I am participating on the Delegation Subcommittee of the Trusted AI Agent Working Group of the Distributed Identity Foundation.  (Quite a mouthful, that.)  Our goal is to provide a spec for delegating permissions to, by, and between AI agents, which means we're only interested in distributed use cases for general resources.  The group has decided to use capabilities, but the restrictions rule out hardware (CHERI), OS (sel4), purely local ocaps, and resource specific solutions such as Tahoe LAFS.  I expect we'll end up with zcaps, but the group wants a strong justification for that choice.

I provided the group with a list of about a dozen capability or capability-adjacent (e.g., OAuth 2) systems.  At today's meeting, we went through the exercise of seeing how to implement Stiegler's 7 aspects of sharing (his 6 plus revocation) with OAuth 2.  It took most of the meeting.  Since I don't want to spend the next 3 months working through the options, I thought we could do that exercise for each of a few types, opaque tokens (Waterken), digital certificates (zcaps), and distributed object references (E).  

My thinking is that attenuated delegation with opaque tokens can be done with token exchange, independent of the specific system.  Similarly, certificate systems allow for offline delegation, whether they are signed (zcap) or hashed (Macaroons).  My hope is that showing how each of the 3 types can be used to implement the 7 aspects of sharing will suffice.

One solution that always works is caretakers, but there are cost, resource consumption, resilience, and performance concerns.  Also, you don't know ahead of time what caretakers you might need because AI agents develop the solution strategy as they go along.  On the other hand, an AI agent might be able to code any caretaker it needs.

--------------
Alan Karp

[Alan Karp]

On Thu, Mar 5, 2026 at 12:14 PM Mark S. Miller <eri...@gmail.com> wrote:

I listed E as in the language category. You likewise listed Endo as in the language category. In fact, both are a combo of a local dynamic ocap language (local-E, HardenedJS) and a live crypto-cap protocol (E's CapTP, ocapn)

Our goal is to define a protocol but not a programming model for whatever capability system we select.  I know you can probably build a system where each vat has its own style of capabilities, but I haven't seen anyone do that for language based capabilities.  We did it with certificates; Zebra Copy was built with J2EE talking to .Net.

I am also inclined to include ocap-oriented UIs, first, as another implementation substrate. Due to human limitations, these usually have a different abstract access control model (petnames, transitive selective revocability as the default form of delegation). These include CapDesk, SCoopFS, The Familar (Endo's in progress UI).

The group hasn't discussed UI, but we certainly should.

Above, I also failed to give enough credit to Waterken and Spritely.

Waterken used Joe-E as the local language and introduced its own live crypto-cap protocol, which I would still classify as being in the CapTP family. YMMV. 

That's where I put them, too.

Spritely started with W7 and therefore Scheme as its local language, but then added builtin time travel. Spritely and Endo jointly use ocapn as the live crypto-cap protocol.

Same category as E/Waterken/Joe-E?

A third orthogonal axis is the persistence and upgrade model.

Good point.  I've added that to our list of considerations.

Agoric's use of Endo starts with orthogonal persistence just to ensure that all honest validators produce the same deterministic computation, independent of whether they crashed and started or they just continued. This leaves upgrade as a separate problem. Agoric does both state-based upgrade (via Exos) and relay based "Manchurian" upgrade (via async-flow). We expect that both forms of upgrade will migrate to Endo, but we do not expect non-consensus use of Endo to support orthogonal persistence. Rather, the durable state of state-based upgrade will also provide persistence.

Mostly separately, Endo supports formula-based persistence and upgrade, already reflected in the Endo cap-oriented UI, the Familiar.

I don't understand very much of the previous 2 paragraphs, but it sounds interesting.  Maybe I'll be able to learn about it when the committee work is done.

 

--------------
Alan Karp

[Alan Karp]

On Thu, Mar 5, 2026 at 12:21 PM Mark S. Miller <eri...@gmail.com> wrote:

Plash is both a dynamic language and a command-line UI, depending on how you want to describe it.

It looks like Plash is not distributed.  Is that right?

--------------
Alan Karp

[Matt Rice]

Sorry about replying to such an older thread... afaict the current thread mostly focuses on differences between mechanisms.

I was kind of thinking there was a separate dimension in regards to what resources are actually governed by capabilities.

E.g. in many of the dynamic language and static language (w7 I believe & emily) are built upon garbage collected languages, where

allocators are available ambiently. While many of the OS capabilities in Mark's list *do* consider allocation to be an attenuable resource.

Then of those, the MCS branch of seL4 seems to consider beyond space, where time is also an attenuable resource. Perhaps there are systems where space (memory) and (persistent) space are considered distinctly from one another giving one ambient allocation but limits on persistent storage.

As far as I know the distinction currently falls pretty uniformly across OS/Language caps with OS caps generally treating allocation as more of a resource. But I don't think it is necessarily so.  We could imagine a language cap system with capability ownership requirements for allocation.

You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CAK5yZYhFv_uixWa4-etroCJvcLrX0-BwRaTiofx66M%2BrCRbdXA%40mail.gmail.com.

[Rob Meijer]

This touches very much on something that I've been strugling with for the design of a "quota" enting-membrane for a DSL I'm working on. 

I used to think allocation, both for persisten and ephemeral storage is pretty much handled by the right to "ent" or graft the allocated thing somewhere into your scope. 

As such, in my DSL I worked on the option to merge (import) function with a freeze on merge "export" branch (that is where all the scoped variables and constants live). That basicly would result in a situation that you can't allocate anything not allocated already  by the import action because you cant assign it to anything. 

But the more I think about it, the more I realize that the important divide isn't between being allowed to allocate or not to allocate, but between being able to allocate a few trivial small things or either be allowed to allocate countless small things, or big things. It's less about the capabity to allocate and more about how much of the storage resource you are allowed to use up. 

I'm holding on to the enting (grafting) moment as gatekeeping moment because doing otherwise would make me have to go back to the drawing board for the entire DSL, and I'm now strugling to design a quata membrane for enting operations. Once I have the membrane sorted (I hope I will), I'll need to look into how I can best make it fit with the import system. 

I'm not sure if the on-ent moment is the best place to put in the authority decision, but it does seem a very practical one. 

On Sat, 4 Apr 2026, 08:32 Matt Rice, <rat...@gmail.com> wrote:

Sorry about replying to such an older thread... afaict the current thread mostly focuses on differences between mechanisms.

I was kind of thinking there was a separate dimension in regards to what resources are actually governed by capabilities.

E.g. in many of the dynamic language and static language (w7 I believe & emily) are built upon garbage collected languages, where

allocators are available ambiently. While many of the OS capabilities in Mark's list *do* consider allocation to be an attenuable resource.

Then of those, the MCS branch of seL4 seems to consider beyond space, where time is also an attenuable resource. Perhaps there are systems where space (memory) and (persistent) space are considered distinctly from one another giving one ambient allocation but limits on persistent storage.

As far as I know the distinction currently falls pretty uniformly across OS/Language caps with OS caps generally treating allocation as more of a resource. But I don't think it is necessarily so.  We could imagine a language cap system with capability ownership requirements for allocation.

This touches very much on a design issue I

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFo8keTb%3D20HzGAh0s5L1F-Oapz3kAa3pWbUydJhtAii5g%40mail.gmail.com.

[Matt Rice]

On Sat, Apr 4, 2026 at 8:41 AM Rob Meijer <pib...@gmail.com> wrote:

This touches very much on something that I've been strugling with for the design of a "quota" enting-membrane for a DSL I'm working on. 

I used to think allocation, both for persisten and ephemeral storage is pretty much handled by the right to "ent" or graft the allocated thing somewhere into your scope. 

As such, in my DSL I worked on the option to merge (import) function with a freeze on merge "export" branch (that is where all the scoped variables and constants live). That basicly would result in a situation that you can't allocate anything not allocated already  by the import action because you cant assign it to anything. 

But the more I think about it, the more I realize that the important divide isn't between being allowed to allocate or not to allocate, but between being able to allocate a few trivial small things or either be allowed to allocate countless small things, or big things. It's less about the capabity to allocate and more about how much of the storage resource you are allowed to use up. 

Yeah, indeed I probably did a poor job of conveying that, but that was basically what I meant by "attenuable resource", an allocation limit that could be subdivided. Basically how keykos spacebanks worked. In theory "TimeBanks" could work similarly, subdividing a schedule/time slice. I struggle to think of what other kinds of resources could be subdivided. Presumably I suppose you could apply the principle to battery power, bandwidth? *shrug* 

 

To view this discussion visit https://groups.google.com/d/msgid/friam/CAMpet1UrcyMnOAT6GO_q92USWMisYYPEtDdn3jk1UNcFQwZqNA%40mail.gmail.com.

[Rob Meijer]

On Sat, 4 Apr 2026, 11:06 Matt Rice, <rat...@gmail.com> wrote:

On Sat, Apr 4, 2026 at 8:41 AM Rob Meijer <pib...@gmail.com> wrote:

This touches very much on something that I've been strugling with for the design of a "quota" enting-membrane for a DSL I'm working on. 

I used to think allocation, both for persisten and ephemeral storage is pretty much handled by the right to "ent" or graft the allocated thing somewhere into your scope. 

As such, in my DSL I worked on the option to merge (import) function with a freeze on merge "export" branch (that is where all the scoped variables and constants live). That basicly would result in a situation that you can't allocate anything not allocated already  by the import action because you cant assign it to anything. 

But the more I think about it, the more I realize that the important divide isn't between being allowed to allocate or not to allocate, but between being able to allocate a few trivial small things or either be allowed to allocate countless small things, or big things. It's less about the capabity to allocate and more about how much of the storage resource you are allowed to use up. 

Yeah, indeed I probably did a poor job of conveying that, but that was basically what I meant by "attenuable resource", an allocation limit that could be subdivided. Basically how keykos spacebanks worked. In theory "TimeBanks" could work similarly, subdividing a schedule/time slice. I struggle to think of what other kinds of resources could be subdivided. Presumably I suppose you could apply the principle to battery power, bandwidth? *shrug* 

 

From your list of resources, and more so from what is missing from the list (things like entropy space), I'm getting the impression it's not the subdivision of the resource that makes these resources different, but the implied thin provisioning. 

In my project I'm using strict pre-alocation for entropy, and this is the most straight forward solution. But for grafting quota membranes allowing some level of overcommit makes it a bit more involved. 

My gut tells me that a least authority language should somehow limit how strong an overcommit is possible, but I neither know if this gut feeling is correct, or if it is, how to quantify it or express it. 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFopmV%2BLcrWRyC02eng8%2BOdzLAOCjBXU7iFZvz0UJKWGvQ%40mail.gmail.com.

[Matt Rice]

On Sat, Apr 4, 2026 at 2:56 PM Rob Meijer <pib...@gmail.com> wrote:

On Sat, 4 Apr 2026, 11:06 Matt Rice, <rat...@gmail.com> wrote:

On Sat, Apr 4, 2026 at 8:41 AM Rob Meijer <pib...@gmail.com> wrote:

This touches very much on something that I've been strugling with for the design of a "quota" enting-membrane for a DSL I'm working on. 

I used to think allocation, both for persisten and ephemeral storage is pretty much handled by the right to "ent" or graft the allocated thing somewhere into your scope. 

As such, in my DSL I worked on the option to merge (import) function with a freeze on merge "export" branch (that is where all the scoped variables and constants live). That basicly would result in a situation that you can't allocate anything not allocated already  by the import action because you cant assign it to anything. 

But the more I think about it, the more I realize that the important divide isn't between being allowed to allocate or not to allocate, but between being able to allocate a few trivial small things or either be allowed to allocate countless small things, or big things. It's less about the capabity to allocate and more about how much of the storage resource you are allowed to use up. 

Yeah, indeed I probably did a poor job of conveying that, but that was basically what I meant by "attenuable resource", an allocation limit that could be subdivided. Basically how keykos spacebanks worked. In theory "TimeBanks" could work similarly, subdividing a schedule/time slice. I struggle to think of what other kinds of resources could be subdivided. Presumably I suppose you could apply the principle to battery power, bandwidth? *shrug* 

 

From your list of resources, and more so from what is missing from the list (things like entropy space), I'm getting the impression it's not the subdivision of the resource that makes these resources different, but the implied thin provisioning. 

In my project I'm using strict pre-alocation for entropy, and this is the most straight forward solution. But for grafting quota membranes allowing some level of overcommit makes it a bit more involved. 

My gut tells me that a least authority language should somehow limit how strong an overcommit is possible, but I neither know if this gut feeling is correct, or if it is, how to quantify it or express it. 

I know Norm's site had a fairly concrete dive into how to implement overcommit, but I'm not currently able to find it.

But here are two things, one discussing the original design of the keykos space bank http://cap-lore.com/CapTheory/KK/OrgId.html

and another discussing promptness, http://cap-lore.com/CapTheory/KK/Prompt.html

a property of space banks.

Essentially a prompt bank was able to promptly respond to allocations with the pages allocated, while a non-prompt bank

may need to use some mechanism to free space before it can produce the pages. The design seems like it was in flux due to the covert channel discussed therein with multiple proposals to close the channel. It has been a long time since I looked at these aspects in depth & certainly don't consider my memory trustworthy on the details. But I don't think it attempted to limit the amount of overcommit, all the system provided space banks IIRC were prompt, but non-prompt banks could be provided through something like a subtyping relation. So presumably whichever bank you substituted could have some restriction for the magnitude of overcommit, but there were things that cared about having prompt banks.

 

To view this discussion visit https://groups.google.com/d/msgid/friam/CAMpet1U48gSt-VbYt%2BcdgbCCaztp5Lk-mJBOdXeBMjxfR0XWtg%40mail.gmail.com.