Define minimal set of initial features

[danfinlay]

Right now this plugin branch represents a vibrant assortment of APIs that we have not firmly committed to supporting.

In practice, we will want to roll out APIs as we're ready to endorse their security and support them.

To do this, we will need to refine our management of this repo a little bit.

Maybe:

• Keep a simplest and most secure branch which represents our most-prod-ready branch.
• Keep most other API proposals on other branches
• More freely merge those proposed APIs into the more experimental branch (develop)?

Right now we lack that bare-bones branch, and any real isolated feature branches. We will want to remedy that before we go to production.

[danfinlay]

A proposed initial production target, for which I've begun the MVP-Blocker tag.

Starkware MVP Plugin

A Starkware plugin is a strong plugin target because it

• Adds considerable utility immediately (a high-throughput exchange)
• Has the same requirements as any L2 scaling strategy (custom assets, custom confirmations)
• Also has the requirements of any alternative cryptography (requires app keys)
• We have a strong relationship with the team, so we are more comfortable shipping their plugin as "available" before we open the entire API to unknown plugins.

The APIs they require

• Manage custom asset (Fix asset controller icon providing API #102, Selecting a custom asset should allow displaying a custom asset view #103, Custom asset design #105, and any other improvements)
• Reliable restorable app keys - Must address whether plugins get per-account scripts.
• Display custom confirmation (Allow Plugins to display custom confirmations #52, needs design)
• Either an update mechanism (Add plugin update mechanism #45) or another distribution mechanism hard-coded for the MVP.

Conclusion

Posting this now to invite feedback from starkware, to see whether this set of features seems to meet their basic requirements.

[rekmarks]

No longer relevant.