Implement jsonrpsee-ipc

[tomaka]

While the async-std crate provides Unix domain sockets, there's no new-futures equivalent of Windows named pipes.

[tomaka]

@tomusdrw Is that still needed?
Maybe we can mark this issue as "very low priority".

[tomusdrw]

Sure.

[tomaka]

See also async-rs/async-std#291

[Demi-Marie]

@tomaka This is still needed, as IPC is considered the most secure transport.

[wadagso-trey]

Is there really no other interest being expressed in this? I wonder how difficult it would be

I'm surprised there's been no activity considering how commonly used it is. My project is currently using the other jsonrpc crate but we'd like to have more direct support for async/await instead of the hack we're doing now by blocking on a task in a tokio runtime.

[niklasad1]

ok, it shouldn't be that hard to port over but no one has really shown interest in it.

fair enough we should look into this

[dvdplm]

I'm surprised there's been no activity considering how commonly used it is.

Is it? We must be living in somewhat disjoint bubbles then! :)

I thought the IPC transport was mainly a legacy from when chains were so small that it was reasonable to expect end users to run their own full nodes and thus could benefit from having IPC level access control.

Can you elaborate a bit more on your use case (and that of others if they differ)? What about IPC is useful to you? I'm happy to consider adding IPC if there's a valid use case for it.

[wadagso-trey]

Not sure why the needs of blockchains are relevant to a jsonrpc library, but unix sockets are just a very convenient way for multiple processes to communicate with each other without having to deal with what comes with using a network stack (managing ports, network namespaces, etc.) and allows a more convenient permissions model. It seems silly to make HTTP/WebSocket requests between two processes on the same machine that have nothing to do with the web doesn't it?

[seunlanlege]

yeah we had ipc in parity-ethereum for this reason, built on https://github.com/paritytech/parity-tokio-ipc

[tomaka]

It seems silly to make HTTP/WebSocket requests between two processes on the same machine that have nothing to do with the web doesn't it?

It also seems silly to me to spend time and effort developing and maintaining an IPC library when HTTP/WebSocket work just as good.

IPC is maybe a bit faster than using the WebSocket protocol, but if having maximum performance is actually a criteria then using JSON-RPC should be a much bigger concern than using WebSocket.

If you have a concrete example where IPC is a better solution (other than performances) than HTTP/WebSocket, then sure, but otherwise I would actually doubt that it's worth the burden of having additional code.

[wadagso-trey]

Compiling an entire HTTP client/server and including it in our binaries when it provides no additional value over the alternative seems seems like an unnecessary burden as well.

Plus more generally speaking: if someone was writing an API wrapper to interact with another project they didn't control then they wouldn't have a choice in the matter.

[dvdplm]

Compiling an entire HTTP client/server and including it in our binaries when it provides no additional value over the alternative seems seems like an unnecessary burden as well.

You can use whichever of the two supported transports that you prefer without having to carry the burden of compiling the other.

Supporting a third transport carries a maintenance burden that we are unlikely to want to carry at this point. If this is very important to you and if you are prepared to commit to implement and maintain it in the future then that's another matter. :)

[jsdw]

Since we have no internal need for this feature, we'd be relying on external contributions. I'm going to close this for now, but if somebody is interested in stepping up and wants to discuss the complexity of this, then you're welcome.

(although for what it's worth, whipping together a completely independent library to solve the specific use case may be the easier path to take here)

[delbonis]

Just leaving this here for future readers, the reth repo has a client and server impl that works with jsonrpsee: https://github.com/paradigmxyz/reth/tree/main/crates/rpc/ipc

[domenkozar]

@delbonis that's great, do you mind publishing this as a separate crate and repo? I'd like to use it as a dependency that exists on crates.io