Revised Nym for ZCash Network-level Privacy

[maxnym]

@jelly5649 a bit more information with regards to your sudo question I got back from one of our mac developers: it is needed because we are not using network extensions but instead tapping into the network adapter through sudo in order to get a higher level of control and to help mediate the leaks, which there are plenty of, when using network extension.

Right now there is no alternative to this with the NymVPN app unfortunately.

[maxnym]

Hi, is there an update on the code / submission review? If you need any other info from us let me know and I can get it done asap. Thanks!

[pacu]

Hi Max, I’m late to the party here.

Are these the things on the following post that you need reviewed?

Revised Nym for ZCash Network-level Privacy

Hi all, just a quick update - there are now new docs for the TcpProxy module and the Go FFI which can be used to send zcash traffic through the Mixnet: TcpProxy SDK Module FFI

[maxnym]

Hi @pacu ,

Currently the list stands as such:

• I have created a module in our SDK which can be imported into crates or via Go FFI (if lightwalletd wanted to use it)
• FFI docs
• Module docs
• I have also created a pair of CLI binaries (docs) which can be used as standalone processes to easily test sending zcash traffic through the Mixnet - I have been using the zingocli wallet on a local machine with the TcpProxyClient binary to send traffic through the Mixnet to a VPS I’m running a testnet zcashd & lightwalletd instance on via the TcpProxyServer binary. The TcpProxyServer binary is also there so it could be e.g. added to the lightwalletd Helm setup. If you want to use these to test, I suggest using the conn-pool-update branch: this is a branch I have been working on a speedup on which is waiting to go into our next release, which involves a Client Pool abstraction.
• There are also the videos further up in this channel which were demonstrating the WIP versions of this work.

These components allow for Mixnet integration into ZCash codebases and can be used currently to use ZCash through the Mixnet.

Happy to help with any other questions you might have.

[SexDrugsAndZcash]

finally had some time to explore Nym project
wow it is serious
and going live in a month

[daira]

I reviewed this code:

• nym/sdk/rust/nym-sdk/src/tcp_proxy/tcp_proxy_client.rs at develop · nymtech/nym · GitHub
• nym/sdk/rust/nym-sdk/src/tcp_proxy/tcp_proxy_server.rs at develop · nymtech/nym · GitHub
• nym/sdk/rust/nym-sdk/src/tcp_proxy/utils.rs at develop · nymtech/nym · GitHub
• nym/sdk/rust/nym-sdk/src/tcp_proxy/bin/proxy_client.rs at develop · nymtech/nym · GitHub
• nym/sdk/rust/nym-sdk/src/tcp_proxy/bin/proxy_server.rs at develop · nymtech/nym · GitHub
• nym/sdk/ffi/go/proxy_example.go at develop · nymtech/nym · GitHub

and these docs:

• FFI Bindings - Nym docs
• Architecture - Nym docs
  • This appears to be missing some flow diagrams.
• Standalone TcpProxy Binaries - Nym docs

With the caveat that I haven’t tried to run the code, it looks well-written and useful for the purpose described in the docs:

The motivation behind the creation of the TcpProxy module is to allow developers to interact with the Mixnet in a way that is far more familiar to them: simply setting up a connection with a transport, being returned a socket, and then being able to stream data to/from it, similar to something like the Tor arti client.

These might be an easy way for developers to start proxying their traffic throught the mixnet and understanding the sort of latency they should expect, and whether their application can currently tolerate it.

There is obviously a lot more design and integration work that would need to be done in order to use Nym more exensively in Zcash (in particular I don’t know whether we’d want to hook into the TCP-like abstraction or something more low-level), but this looks like a good start.

[maxnym]

Thank you for the review!

@daira

This appears to be missing some flow diagrams.

What sort of diagrams do you think are missing here / aren’t covered by the Sessions and Message Ordering section? Something more like an architecture diagram of how the Proxies take incoming traffic, frame it, etc? Always happy to hear feedback on the docs and what else can be added to make them better

@daira

in particular I don’t know whether we’d want to hook into the TCP-like abstraction or something more low-level

We are currently working on some protocol upgrades which will make the SDK Client interface a lot nicer to work with. This should remove the need for the localhost port exposed by the TcpProxy and allow for whatever code consumes the SDK to pipe bytes directly to the Client (also removing the need for the bytecodec shuffling in this abstraction), as well as doing stuff like multiplexing (removing the need for a lot of the accounting work this abstraction is currently doing). I will update this forum when we have something to share with regards to this upgrade - that should allow for lower-level integration work to take place.

[pacu]

Thank you Daira-Emma for your review!

[daira]

@maxnym

What sort of diagrams do you think are missing here / aren’t covered by the Sessions and Message Ordering section?

I think they were either added after my review or they weren’t rendering correctly for me. The ones that are there now look good.