Roadmap
Pre-V1.0
Fix Instructions/Debug output to show mutated state
The result of executeAction is meant to show the state mutated for each instruction. Currently, it is broken and does not do this correctly.
Support for Arrays
Some templates will, for example, need a list of recipients. Thus, we must support Arrays and Array iteration (there are also other use-cases for this).
Control-Flows for Meta Titles/Descriptions display in Wallets
This is connected to the above. Descriptions should be able to loop through array items for presentation and support conditionals.
Meta Titles and Descriptions should ONLY use CashASM
Currently, a custom parser has been hacked in. But this should be moved to tooling to keep the Core Templates lightweight and easy to migrate to other languages (i.e. no custom parsers except CashASM).
Support for Var Outpoints
This will allow state inference using existing Instructions and, if not done before V1, would be a breaking change. Currently, on each transaction instruction UTXOs are fetched: But I'm pretty confident that we want to know these up-front at this point.
VanillaJS Dapp UI for easy Dapp integration
Current is written in Vue and was developed for the BCH Guru Team. But the UI is simple enough that I should be able to take their's and convert it to a VanillaJS implementation so that it's lighweight and doesn't drag in unnecessary UI dependencies.
Lots of minor fixes
The aim is to get CashConnect into a stable enough state that we can append features without breaking compatibility with existing templates.
Post V1.0
HTTP Transports
BIP70/JPP-like flows will suffice for many Dapps (and likely provide a better UX where Wallet interaction is not frequent).
LibP2P Transports
This is a broad area I'm currently experimenting with. But, it would potentially replace WalletConnect as transport and also allow Wallet-2-Wallet communication in a BIP70/JPP-esque flow.
Formalization of States
Currently, templates are byte-heavy due to repetition. By formalizing states (i.e. params and returns) into a schema property, we would chop this down a lot. However, how I do this will also likely tie into a future generalized storage adapter, so I'm not quite ready to scope it yet (most states will follow a consume and emits pattern, but this might not always be the case and we want to be able to accommodate that).
Lots more
Above written on a whim as I try to recall my TODO items. If you have other suggestions, please let me know!