Hi tor-dev,
In the past, there were generally two options for supporting Tor in an
application.
1. Require the user to install the tor daemon (ex: apt install tor, Tor
Expert Bundle, etc) and configure the application to use its SOCKS proxy.
2. Bundle the tor binary with the application (ex: Tor Browser) and have
the application use the app-specific tor process as the SOCKS proxy.
I'm not clear on how this changes in an Arti world. Arti currently has a
Rust Tor client library for applications, and a CLI application to run a
SOCKS proxy. Is there any plan to offer an Arti daemon (ex: a systemd
service) for clients like with the current tor package? In a future
where Arti replaces the Tor client and relay code, or when Arti is
recommended for all client-related use cases, will there continue to be
a Tor daemon with client support?
Hi, Steven!
We're looking at a timeline more or less like this:
In the short term, both implementations will coexist.
In the medium term, we will deprecate the C Tor client implementation. This will not be until some time after Arti is a *complete* tor client with support for onion services, with a *complete *embedding/FFI/RPC solution.
In the long term, we intend that Arti will replace the C tor implementation completely. This means we'll have to implement relays and directory authorities with Arti. (We won't be starting this for a year at least, and it will probably take some while to achieve.)[1]
We intend that Arti will be usable in multiple deployment environments, including as a daemon that they talk to over an RPC-like protocol (analogous to the current control port) and as an embedded library. We want applications written in most any reasonable language to be able
to use Arti, and to be more or less agnostic about whether they're doing
it with an in-process library or over an RPC channel. Of course, this involves a lot of API work, and there will be a lot of design and prototyping to do. Our plan is to have this part ready for experimental use this year.
Right now, we're starting a working group of interested people to talk about getting all of these APIs right. You can see an initial thread at
https://forum.torproject.net/t/defining-an-interface-to-arti/6432 with links to different design sketches; pretty soon we hope that there will be a new subforum to work on the issue and discuss more. I'll follow up with a link once there is (unless somebody else does).
[1] (A note for
the anxious: We don't plan to stop C Tor support immediately when any of
these phases is done, but we do plan to do it after a reasonable time
for migration and making sure that the migration issues are solved. We
haven't committed to a schedule for this. Whatever we _do_ decide on will definitely be annoyingly long from some points of view, and annoyingly short from others.)
best wishes,
--
Nick