Sponsor-141.md

@@ -85,7 +85,7 @@ Administration of directory authorities is substantially more complex than admin
 In this Activity, we will first develop a phased transition plan to switch the network from C authorities to Arti authorities. Then we will consult with the authority operators, adjusting the plan as needed, to ensure that they believe the plan is achievable, sensible, and robust. If during this Activity we identify new necessary tooling for migration that we have not yet identified, we will develop those tools as part of O1.9. (We have not currently identified any such tooling, but any planning activity carries the possibility of finding unexpected second-order requirements.)
 
 
-**Objective 2: Arti supports all necessary relay types**
+## **Objective 2: Arti supports all necessary relay types**
 
 To achieve this Objective, we will build relay mode in Arti such that it can replace Tor for relays in the network. This includes supporting all necessary relay types: guards, middle relays, exits, and bridges (with and without pluggable transports). 
 
@@ -131,7 +131,7 @@ Some effort in this Activity is allocated for solving issues raised by operators
 
 After these requests are evaluated and we decide whether or not to resolve them, we will gauge our success based on whether relay operators report that these issues have been resolved and whether relay operators are able to migrate to Arti successfully, following the targets set in the M&E plan.
 
-**Objective 3: Arti is stable enough for general usage*
+## **Objective 3: Arti is stable enough for general usage*
 
 To achieve this Objective, we must test and tune Arti so we can ensure the new relay implementation is stable enough for general usage on supported modern operating systems. Across this Objective we will be analyzing the privacy implications of Arti, its robustness, and ensuring that Arti builds reproducibly.
 
@@ -168,7 +168,7 @@ Our current specifications are maintained in our specifications and proposals re
 Additionally, some documents in the `proposals` subdirectory of the repository mentioned above —those marked with "FINISHED" status in 000-index.txt—are proposals that are implemented in some version of Tor; the proposals themselves still need to be merged into the specifications proper. We will ensure that any of these proposals that are relevant to the work completed in this project are merged into the appropriate specification.
 
 
-**Objective 4: Arti relay implementation performs as well or better than C implementation**
+## **Objective 4: Arti relay implementation performs as well or better than C implementation**
 
 To achieve this Objective, we must profile and verify Arti relay performance and ensure that Arti relay implementation performs as well or better than the C implementation of Tor.
 
@@ -214,7 +214,7 @@ The algorithms that we will need to re-adjust based on work in this Activity:
 - Round-trip time congestion control (RTTCC) and Conflux: RTTCC is an algorithm to improve speed and reduce memory requirements for fast Tor relays by reducing queue lengths. Conflux7 is a dynamic traffic-splitting approach that assigns traffic to an overlay path based on its measured latency. Together, congestion control and Conflux are used to provide performance and improvements. (In the C implementation, RTTCC is implemented principally via the `src/core/or/conestion_control*.c` files. Conflux is principally implemented in the C implementation `src/core/or/conflux*.c`.)
   - Congestion control and Conflux are already implemented in Arti for a specific part of the Tor protocol. We will need to complete some minor adaptation, tuning, and refactoring to both in order to maximize performance and adjust to work completed above in this Activity.
 
-**Objective 5: The Tor network is significantly transitioned to Arti Relays**
+## **Objective 5: The Tor network is significantly transitioned to Arti Relays**
 
 In this Objective we will create the test network needed for testing all work created in this project, create a framework for evaluating the transition from the C implementation to Rust, develop any needed tools for relay operators to migrate their relays, and engage the community in a public campaign to encourage transition to Arti. This Objective is not about transitioning all relays to Arti—as stated above, the Tor Project does not control the volunteer relay operators and cannot force them to transition—but is about making a concerted effort to encourage a significant number of operators to transition through support and easy-to-use migration tools.
 
@@ -265,7 +265,7 @@ O5.4 Run public campaign to migrate to Arti: In this Activity, we will create an
     - If midterm evaluation reveals that we are not reaching targets, utilize the process previously created to modify the campaign plan
     - At the end of the campaign, evaluate transition against target numbers specified in the M&E plan
 
-**Objective 6:  Promote and encourage information sharing and collaboration between Internet Freedom Program Implementers**
+## **Objective 6:  Promote and encourage information sharing and collaboration between Internet Freedom Program Implementers**
 
 To achieve this objective we will work with DRL to host a DRL implementers meeting in March of 2024.