Filename: 372-remove-extra-info.md
Title: Removing extra-info
Author: Clara Engler
Created: 10-Nov-2026
Status: Open

Motivation

Historically, Tor bootstrapped using plain router descriptors. At one point in the past, it became evident that it would be useful to have relays publish additional information that is not required for bootstrapping but still useful to know, such as the number of seen hidden servers, the digest of the used geoip database, etc.

In order to keep the router descriptors more lightweight and allow clients to bootstrap faster, an additional format known as extra-info was created, which intends to hold such information. Instead of publishing these fields in the router descriptor, they are published in a separate signed document called the "extra-info", whose digest may be included in the actual router descriptor using the optional extra-info-digest field.

However, not shortly after that, the concept of micro descriptors got introduced, which have been standard for client bootstrapping for over 10 years by now. With this format, clients don't even have to download the ordinary router descriptors for bootstrapping anymore, as they are an entirely separate format.

Because of this, router descriptors are effectively only used by relays, metrics, and a negotiable number of clients that use obscure settings such as FetchServerDescriptor 1 and/or UseMicrodescriptors 0 which we will ignore for the sake of further argumentation. For these types of use cases, the argument to save bandwidth doesn't really apply. Besides, they already download and store the extra-infos regardless, thereby making the efficiency from splitting these documents obsolete.

Unfortunately, the concept of extra-infos comes with a big headache of implementation specific considerations:

  • What if a relay uploads a valid router descriptor but invalid extra-info?
  • What if a relay uploads a valid extra-info but invalid router descriptor?
  • What if the extra-info is validly signed but has a hash mismatch?
  • What if the SHA-1 matches but the SHA-256 does not, or vice versa?
  • What if the published date in the extra-info does not align with the one in the router descriptor?
  • Can the same extra-info be referenced by multiple router descriptors?
  • How to bootstrap extra-infos when they cannot be known in advance until the accompanying router descriptor is downloaded?
  • (This list is non-exhaustive)

Therefore, this proposal proposes to remove extra-infos as their own format and to merge the relevant fields contained inside extra-info inside router descriptors. What we hope to achieve by this is a reduction in code complexity.

Specification

We observe the facts that extra-infos are published at the same time as their router descriptors (i.e. there is an exact 1:1 relationship between router descriptors and extra-infos) and that their presence is entirely optional.

First and foremost, we modify the router descriptor format by moving the definitions of all fields defined in the extra-info format into it, except for the following fields:

  • identity-ed25519 (already contained in router descriptors)
  • published (already contained in router descriptors)
  • extra-info (no need for an intro item anymore)
  • router-sig-ed25519 (router descriptors are already signed)
  • router-signature (router descriptors are already signed)

For implementing this, we define a new relay protocol called "NoExtraInfo".

If a relay supports this proposal, it sets NoExtraInfo=1. If this is the case, the relay MUST no longer produce an extra-info document and is likewise no longer allowed to provide an extra-info-digest in its router descriptor. It SHOULD respond to all /tor/extra directory requests with "Not Found" and MAY remove all parsing/generation logic from its codebase. Likewise, it SHOULD no longer attempt to download any extra-infos from other relays or authorities.

Deploying this on the Tor network should happen in stages, where the first stage works in a hybrid mode where certain relays produce extra-infos and others don't, alongside a hard cut, at which NoExtraInfo=1 will be a part of required-relay-protocols.

In the far future, we might be able to also remove that protocol version, but only if we can guarantee it will not cause friction with existing clients.

Compatibility

Given the optionality of the extra-info-digest field alongside the forward compatibility of relays being able to accept router descriptors with fields they do not understand, we consider this proposal to introduce low compatibility friction on the protocol layer. However, certain external metrics tooling might break, although it will most likely be easily fixable, given that the fields do not disappear but rather just change their location.

Further Considerations

We still need to figure out what this would mean for bridges.