Feedback for discussion

[mradkov]

Operations:

• follow a convention in branch naming (improve on potential contributors accessibility);
  • main instead of stable and dev instead of unstable;
  • 🤝 Keep stable and unstable which will serve purpose of main and dev
    • release/x.x.x branch to stable (similar to gitflow)
    • small change: trunk commit to unstable
    • bigger features/changes: feature branch to unstable
• code formatting / IDE support / lint to follow a convention;
  • figure out a middle ground that will ease PR reviews and contributions and at the same time will not introduce mental burden on core contributors;
  • 🤝 include .editor.config for JS and Rust
• tag experimental stuff with some experimental label and leave it aside from the main stable product until its usable and stable enough :D;
• cleanup deployment procedures and clear definition on release process and versioning;
• housekeeping on old issues;

Architecture:

• composable or derive - agree on one and follow on;
• export * ?
• creates instead submodules

Strategic discussion:

• where should fadroma head to;
• core feature set;
• discuss Rust / JS parts;
• UX (https://github.com/hackbg/fadroma/issues/92);
• integrations with other tools and workflows (e.g. cw boilerplates and other tools).

[mradkov]

What

Value prop:

• Fadroma to be the main contract development framework for cosmos
  • Be able to run and test everything locally (Devnet, Mocknet)
• Bringing strong encryption capabilities to the cosmos apps

Core features

1. initialize a project (#79)
   • bare CosmWasm contract
     • version select
   • [opt-in] derive macro (could be selected on project init)
   • [opt-in] composability (very experimental at the moment)
2. develop
   • use helpers from fadroma (flags? treeshaking? is this compiled/included in)
     • vk logic, auth, permits etc.
3. test
   • use ensemble for integration testing (Rust: contract instance testing, cross-contract communication tests)
   • Mocknet (runs web assembly blobs in node-js built in runtime) (JS: run tests with the compiled contracts and test clients);
     • Localnet (real VM)/ Devnet / Mainnet
4. compile
   • dockerized build containers (reproducibility)
     • checksums & wasms (artifacts)
5. deploy (upload, init, configure)
   • receipts;
   • scripts for init and configure (operations scripts). 6(future). dashboard / REPL

How

Discussion

@egasimus:

• move deployment procedures from console to browser;
• as much interaction from the browser (deploying contracts and interacting with contracts from the browser);
• want to use import * from fadroma , use *;
• simplification of deploy scripts (build, deploy etc. templates for instantiation);
• cosmwasm issues with storage;
• Remove the fadroma-platform-scrt crate and add the cosmwasm_std dependency in the main fadroma crate itself.

@aakamenov:

• stable API and move all of the moving and experimental stuff to a different branch until they are stable again;
• prelude is needed;
• we are abusing flags?
• ensemble allows you to debug (breakpoints);

@denismaxim0v:

• import * is a bad practice - should explicitly import what you want, otherwise risk of name clashes;
• mocknet is serving the same purpose as ensemble - you cannot catch Enclave errors as the contract is not being actually uploaded on-chain;

Ideas:

• teggle.com like tool that will enable cosmos apps to utilise Secret Network's encryption for privacy;
• REPL (fadroma dashboard) (#124 ?)
  • interact with a project, query/execute txs
• typecheck commit hook

[egasimus]

import * from fadroma

import * as Fadroma from 'fadroma' -> in TS it's still namespaced so no issue there.

use *

agreed (?) on:

use fadroma::*          // includes cosmwasm_std
use fadroma::prelude::* // includes cosmwasm_std::*

risk of name clashes

imo the library's nomenclature shouldn't clash with the platform's either way and it doesn't, clash was downstream

[egasimus]

Work item: dat big mysterious packages refactor.

• @fadroma/deploy (which is FS-bound) contains the ContractSlot and TemplateSlot classes which do the heavy lifting in the new (nearly declarative) deploys.
• The TokenRegistry (which is used downstream) would be a good addition to @fadroma/tokens (which is isomorphic), but it depends on ContractSlot and TemplateSlot to deploy placeholder tokens on demand.
• To move TokenRegistry (AssetRegistry?) into @fadroma/tokens (where it can be reused), it is necessary to move ContractSlot and TokenRegistry into @fadroma/client.
• @fadroma/client (which is overweight) already contains Template and Client. Adding the functionality of the deployment primitives TemplateSlot and ContractSlot onto the base clases looks to be a good way to reduce code complexity.
• One side of this refactor enables all future REPL/dashboard/frontend console, as the entirety of the core workflow code becomes isomorphic.
• The other side of this refactor enables restructuring the deployments format, enabling deployments to be delivered to the frontend in an importable JSON.
• Need docs: asset registry guide
• Once this is done, the contracts will practically deploy themselves.