# C-tor Transition to Arti Policy

Repository of C-tor: https://gitlab.torproject.org/tpo/core/tor

This page details why and how we will start limiting the patches that we
accept in our  C tor code, as it is slowly deprecated in favor of
[arti](https://arti.torproject.org), our Rust reimplementation of the Tor
protocols.

That might sound drastic, but there's no need to worry!  We're going to do our
best to keep the migration easy, and to manage our resources so that all users
and relay operators have a reliable code-base that they can use at every stage
of the process.

We do apologize for any inconvenience these changes might bring, but they are
unfortunately necessary so that our team can focus on producing the best
privacy software possible.

## Who should care?

This document is particularly relevant if you are:

- A developer integrating with tor.
- A C-tor code contributor

The changes described here won't affect you much yet if you are a user or relay operator.

## Why

C in general is old and unsafe, and our C code in particular is old and
hard-to-maintain.  We find that we are much more productive, safe, and
efficient programming in Rust.  With this in mind, we've started a Rust
implementation of the Tor protocols, [`arti`](https://arti.torproject.org/).

With time, we intend that Arti will be the primary supported implementation of
our protocols that we support.  We aren't there yet, of course!  It will take
a fair amount of time before we can declare that Arti is mature enough to
replace the old C implementation.

(Why not just support the C implementation forever?  That _would_ save
everybody the trouble of migrating, but it would come at an unacceptable cost.
Maintaining two implementations of all of our protocols would mean that we'd
have to make two implementations of every improvement that we make in the
future, which would _slow down_ the pace of development when the whole point
of moving to Arti is to try to improve that pace.)

## Current status

The C Tor code is a huge monolithic code base. That is, every single features
we have is packed into one binary: `tor`. But, our features can be divided
into **two** high level components:

1. Client
  * SOCKS Proxy (ex: Tor Browser using `tor`).
  * Onion Services
  * Pluggable Transport (client)

2. Relay
  * Relays
  * Bridges
  * Authorities (directory and bridge)
  * Pluggable Transport (relay)

Assuming that everything proceeds as planned, and we are able to find funding,
Arti is on track to work as a replacement for the **Client** (1) side of C tor
in late 2023.  (When it is ready, we will give users plenty of time to
upgrade.) We are also seeking funding in order to expand Arti development to
implement the Relay (2) component.

Our long-term intent is that Arti will become a complete replacement for the C
tor implementation, and eventually replace it entirely.  We will continue to
support the C tor implementation for a while after Arti is feature-complete,
but will eventually end support entirely.

### Contributions

Since we are focusing our efforts on Arti, we need to reduce our engineering
efforts to the tor.git code base: this will affect our capacity to handle
external contributions from our important and beloved contributors.

We want to encourage all contributors to shift their efforts to Arti and avoid
seeing their contributions being denied inclusion due to our lack of resources
to review and merge.  For more information on hacking on Arti, see
[`CONTRIBUTING.md`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CONTRIBUTING.md)
in the source repository.

## What is changing *now*

We are changing what kinds of patches we will accept for C tor,  and are
writing this to inform the community, so that people don't waste too much time
contributing code that we can't accept. 

For the **client** side of tor.git:

- New client features will generally **not** be accepted.[^1]
- **Only** security, stability and regression fixes will be accepted.

On the **relay** side, we still accept new features for now, but we will start
accepting fewer over time. Here are some topics that will likely to be refused
(not exhaustive):

- Memory or CPU optimization
- Code cleanup or removal
- Refactoring

The above is, as always, a best effort and the network team might decide, in a
specific context, to diverge from the policy. The decision will be made on a
case-by-case basis. For example, we'll likely approve nearly any change if
it's blocking another Tor Project team.

[^1]: :warning: We will still allow features or fixes in tor.git if the work
is necessary to fulfill a funded grant—for example, if we need to add a
feature that requires relay-side support. The grants that Tor Project gets
should shift towards Arti in the future.

See a deprecation breakdown draft [here](./DeprecationTorPhases)

### Help

Please, don't hesitate to join our development IRC channel on OFTC, #tor-dev
or drop us an email on our development mailing list
(tor-dev@lists.torproject.org) in order to seek help with a change you are
planning to work on before you start.

We can also help with your work on migrating feature(s) in C-tor to `arti`.

## Control Port

One last word about the [Control
Port](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/control-spec.txt).
It is a very vintage protocol and `arti` is moving towards **not**
re-implementing it—or at most, implementing a subset of it. We don't know yet.

And so, for that reason, we will most likely **not** accept any control port
changes at the moment, except for ones that are absolutely necessary. The
Network Team will decide then based on the need, usage, and arguments.

Please note that we're only talking about the control port _protocol.  The
_features_ available via the control port are not going away but rather will
be available with `arti` as an API or/and some sort of RPC mechanism (still
early to tell). This part is still in active design and development phase.