Arti 0.0.2 is released: API groundwork, refactoring, config, and optimism

Arti 0.0.2 is released: API groundwork, refactoring, config, and optimism

Arti is our ongoing project to create a working embeddable Tor client in Rust. It’s nowhere near ready to replace the main Tor implementation in C, but we believe that it’s the future.

We put out our first official release of Arti last month. It included a working SOCKS proxy client, a supported (but unstable) API for embedding, and all the basic features necessary for anonymous use of the Tor network.

With that done, our next major goal is our 0.1.0 milestone in March, where we’ll to have a (mostly) stable API that applications can rely on. With that in mind, we’re working on API completeness and ergonomics, and trying to get our breaking changes out of the way. We’re also trying to fill in small missing features and set the groundwork for future work on performance and reliability.

We’re planning to do releases every month or so until we put out an 0.1.0 release in March. Each release will break API compatibility until then, when we’ll start making an effort to keep the API a bit more stable.

So what’s new in Arti 0.0.2?

The Arti 0.0.2 release has a major refactor of the backend network code that implements circuits and channels, to better use the reactor architectural pattern and reduce the need for locks.

The configuration API has been completely rewritten, to make it easier for applications to change Arti’s configuration as needed, and to reuse the user’s main Arti configuration file (if they want to).

Optimistic streams are available, for applications that need to reduce stream startup latency.

There’s also a new backend (as yet unused) for asynchronous events, and a bunch of smaller changes throughout the codebase. See the changelog for a more complete list.

What to expect next

The next release will probably be pretty small: there are a lot of people on vacation in December. We’ll likely have preemptive circuit construction ready, and the ability to change the configuration of a running Arti client on the fly.

And if you help us out, we’ll have your user-driven API feedback!

Here’s how to try it out

We rely on users and volunteers to find problems in our software and suggest directions for its improvement. Although Arti isn’t yet ready for production use, it should work fine as a SOCKS proxy (if you’re willing to compile from source) and as an embeddable library (if you don’t mind a little API instability).

Assuming you’ve installed Arti (with cargo install arti, or directly from a cloned repository), you can use it to start a simple SOCKS proxy for making connections via Tor with:

$ arti proxy -p 9150

and use more or less as you would use the C Tor implementation!

(It doesn’t support onion services yet. If compilation doesn’t work, make sure you have development files for libsqlite installed on your platform.)

For more information, check out the README file. (For now, it assumes that you’re comfortable building Rust programs from the command line). Our CONTRIBUTING file has more information on installing development tools, and on using Arti inside of Tor Browser. (If you want to try that, please be aware that Arti doesn’t support onion services yet.)

When you find bugs, please report them on our bugtracker. You can request an account or report a bug anonymously.

And if this documentation doesn’t make sense, please ask questions! The questions you ask today might help improve the documentation tomorrow.

Call for comments—Urgent!

We need feedback on our APIs. Sure, we think we’re making them more complete and ergonomic… but it’s the users’ opinion that matters!

Here are some ideas of how you can help:

  1. You can read over the high-level APIs for the arti-client crate, and look for places where the documentation could be more clear, or where the API is ugly or hard to work with.

  2. Try writing more code with this API: what do you wish you could do with Tor in Rust? Give it a try! Does this API make it possible? Is any part of it harder than necessary? (If you want, maybe clean up your code and contribute it as an example?)


Thanks to everybody who’s contributed to this release, including dagon, Daniel Eades, Dimitris Apostolou, Neel Chauhan, S0AndS0, Trinity Pointard, and Yuan Lyu!

And thanks, of course, to Zcash Open Major Grants (ZOMG) for funding this project!


I’m one of the developers on Zebra, a Zcash cryptocurrency node.

I recently spent about a day adding Tor support to Zebra’s isolated connection API using arti-client.

When Zebra adds support for sending user-generated transactions, we can use this API to make sure they aren’t linked to the sender’s IP address. (Or to any other transactions we send.)

Overall the process went really smoothly. The API was easy to understand, the code is short and easy to read, and basic tests seem to work. (I wasn’t able to do comprehensive end-to-end tests, because Zebra doesn’t support creating transactions yet.)

I posted some detailed feedback about some tricky parts of the integration on the Zcash forums, but I wanted to let people know about it here as well:


Hi @teor :slight_smile: Thanks for sharing your development work on the integration of Tor into the Zebra API & a warm welcome to the Tor Project forum.