By integrated into apps, I meant on the binary level. The cited Bitcoin issue wants node-Tor to effectively replace the standing Tor daemon for now, without native integration, and any native integration would require shipping the full JS runtime in the application.
By full functionality, I really just meant being able to connect to the Tor network and securely send data over it to achieve network level privacy as much as possible. That said, Arti is intended to implement all of the Tor protocols.
I personally use Rust exposed via a C FFI in my Nim work. You can argue it’s insecure because I do use raw pointers for the C FFI, which violates the memory safety Rust offers, yet I don’t imagine any JS engine bindings would be better. I will note I don’t crossover any async work, which sounds like a monumental task, yet that’d be true for both Rust and JS. It’s effectively a pair of header files (one C++ header, one Rust copy of the function definitions) and my binary solely executes native code with 0 overhead.
I don’t dislike node-Tor. I think it sounds best left to the browser side of things. If I have a C++ app, such as zcashd, and I want to give a single executable to my users which utilizes the Tor network for privacy, how would you recommend doing this with node-Tor? I personally detest the idea of grabbing V8, spawning it up in my app, piping the scripts to it, and then defining custom bindings for the actual functionality compared to grabbing a Rust library which would be immediately accessible under Rust, and C++ with just a header file. Even if you provide bindings from node-Tor to C++ yourself which manage a V8 instance accordingly, why do I want to ship the memory hog known as V8 in my performance-focused C++ app? If node-Tor is run as a separate binary, as suggested by the Bitcoin issue, what benefits does it offer over just running the stock Tor daemon? That was my comments/questions with that paragraph.
When you define the Tor network as a set of nodes running the protocol considered as Tor to offer network privacy, such functionality is critical to Zcash. Even now running Zcash behind Tor will greatly increase your privacy, even if it doesn’t take advantage of aggregate traffic with other nodes due to the lack of people running Zcash over Tor. I don’t know why you’d say it’s not appropriate.
Your final comment states this wouldn’t be used to link up with the thousands of Tor nodes out there providing access to the entire internet with privacy (though they could be). At that point this effectively becomes a Dandelion++ functional equivalent except it’ll greatly reduce performance if we blindly route all traffic over it, no? The reason I’d want to use Tor with Zcash is so no one knows I’m running Zcash in the first place. If I spawn a Zcash nodes, which has the Tor protocols yet not the Tor network, and I immediately connect to a bunch of Zcash nodes, it’s obvious I’m running Zcash. Then, as it’s a public blockchain (just with some data not saved to the blockchain yet rather committed to and proved), I don’t care for privacy because everyone knows everything except for new TX publication on my end. That’s why this effectively becomes a discussion against Dandelion++ which offers a privacy protocol for that.
As one final note, I do understand running a node behind Tor would also greatly reduce performance. The distinction is that no one even knows I’m running a node without potential theoretical government level attacks (packet size analysis across entry/transport/exit nodes with low population of similarly sized packets) whereas if I’m solely connecting to Zcash nodes, that advantage isn’t there.
That may be our fundamental misunderstanding though. I’m coming from this discussing integration with the Tor network. If you’re suggesting zcashd form its own network privacy system, that’s just a different discussion that what I thought it was, and I’d be interested in discussing that. If it is discussing the Tor network, or if it’s discussing both, I’d love to hear an explanation on why this is better suited for integration with Rust/C++ projects than Arti, as well as clarification on why it’s better than the standard Tor daemon if not meant to be integrated on such a level. If it’s solely discussing a Zcash network privacy solution limited to the Zcash network, then the question really does become how much better is this than Dandelion++. They may both be fine yet this may be faster to integrate. Cool if so.
EDIT: I saw your grant proposal linked a BTC mailing list email I had yet to read. I actually commented on how such an attack is possible here: Is Zcash actually quantum private? - #23 by kayabaNerve Interesting to see you also discussed it a few weeks ago. While that does mean nodes are still identifiable behind Tor, it doesn’t mean they’re trackable to where they’re running, which is what I’m promoting as the reason to use Tor with nodes. I can also promise you the Zcash network is much smaller than the Tor network so that aspect of the problem remains unchanged. The only benefit would be if node-Tor offers the fine grained circuit control I say would be needed in the thread I linked AND the existing Tor daemon does not expose such functionality. At that point, I’d ask what/how Arti is doing before coming to node-Tor.