1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
# 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.
* [Community team guidelines](https://gitlab.torproject.org/tpo/community/team/-/issues/5)
* [Tor project glossary](https://support.torproject.org/glossary/)
* [Specifications glossary](./glossary.md)
(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.
## Starting notes
We are moving towards using
[semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/):
put each thought, or sentence, or subclause, on its own line,
in the Markdown source text.
(This is not yet applied consistently,
and we won't reject contributions that don't write that way.)
## 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](./rend-spec/protocol-overview.html#imd-key-menagerie).
## 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](https://gitlab.torproject.org/tpo/core/trunnel/-/blob/main/doc/trunnel.md?ref_type=heads).
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>`.
|
