Applications with Configurations

[jakehemmerle]

This is the tracking ticket for Configurations.

From the context of usability and browser support, users should be able program/config instances, which allow a user to to reuse other's programs and modify configurations for them by simply filling out the program's associated configuration, and then setting the config for that instance on-chain with their program modification key.

This requires a few changes throughout the whole stack

Core

Already talked with Jesse about this, but basically we want to add program 'instances', followed by Program/Config instances.

Programs

• Program Configurations MVP #56
• Config sanitization function (allows for client-side sanitization of the config type before being uploaded)

SDK

There should be a method that allows the user to be able to modify the config of the program instance. @JesseAbram please tag the PRs

---

Older notes but feel weird about deleting:

This type of architecture allows for:

• not requiring a user to compile or write (or know anything about) Rust themselves
  • Pointers (related): Convert user constraint to Pointer  entropy-core#531
• composing Constraints as logical expressions (where the evaluated constraint is the operand)
  • Additive Program Composition Additive programs entropy-core#550
  • threadding of constraints (evaluate logical operands in parallel)
• exposes a simpler interface for developers to reuse other compiled constraints (via importing WITs and dynamic linking at runtime)
  • reducing duplicate on-chain bytecode
• easy integration into the Wasm registry or our own hosted version
  • users can browse available constraints and immediately activate them.
• typegen for the SDK and other languages (see wit-bindgen)
  • WIT generation from Application configurations #16

[ameba23]

@jakehemmerle would be great if we can put together a description of exactly how this would work using the access control list example. As for me its not clear at what point the template ACL program gets combined with the configuration.

Im guessing that when registering or updating we are going to store the template program pointer, together with the configuration binary blob, and then at the point of requesting a signature, the programs runtime evaluates the program together with configuration data, input data, and auxiliary data.

So in the case of the ACL, deserialization of the allowed / denied addresses etc, would happen on every program evaluation rather than only when registering / updating. Is this what you are imagining?

[jakehemmerle]

@ameba23 this is just a draft! I should have indicated that. I will be flushing this out into a set of actionables.

[jakehemmerle]

@ameba23

Im guessing that when registering or updating we are going to store the template program pointer, together with the configuration binary blob, and then at the point of requesting a signature, the programs runtime evaluates the program together with configuration data, input data, and auxiliary data.

Exactly. I'll write the details in a ticket soon.

So in the case of the ACL, deserialization of the allowed / denied addresses etc, would happen on every program evaluation rather than only when registering / updating. Is this what you are imagining?

Also, exactly. I'm currently imagining the config as stringified JSON that gets uploaded onto the chain, and during each evaluation, the program parses that string (which is the Config) into addresses, bool, etc and then evaluates the signature request with that data. This makes it easy for users to update a Config from the SDK without having to recompile a program.

[jakehemmerle]

Complete per #56