ADR 003 follow-up

[cwgoes]

Notes from @warner:

• Representing as opaque pointers is fine, they are unforgeable
• Storing as a map from name to pointer OK as long as scope of lookup is well understood
  C-list - some agent gets access to set of authorities. Agent's access to clist table not forgeable (currently this is in app.go).
• Single owner per capability feels a bit wrong. Multi-owner? Different types? Multi-owner maybe simpler.
• Capabilities remembering name = kinda wrong? Exclusive access, claim function doesn't take name, instead takes pointer (but pointer is to capability with name)
• Agoric's approach: names only exist in clist, capabilities don't have a name, capability-lists are scope-local (e.g. to scoped keeper) - we need clist of identities, though, since we have to restore it.
• Exercise capability - feels a bit weird to provide both name & pointer, receiver module should look up the capability name with the pointer

What we want @cwgoes : ability to give up capability ownership (e.g. give up channel).
@warner : Ocap world usually doesn't do this
@deantribble : There are models where you can.

For channels: tx/rx split should use separate capabilities.

Receive packet patterns (callback vs OpaquePacket receive) / how does this relate?

Sender will want ability to transfer where receiver can claim & where they cannot.

To-do:

• Scoped-keeper-local name-spacing for access, opaque global identity table
• Think about single-owner / multi-owner / revokability / claiming questions

[cwgoes]

Will Agoric use this (Swingset = multiple module) or not (Swingset = single module)?

[cwgoes]

I concur with @warner that namespacing should be scoped-keeper-local.

I / we are undecided as to the questions of single/multi-owner and revokability/claimability. Which design patterns make sense depend a lot on the intended use-cases, and we don't understand those too concretely yet.

I plan to update the ADR to reflect the namespacing change & these questions.

I want to note that implementation of this ADR is not required for wire-compliant IBC, and we could elect to leave it out of the first live version if we don't think any SDK applications will need it. I think it is worth having a detailed design document either way, and we can subsequently choose whether we want to implement it, ideally with a bit more insight into initial usage by Agoric and any other possible SDK app developers.

[cwgoes]

#5469 switches to local namespacing & irrevocable multi-owner capabilities.