Websocket Subscription support

[thiagodeev]

Hi!
I'm testing the library. It has websocket support, but when I tried to subscribe to a blockchain node through a subscribe... method, it didn't worked. When debbuging, I noticed the received message was going to the default case in the handleFrame func (ref). I believe one of the problems is that the switch only consider the message as a respone if the method field is empty, but in a subscription response the method usually is domain_subscriptionMethodName.

So, the library doens't support subscription, am I correct?
If so, is there any plans to implement it?

[rvagg]

It does, we use it in lotus, it's particularly useful subscribing to a ChainHead channel and that's used in critical code all over, including in miner and market software which maintain long-running connections listening to head changes. Lotus also supports eth_subscribe and friends and that's supposed to work fine.

There is a chance though that it may not work quite the way that an alternative Ethereum-compatible endpoint might expect. For example, if you pointed it to go-ethereum, maybe it would struggle to interpret things quite the same? I'd be very interested in hearing about any such incompatibilities, especially if you can demonstrate it with demo code.

[thiagodeev]

Hi @rvagg, thanks for replying!
Sorry for the delay.
Based on your comment, I studied the Lotus and the go-jsonrpc code extensively, and I was finally able to subscribe to the eth_subscribe method using go-jsonrpc. Here are my conclusions:

1. How does the eth subscription work?
   Ref: https://geth.ethereum.org/docs/interacting-with-geth/rpc/pubsub
   The first thing to do is, via websocket, send a json-rpc request with the eth_subscribe method, and for this example, I'm passing the "newHeads" param to subscribe to new heads notifications.
   The node will return a hex number as the result, and then, it'll start sending notifications.
   The notifications follow this standard:

• They have the eth_subscription value as method;
• They don't have the result field, nor the ID;
• Instead, the result is inside the params field, and also inside we have the subscription field, containing the ID of our subscription returned on the first call

2. The problem
   I'm used to working with the go-ethereum rpc client (ref), and their implementation is quite different from this library's.
   When I was trying to follow the README.md tutorial (struct configured + field Subscribe func....), the json-rpc eth_subscription response was falling into the handleFrame function (as I said previously), and the handleCall on client with no reverse handler error was being returned

3. Resolution
   Studying the Lotus code, I found this:
   https://github.com/filecoin-project/lotus/blob/f5f71f903c5371f5538bdbf3ffea3e6511cf6e70/gateway/proxy_v2.go#L571
   This was related to the no reverse handler error, so I followed your README.md explaining how to use it, but a different error was being returned now: RPC Error: method 'eth_subscription' not found.
   I found the root cause: this library formats the method like namespace.Method by default, but the json-rpc response was like namespace_method. For the client methods, we can change this with the WithMethodNameFormatter func, but this is not the case for the reverse handlers. There is no other way than manually editing the makeHandler function and set a new format there (ref).
   This is what I did, and the code finally worked:

I've created a gist containing my code: https://gist.github.com/thiagodeev/69d6fd1ff792794f0a2e4c09d14fef78

[thiagodeev]

@rvagg, as we can see, subscription is not a 100% out-of-the-box feature.
I'm the current maintainer of the Starknet.go library, and I'm planning to use this library as the rpc client. I want to know if, in the case I create a PR implementing it, it would be possible to review and, after being merged, make a new go-jsonrpc release within days or a few weeks so I can use it in starknet.go.
If yes, I can help with that; otherwise, I'll need to fork the library.

Looking forward to your response

[rvagg]

I'm not 100% following what you're requesting but I think you're just wanting to be able to pass new options to transform names, which is fine as long as the default case remains stable. You can see that the renaming code is fairly new already so it's not surprising that it doesn't cover all the cases: #130, #131. Happy for you to extend it to subscriptions if you can find a way to do it without causing disruption for cases that don't need it; mainly lotus - i.e. if you don't make it harder, less efficient or breaking for lotus then I think we can happily accommodate. If you happen to fix bugs for lotus along the way then all the better!

[thiagodeev]

Thanks @rvagg!
Yeah, I know; the only problem is not having the name formatter for reverse handles functions; just implementing that is enough to make it work. I was thinking about having a more user-friendly wrapper for subscriptions, but I believe I can handle that on Starknet.go side; here, just a small improvement on the README would be sufficient to help users better.

And yes, I understand that the solution should change as few things as possible. I'll take care.
Sorry, not sure if it would help anything on Lotus side though 😅

I'll open a PR soon