Community apps run beside your money, not inside it.
A community app is a mini app whose manifest says so, and that one word changes what the bridge hands it: no finance context, only key-value storage namespaced to its own id. It can't read a balance and it can't post to the ledger, however it's written.
What the sandbox guarantees
- No finance context.
host.financeisundefined. There is no second path to the ledger; every store lives in the SDK and only the bridge exposes it, and only to core apps. - Own storage. Reads and writes go through
host.storage, namespaced to the app id. Two community apps cannot see each other’s records. - Same backup. Community records are included in the export and the restore, under their own keys, with the same validation.
- Same error boundary. A community app that fails to load or throws degrades to one broken tile with a retry. The shell is unaffected.
- Public catalogs only. The provider list and the category list are product metadata, not user data, and community apps may use them.
What a community app may do
Anything a sandboxed screen can. The five that ship today track savings goals, personal lending, a rotating savings group, remittances, and shared expenses. Each keeps its own records, validates every entry before saving it, and follows the same UI kit and tone as the rest of the product, so a user cannot tell by looking which apps are sandboxed. They can tell by what the app asks for: nothing.
Proposing one
- Read the SDK guide and build against the template app.
- Keep to the rules: SDK imports only, no native modules, no colour literals, no emoji.
- Add validation cases to the SDK test suite for anything the app persists.
- Open a pull request against the repository, or write to hello@jinnie.ph with a short description and a screenshot.
A community app that later needs the ledger is not promoted quietly. It is reviewed as a core app, with the same regression coverage, and its manifest changes kind in a host release.