Tor specifications: style and usage notes

Audience

The primary intended audiences are:

Programmers: implementors of the Tor Protocols. This includes both maintainers of existing implementations, and people writing new implementations.
Researchers: people analysing the security of the Tor Protocols, including both academic research and practical security investigation.
Expert users who wish to fully understand the operation of their Tor software. This includes users of clients and relays.
Directory authority operators, and others with a critical technical role in the integrity of the Tor network.

Scope and intentions

These notes apply to our specifications. When possible, they should also apply to proposals, to make proposals easier to merge into our specifications when they are done.

As of 2023, our existing specifications have been written without any real style guidelines, so you should not expect to find these guidelines to apply well to all of the documents as you read them. Instead, these guidelines are for documentation going forward.

These notes are not terribly well organized. We should improve them over time. They are meant to be a living document.

Other sources

There are a number of other style guides used in Tor. We should follow these as well. If they do not suit our needs, we should try to get them changed.

(Please add more if you know about them!)

As we refine the guidelines in this file, we should attempt to get them upstreamed to more project-wide guides, if they are suitable.

Line breaks

Begin each new thought, sentence, or subclause on its own line. Keep lines short enough to be readable on a terminal (~80 columns), but don't reflow text unnecessarily. This makes diffs easier to review, while still keeping the text fairly readable in its raw form. See semantic linefeeds for history and a more detailed explanation of why this is useful.

Vocabulary

We use these terms freely:

Channel
Circuit
Stream

We try not to say "connection" without qualification: There are too many things in Tor that can be called a "connection".

Similarly, don't say "session" without qualification except when it is clear from context what we mean.

Prefer "relay" to "node" or "server".

Prefer "service" and "client" when talking about onion services and their users.

Refer to arti as arti and the C tor implementation as "the C tor implementation" on first mention. Subsequently you can call it tor or "C tor".

Avoid "AP" and "OP" and "OR"; those are not in current usage.

Documenting keys

TODO: Explain our new key documentation conventions, as used here.

Documentating data encodings

We have two competing legacy schemes for documenting data encodings. One of them is an ad-hoc format the looks like this:

   * FIELD_1     [4 bytes]
   * FIELD_2     [1 byte]

The other is a somewhat C-like format based on the trunnel format. It looks like this:

struct message {
   u32 field_1;
   u8 field_2;
}

Neither of these is really great. We should find something better.

Writing explanations

When you are writing an explanation in the middle of a bunch of normative text, it is a good idea to put it in quoted text, like this.

Managing links

We're in the early stages of this spec organization, but we should still be thinking about long term maintainability.

Please think about how to keep links working in the long term. If you are going to add a link to a file, make sure that the file's name is reasonable. Before you rename a file, consider adding a redirect from the file's old name. (See the mdbook documentation for more information about how.)

If you want to link to a specific section within a file, make sure that the section has a defined anchor that makes sense. The syntax to define heading ids in mdbook looks like this:

## Heading with a long title that you want shorter name for { #shortname }

If you need to change a heading, make sure that you keep its id the same as it was before, so that links will still work.

Finally, when you're looking for specific sections (e.g., to fix references that say "See section 5.2.3") you can look for the HTML anchors that our conversion process added. For example, if you want to find dir-spec.txt section 2.1.3, look for the anchor that says <a id="dir-spec.txt-2.1.3"></a>.

Specific Markdown syntax

Define link fragment targets with `<span id="...">` (usually)

To manually make an target for a #-prefixed link fragment, prefer <span id="fragment">Text</span>, to <a id=...>Text</a>. This works around mdbook mistakenly styling <a> without href as if it were a clickable link.

(Of course it is often better to make the referenced text a section and use the mdbook explicit anchor syntax.)

You may need to make sure you have some other text on the same line as the <span> to avoid mdbook thinking you were writing a whole paragraph of raw HTML.

Sometimes you may wish to use <div id="..."> and </div> (which must usually be placed as paragraphs of their own).

Example:

<span id="lemons-lemonade">LEMONS
are a sour fruit, sometimes used for making
lemonade</span>

(later)

Various fruit may be found, including [lemons](#lemons-lemonade).

It is OK to use an empty a element: <a id=....></a>. Many existing section anchors are done this way.

Tor Specifications