<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 13, 2023 at 4:20 AM Steven Engler <<a href="mailto:opara@sengler.ca">opara@sengler.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi tor-dev,<br>
<br>
In the past, there were generally two options for supporting Tor in an <br>
application.<br>
<br>
1. Require the user to install the tor daemon (ex: apt install tor, Tor <br>
Expert Bundle, etc) and configure the application to use its SOCKS proxy.<br>
<br>
2. Bundle the tor binary with the application (ex: Tor Browser) and have <br>
the application use the app-specific tor process as the SOCKS proxy.<br>
<br>
I'm not clear on how this changes in an Arti world. Arti currently has a <br>
Rust Tor client library for applications, and a CLI application to run a <br>
SOCKS proxy. Is there any plan to offer an Arti daemon (ex: a systemd <br>
service) for clients like with the current tor package? In a future <br>
where Arti replaces the Tor client and relay code, or when Arti is <br>
recommended for all client-related use cases, will there continue to be <br>
a Tor daemon with client support?<br></blockquote><div><br></div><div>Hi, Steven!</div><div><br></div><div>We're looking at a timeline more or less like this:</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">In the short term, both implementations will coexist.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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]<br></div><div><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>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.</div><div><br></div><div> 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 <a href="https://forum.torproject.net/t/defining-an-interface-to-arti/6432">https://forum.torproject.net/t/defining-an-interface-to-arti/6432</a> 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).<br></div><div> </div><div><br></div><div><br></div><div>[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.)<br><div class="gmail_quote"><br></div><div class="gmail_quote">best wishes,<br></div></div><div>-- <br></div><div>Nick<br></div></div></div>