gateway mode

[keppel]

Shea currently creates a separate node process and http server listening on a different port for each Lotion app. You run shea <GCI> and that localhost:1337 or whatever.

Instead, running shea with or without a GCI argument should open a single process that manages light client connections to multiple chains.

GET /:gci

Load the client code for a chain at gci. Apps can link to other apps this way.

GET /state

For now, apps can only query their own state. While it's possible and would be super convenient to let clients query the state of other chains, it seems tricky to prevent an app from just spamming a bunch of /:gci/state endpoints for random gcis, which would unnecessarily spawn a bunch of tendermint nodes. This seems like it should be possible to solve, but I'm not sure of the best way to do this yet.

POST /txs

Create transaction for currently-loaded client. Cross-chain txs might be possible, but need to think more about how to do this securely.

Gateways

I expect there to be three ways people use shea apps:

1. Public gateways. People connect to, for example, https://shea.kep.io/abc123000deadbeefbabe456 and see the Lotion app running at that gci. In that case, however, they're completely trusting the gateway not to be evil, which is only ok for apps where nothing is at stake. From a UX perspective, this is a fantastic experience. As an example, consider that most IPFS usage happens through the gateway at ipfs.io.

2. Trusted gateways. People spin up their own gateways which they can then trust from any of their devices. The UX cost can be small here if the tools for deploying a gateway are simple, and the UX cost is all up-front.

3. No intermediaries. People install shea and always run a local gateway -- this currently the only way to use Shea.

[SaifRehman]

@keppel any progess with shea? can we use it in prod, shea works perfectly locally but how others can join globally?