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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
# 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.)
<div id="mdbook-heading-anchors">
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 }`
</div>
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](#mdbook-heading-anchors).)
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.
|
