Low hanging fruit: add REST endpoints to LightwalletD

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.

The benefit of this is that we don’t need to use gRPC specific tooling that is niche compared to the curl / javascript fetch ecosystem. This means development time and costs get reduced and more experimentation is enabled.


I’m sorry but I have to disagree with that. The light walletd protocol is mostly binary in nature and streaming. It is not designed to be exposed to end users. For instance, there is nothing related to wallets or accounts in it, just transactions and blocks.

1 Like

thanks for your work on warp sync and ywallet @hanh and all the other projects you have done for the Zcash ecosystem!

That is not what I meant.

Well - if you are a dev, it shouldn’t really be a problem. As you said, grpc was designed for machine to machine communication.
Just to be clear, I have nothing against offering more options but I don’t think it will make much difference in the webapp case. Because, the difficulty is elsewhere.
And if you do REST, you have to implement message encoding and streaming.