@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.
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!
Hi Max, I’m late to the party here.
Are these the things on the following post that you need reviewed?
Hi @pacu ,
Currently the list stands as such:
lightwalletd wanted to use it)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.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.
I reviewed this code:
and these 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
TcpProxymodule 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 Torarticlient.
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.
Thank you for the review!
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 
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.
Thank you Daira-Emma for your review!
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.
I was looking into this NymVPN project and it’s another one for this lovely thread:
Hey guys, can someone explain what’s going on here in simple terms for those of us who aren’t very technical? What’s the point of integrating Nym with the zcash wallet?
Why not just add an option in the wallet to work through SOCKS5, so you can run any software that provides a SOCKS5 proxy alongside it-whether it’s Nym, Tor, or something else?
From what I understand, something like this is being developed for $150K and about a year and a half, right?
Also, will this be a paid service? Meaning, will wallet users have to buy a Nym subscription to use it?
And one more thing, while reading the text “Addressing Network-Level Threats in Zcash Using the Nym Network”, I came across this passage:
Transaction and Address Linkability:
Similarly, when a wallet checks for received transactions, the wallet will indicate exactly which transactions it wants the ciphertext for.
Could someone explain in a bit more detail how this works? Does Lightwalletd really track user transactions in this way, or is something like bloom filters used? what is “ciphertext”?
Dear @postfix1 - I haven’t been monitoring this thread very much, but I’d like to answer these questions:
The Nym mixnet has been available as a SOCKS proxy since its launch back in 2022. If you want to use it via SOCKS you can follow instructions. For example, Monero Desktop, Firefox, and others support SOCKS and have been using the Nym mixnet for ages - check out the docs here: Socks5 Client (Standalone) | Nym Docs
Unforunately, Zcash uses gRPC, not SOCKS, so we are having to do a lot of extra work to make Zcash wallets work with Nym. Here’s a guide for zcash wallet devs: https://zcash-sdk.nym.com/
We’ll post an update on the grant soon, there’s been obviously a lot going with the Ironwood migration. And yes, lightwalletd or any successor like zainod sees your IP address and timing of any transactions, that’s just how light wallets work. They don’t see the payload per se, just the Zcash encrypted transaction. So that’s why network-privacy is important!
Hey everyone, just so you know Nym has officially completed the grant. You can read more on our blog post here (Nym mixnet now live in Zcash wallets | Nym), but here’s all the libraries we produced, and the Nym mixnet is now integrated into ZKool and Zingo wallets, with more coming soon we hope!
Improved Network Privacy Threat Model and Design Document for Zcash. This will be delivered by the Nym Research team; furthermore, we will use our network of privacy experts, including the Zcash Foundation, for a review. This document will be iterated as the integration continues.
The network privacy threat model document is now fully fleshed out, with clear guidance on recommendations for Zcash integration and design for developers - and animated graphics! Threat models and concrete implementation recommendations against a wide variety of threats, from a compromised lightwallet server to a local and global passive adversary are covered, each with a set of remediations using Nym. See the Threat Model and Design Document for Zcash here: https://zcash-sdk.nym.com/
Create HTTPS Connect Proxy for Nym to allow Nym to work with gRPC
We have made several Rust crates to deal with different traffic scenarios (tx send vs wallet sync) / threat models (untrusted endpoints vs GPA), to offer as many options as possible for ZCash wallet developers. All of these crates are available at crates.io. For when and where to use each crate, see the recommended hybrid integration approach.
A new networking crate was developed based on the original “proof of concept” that involves sending traffic through the Mixnet and then out to the internet via an Exit Gateway, de-linking the traffic from the user but allowing the endpoint to see transactions:
We also created transport-independent pattern hygiene for crates: shaping the timing and content of your requests before they leave your device.
Nym-swizzle simply changes what your application puts on the wire and when. It is transport-independent - it works the same over the Mixnet, a VPN, Tor, or a direct connection.
Nym-swizzle-zcash is a crate utilising -swizzle but adapted specifically for ZCash with regards to timing assumptions and block times.
This crate can directly be integrated into both native and Rust wallets. FFI bindings for Go and C were also created by @maxnym from Nym:
Create a Service Provider component (transactions submission service) that would run between the mixnet and Zcash nodes:
Service providers may also want to be inside the Nym mixnet, and not accessible from outside the Nym mixnet. This is somewhat equivalent to running a “hidden service” for Zcash transactions inside the Nym mixnet. Full documentation for service providers is given our Zcash Wallet Design: Service providers — Zcash × Nym
In order to enable this use-case, we created a new crate:
Integration via lighwalletd for sending, and possibly receiving, transactions.
In particular, we created documentation for Zcash wallet developers to show how to make lightwalletd as a service provider: Fork of lightwalletd + service provider — Zcash × Nym
There has been some vibecoding around it, including GitHub - nymtech/nym-rpc · GitHub and some work by the developers of Nosy Wallet like Lwd-mixnet-proxy: light-wallet gRPC over the Nym mixnet, and what three days of measuring it found - #31 by Joaco .
If you want to try it out, this service (used by ZKool) is completely inside the Nym mixnet, similar to a Tor Hidden Service. It can be accessed here: nym://BbTPrU1gNTsPiieXdC58xkp5QFSHhUUM98BP1Rm2adf9.GKiGLNQB116YszFwbuweeL2GsrfpHpuUzq6JuqFQ8EEE@ZXSDhRTKU5HgMpH8ma78FftvLiKyZ6jWL1e2U7GD7gQ
We at Nym are happy to answer any questions here!
