While it would be best for everyone to run their own node, realistically this is too much of a burden for first time users (that might be only using a smartphone). The lightwallet rpc is essential to serve this use case, but currently it only has a grpc based API. We should lower the barrier to entry to interact with the RPC.
Take a look at the architecture diagram of the Zephyr project that got funded by a Zcash community grant.
The lower part of the diagram could be eliminated if lightwalletD offered REST endpoints.
As you can see months of development time and effort was spent on this issue. To reduce development time and cost in the future it is best for the lightwalletD to expose a REST api.
This is also not a protobuf vs JSON problem. The issue really lies with gRPC.
gRPC’s complex use of HTTP/2 makes it impossible to implement a gRPC client in the browser, instead requiring a proxy.[…]
gRPC is a good choice when connecting servers in a datacenter. But it is more complicated to interact with than a typical REST api. This tradeoff means that there is a higher barrier to entry for developers. It makes some applications impossible or very hard to create.
How the issue can be addressed
The lightwalletd includes an http server anyway for the metrics endpoint:
So we could expose the grpc endpoints as rest endpoints as well.
To give an overview of how lightwalletd endpoints typically work:
For example this function will get a transaction from zcashd, unmarshal the json response and turn it into grpc for the wallet of the zcash user that is connecting to the lightwalletd. lightwalletd/service.go at e3d9c11f14673fe1828fa7dc92ba292586a7c565 · zcash/lightwalletd · GitHub
We can do the exact same thing, but instead of gRPC, expose this as a normal http REST endpoint. The logic stays the same.