[tor-dev] The future of Tor client software?

[Nick Mathewson]

On Mon, Feb 13, 2023 at 4:20 AM Steven Engler <opara at sengler.ca> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230213/5b98a158/attachment.htm>