The idea here is to produce an Anoma Research Topic Report specifying how we want Controllers to work, and why they should work that way.
Here I try to lay out the scope of this report: what it should cover, and what it should not cover.
- what is a controller?
- does a controller differ from a (replicated) state machine?
- does a controller differ from an (external signing) identity?
- what makes a good controller?
- what can controllers do (to resources)?
- how do resources reference controllers?
- this should include a notion of a resource graph
- this should include some description of policy languages for creating / destroying / moving resources
- what kind of resource “moves” (destroying a resource and creating a similar one with a different resource graph) should be possible?
- what does each move require from its controller?
- what does each move require from its resource?
- this may include a notion of resource “shares” for asynchronously moving resources “up their resource graph.”
- this may include an examination of whether it’s possible to “simplify” a resource graph while “using” the resource.
- specify a precise policy language of resource controller permissions (just examine what kind of things are possible / impossible).
- specify how to implement any particular kind of controller (we’re much more interested in the interface: what does a controller need to be able to do?)
- rule out possible controllers just because they seem unlikely to be useful.
- rely on any more specifics concerning resource structure / logics than absolutely necessary.
Broadly aligned, a few specific comments:
- I think we should include a scope section describing our design goals and constraints for the controllers system, perhaps a bit similar to the first part of the “controllers from first principles” topic, but further explicated and refined.
- I think we should describe what logic the resource machine - or a particular resource logic, perhaps - must run in order to enforce the controller system correctly. I think your last section is similar to this - my request is specifically that we aim to get this all the way to pseudocode describing exactly what transition conditions must be checked.
- I think it is worth including a section on how controllers are similar to and different from what IBC does, as this is a design many people will be familiar with, and has some similar constraints (and some constraints that we don’t have because we control the whole protocol stack).