Onionoo

Onionoo is a web-based protocol to learn about currently running
Tor relays and bridges. Onionoo itself was not designed as a service
for human beings—at least not directly. Onionoo provides the
data for other applications and websites which in turn present Tor
network status information to humans.

The Onionoo service is designed as a RESTful web service.
Onionoo clients send HTTP GET requests to the Onionoo server which
responds with JSON-formatted replies.
Onionoo clients and their developers should follow a few rules:

Clients should handle response codes by
distinguishing between client and server errors, and if there's a problem,
informing their users about the kind of problem.
The following response codes are used:

There are plenty of reasons why we may have
to change the protocol described here.
Clients should be able to handle all valid JSON responses, ignoring
unknown fields and not breaking horribly in case of missing fields.
Protocol changes will be announced here by writing deprecated API parts with
the label deprecated and new parts
with the label new.
Deprecated parts will be removed one month after their announcement.

All responses contain a "version" string that
indicates whether clients can parse the document or not.
Version strings consist of a major and a minor version number.
The major version number is raised when previously required fields are
dropped or turned into optional fields, when request parameters or
response documents are removed, or when there are structural changes.
The minor version number is raised when new fields, request parameters, or
response documents are added or optional fields are dropped.
If clients support the same major version given in a response but only a
lower minor version, they should be able to parse the document but may not
understand all fields.
If clients support a lower major version, they should not attempt to parse
a document, because there may be backward-incompatible changes.

Responses may also contain the optional
"next_major_version_scheduled" field that announces when
the next major version is scheduled to be deployed.
Clients should inform their users that they should upgrade to the next
major protocol version before the provided date.

The following versions have been used in the past six months or are
scheduled to be deployed in the next months:

4.2:
Added "build_revision" field to response header
on October 10, 2017.
#

4.3:
Added a new "host_name" parameter to filter by host name and a new
"unreachable_or_addresses" field with declared but unreachable OR
addresses on November 17, 2017.
#

4.4:
Extended the "version" parameter to bridges, added a
"recommended_version" parameter for relays and bridges, added a
"version" field to relay and bridge details documents, and added a
"recommended_version" field to bridge details documents on November
28, 2017.
#

5.0:
Removed the $ from fingerprints in fields "effective_family", "alleged_family",
and "indirect_family" on December 20, 2017.
#

5.1:
Always added a relay's own fingerprint to its "effective_family" and made
nickname fields "n" in summary documents and "nickname" in details documents
required fields on March 14, 2018.
#

5.2:
Added "version_status" field to details documents on April 6, 2018.
#

6.0:
Included all exit addresses in "exit_addresses", regardless of whether they are
used as onion-routing addresses or not on April 17, 2018.
#

6.1:
Added a new "os" parameter to filter relays and bridges by operating
system, extended the "as" and "country" parameters by a special
country code and AS number to return relays that were not found in the
GeoIP database, and deprecated the "host_name" field in details
documents in favor of the new "verified_host_names" and
"unverified_host_names" fields for more accurate DNS results on July
16, 2018.
#

6.2:
Added an "as" field to details document, deprecated the "as_number" field, added
an "as_name" parameter to search for relays by AS name, and added support for
comma-separated lists in the "as" and the "lookup" parameters on August 3, 2018.
#

7.0:
(scheduled, but not deployed yet!): Extend the "version" parameter to support
lists and ranges, remove redundant "1_week" and "1_month" graphs from clients
documents, change "3_months" graphs to "6_months" graphs in all documents
containing history objects, remove the "fingerprint" parameter, and remove the
previously deprecated "as_number" field from details documents, to be deployed
after September 3, 2018.
#

Each of the methods can be parameterized to select only a subset of relay
and/or bridge documents that are currently running or that have been
running in the past week.
(The fingerprint parameter is special here, because it
allows selecting a specific relay or bridge, regardless of whether it has
been running in the past week.)
If multiple parameters are specified, they are combined using a logical
AND operation, meaning that only the intersection of relays and bridges
matching all parameters is returned.
If the same parameter is specified more than once, only the first
parameter value is considered.

Return only (1) relays with the parameter value matching (part of a)
nickname, (possibly $-prefixed) beginning of a hex-encoded fingerprint,
any 4 hex character block of a space-separated fingerprint, beginning of a
base64-encoded fingerprint without trailing equal signs, or beginning of
an IP address (possibly enclosed in square brackets in case of IPv6),
(2) bridges with (part of a) nickname or (possibly
$-prefixed) beginning of a hashed hex-encoded fingerprint, and (3) relays
and/or bridges matching a given qualified search term.
Searches by relay IP address include all known addresses used for onion
routing and for exiting to the Internet.
Searches for beginnings of IP addresses are performed on textual
representations of canonical IP address forms, so that searches using CIDR
notation or non-canonical forms will return empty results.
Searches are case-insensitive, except for base64-encoded fingerprints.
If multiple search terms are given, separated by spaces, the intersection
of all relays and bridges matching all search terms will be returned.
Complete hex-encoded fingerprints should always be hashed using SHA-1,
regardless of searching for a relay or a bridge, in order to not
accidentally leak non-hashed bridge fingerprints in the URL.
Qualified search terms have the form "key:value" (without double quotes)
with "key" being one of the parameters listed here except for "search",
"fingerprint", "order", "limit", "offset", and "fields", and "value" being
the string that will internally be passed to that parameter.
If a qualified search term for a given "key" is specified more than once,
only the first "value" is considered.

Return only the relay with the parameter
value matching the fingerprint or the bridge with the parameter value
matching the hashed fingerprint.
Fingerprints should always be hashed using SHA-1, regardless of looking up
a relay or a bridge, in order to not accidentally leak non-hashed bridge
fingerprints in the URL.
Lookups only work for full fingerprints or hashed fingerprints consisting
of 40 hex characters.
Lookups are case-insensitive.

Return only the relay with the parameter value matching the fingerprint
or the bridge with the parameter value matching the hashed fingerprint.
Fingerprints must consist of 40 hex characters, case does not matter.
This parameter is quite similar to the lookup parameter
with two exceptions:
(1) the provided relay fingerprint or hashed bridge fingerprint must
not be hashed (again) using SHA-1;
(2) the response will contain any matching relay or bridge regardless of
whether they have been running in the past week.
Scheduled to be removed after September 3, 2018.

Return only relays which are located in the given country as identified by a
two-letter country code. Filtering by country code is case-insensitive. The
special country code xz can be used for relays that were not found in
the GeoIP database.
Updated to recognize special country code
xz on July
16, 2018.

Return only relays which are located in either one of the given autonomous
systems (AS) as identified by AS number (with or without preceding "AS" part).
Multiple AS numbers can be provided separated by commas.
Filtering by AS number is case-insensitive.
The special AS number 0 can be used for relays that were not found in
the GeoIP database.
Updated to recognize special AS number 0
on July 16, 2018 and to support comma-separated lists of AS numbers on August 3,
2018.

Return only relays with the parameter value matching (part of) the autonomous
system (AS) name they are located in.
If the parameter value contains spaces, only relays are returned which
contain all space-separated parts in their AS name.
Only printable ASCII characters are permitted in the parameter value,
some of which need to be percent-encoded (# as %23, % as %25, & as
%26, + as %2B, and / as %2F).
Comparisons are case-insensitive.
Added on August 3, 2018.

Return only relays which have the
given relay flag assigned by the directory authorities.
Note that if the flag parameter is specified more than once, only the
first parameter value will be considered.
Filtering by flag is case-insensitive.

Return only relays or bridges which
have first been seen during the given range of days ago.
A parameter value "x-y" with x <= y returns relays or bridges that have
first been seen at least x and at most y days ago.
Accepted short forms are "x", "x-", and "-y" which are interpreted as
"x-x", "x-infinity", and "0-y".

Return only relays or bridges which
have last been seen during the given range of days ago.
A parameter value "x-y" with x <= y returns relays or bridges that have
last been seen at least x and at most y days ago.
Accepted short forms are "x", "x-", and "-y" which are interpreted as
"x-x", "x-infinity", and "0-y".
Note that relays and bridges that haven't been running in the past week
are not included in results, so that setting x to 8 or higher will lead to
an empty result set.

Return only relays with the parameter value
matching (part of) the contact line.
If the parameter value contains spaces, only relays are returned which
contain all space-separated parts in their contact line.
Only printable ASCII characters are permitted in the parameter value,
some of which need to be percent-encoded (# as %23, % as %25, & as
%26, + as %2B, and / as %2F).
Comparisons are case-insensitive.

Return only the relay whose fingerprint matches the parameter value and
all relays that this relay has listed in its family by fingerprint and
that in turn have listed this relay in their family by fingerprint.
If relays have listed other relays in their family by nickname, those
family relationships will not be considered, regardless of whether they
have the Named flag or not.
The provided relay fingerprint must consist of 40 hex characters where
case does not matter, and it must not be hashed using SHA-1.
Bridges are not contained in the result, regardless of whether they define
a family.

Return only relays or bridges running a Tor version that starts with the
parameter value without leading "Tor".
Searches are case-insensitive.
Scheduled to support lists and ranges after September 3,
2018:
Return only relays or bridges running either Tor version from a list or range
given in the parameter value.
Tor versions must be provided without the leading "Tor"
part.
Multiple versions can either be provided as a comma-separated list (","), as a
range separated by two dots (".."), or as a list of ranges.
Provided versions are parsed and matched by parsed dotted numbers, rather than
by string prefix.

Return only relays with a domain name ending in the given (partial)
host name.
Searches for subdomains of a specific domain should ideally be prefixed
with a period, for example: ".csail.mit.edu".
Non-ASCII host name characters must be encoded as punycode.
Filtering by host name is case-insensitive.

Return only relays and bridges running a Tor software version that is
recommended (parameter value true) or not recommended by
the directory authorities (parameter value false).
Uses the version in the consensus or bridge network status.
Relays and bridges are not contained in either result, if the version they
are running is not known.
Parameter values are case-insensitive.

Response documents can be reduced in size by requesting only a subset
of contained fields.

Comma-separated list of fields that will be
included in the result.
So far, only top-level fields in relay or bridge objects of details
documents can be specified, e.g.,
nickname,hashed_fingerprint.
If the fields parameter is provided, all other fields which are not
contained in the provided list will be removed from the result.
Field names are case-insensitive.

Relay and/or bridge documents in the response can be ordered and
limited by providing further parameters.
If the same parameter is specified more than once, only the first
parameter value is considered.

Re-order results by a comma-separated list
of fields in ascending or descending order.
Results are first ordered by the first list element, then by the second,
and so on.
Possible fields for ordering are: consensus_weight and
first_seen.
Field names are case-insensitive.
Ascending order is the default; descending order is selected by prepending
fields with a minus sign (-).
Field names can be listed at most once in either ascending or descending
order.
Relays or bridges which don't have any value for a field to be ordered by
are always appended to the end, regardless or sorting order.
The ordering is defined independent of the requested document type and
does not require the ordering field to be contained in the document.
If no order parameter is given, ordering of results is
undefined.

Limit result to the given number of
relays and/or bridges.
Relays are kept first, then bridges.
Non-positive limit values are treated as zero and lead
to an empty
result.
When used together with offset, the offsetting step
precedes the
limiting step.

Array of IPv4 or IPv6 addresses where the relay accepts
onion-routing connections or which the relay used to exit to the Internet
in the past 24 hours.
The first address is the primary onion-routing address that the relay used
to register in the network, subsequent addresses are in arbitrary order.
IPv6 hex characters are all lower-case.

Details documents are based on network statuses published by the Tor
directories, server descriptors published by relays and bridges, and data
published by Tor network services TorDNSEL and BridgeDB.
Details documents use the most recently published data from these sources,
which may lead to contradictions between fields based on different sources
in rare edge cases.

Array of IPv4 or IPv6 addresses and TCP ports
or port lists where the relay accepts onion-routing connections.
The first address is the primary onion-routing address that the relay used
to register in the network, subsequent addresses are in arbitrary order.
IPv6 hex characters are all lower-case.

Array of IPv4 addresses that the
relay used to exit to the Internet in the past 24 hours.
Omitted if array is empty.
Changed on April 17, 2018 to include all exit addresses, regardless of whether
they are used as onion-routing addresses or not.

UTC timestamp (YYYY-MM-DD
hh:mm:ss) when this relay last stopped announcing an IPv4 or IPv6 address
or TCP port where it previously accepted onion-routing or directory
connections.
This timestamp can serve as indicator whether this relay would be a
suitable fallback directory.

Boolean field saying whether this relay indicated that it is hibernating
in its last known server descriptor.
This information may be helpful to decide whether a relay that is not
running anymore has reached its accounting limit and has not dropped out
of the network for another, unknown reason.
Omitted if either the relay is not hibernating, or if no information is
available about the hibernation status of the relay.

Country name as found in a GeoIP database by
resolving the relay's first onion-routing IP address.
Omitted if the relay IP address could not be found in the GeoIP
database, or if the GeoIP database did not contain a country name.

Region name as found in a GeoIP database by
resolving the relay's first onion-routing IP address.
Omitted if the relay IP address could not be found in the GeoIP
database, or if the GeoIP database did not contain a region name.

City name as found in a
GeoIP database by resolving the relay's first onion-routing IP address.
Omitted if the relay IP address could not be found in the GeoIP
database, or if the GeoIP database did not contain a city name.

AS number as found in an AS database by
resolving the relay's first onion-routing IP address.
AS number strings start with "AS", followed directly by the AS number.
Omitted if the relay IP address could not be found in the AS
database.
Added on August 3, 2018.

AS number as found in an AS database by
resolving the relay's first onion-routing IP address.
AS number strings start with "AS", followed directly by the AS number.
Omitted if the relay IP address could not be found in the AS
database.
Scheduled to be removed after September 3, 2018.

Weight assigned to this relay by the
directory authorities that clients use in their path selection algorithm.
The unit is arbitrary; currently it's kilobytes per second, but that might
change in the future.

Host name as found in a reverse DNS lookup of the
relay's primary IP address.
This field is updated at most once in 12 hours, unless the relay IP
address changes.
Omitted if the relay IP address was not looked up, if no lookup request
was successful yet, or if no A record was found matching the PTR record.
Deprecated on July 16, 2018.

Host names as found in a reverse DNS lookup of the
relay's primary IP address for which a matching
A record was also found.
This field is updated at most once in 12 hours, unless the relay IP
address changes.
Omitted if the relay IP address was not looked up, if no lookup request
was successful yet, or if no A records were found matching the PTR records
(i.e. it was not possible to verify the value of any of the PTR records).
Added on July 16, 2018.

Host names as found in a reverse DNS lookup of the
relay's primary IP address that for which a matching A record was not found.
This field is updated at most once in 12 hours, unless the relay IP
address changes.
Omitted if the relay IP address was not looked up, if no lookup request
was successful yet, or if A records were found matching all PTR records
(i.e. it was possible to verify the value of each of the PTR records).
Added on July 16, 2018.

Bandwidth
estimate in bytes per second of the capacity this relay can handle.
The relay remembers the maximum bandwidth sustained output over any ten
second period in the past day, and another sustained input.
The "observed_bandwidth" value is the lesser of these two numbers.
Missing if router descriptor containing this information cannot be
found.

Bandwidth in bytes per second that this
relay is willing and capable to provide.
This bandwidth value is the minimum of bandwidth_rate,
bandwidth_burst, and observed_bandwidth.
Missing if router descriptor containing this information cannot be
found.

Array of exit-policy lines.
Missing if router descriptor containing this information cannot be
found.
May contradict the "exit_policy_summary" field in a rare
edge case: this happens when the relay changes its exit policy after the
directory authorities summarized the previous exit policy.

Summary
version of the relay's exit policy containing a dictionary with either an
"accept" or a "reject" element.
If there is an "accept" ("reject") element, the relay accepts (rejects)
all TCP ports or port ranges in the given list for most IP addresses and
rejects (accepts) all other ports.
May contradict the "exit_policy" field in a rare edge
case: this happens when the relay changes its exit policy after the
directory authorities summarized the previous exit policy.

Summary version of the relay's IPv6 exit policy containing a dictionary
with either an "accept" or a "reject" element.
If there is an "accept" ("reject") element, the relay accepts (rejects)
all TCP ports or port ranges in the given list for most IP addresses and
rejects (accepts) all other ports.
Missing if the relay rejects all connections to IPv6 addresses.
May contradict the "exit_policy_summary" field in a rare
edge case: this happens when the relay changes its exit policy after the
directory authorities summarized the previous exit policy.

Tor software version without leading "Tor" as reported
by the directory authorities in the "v" line of the consensus.
Omitted if either the directory authorities or the relay did not report
which version the relay runs or if the relay runs an alternative Tor
implementation.

Boolean field saying whether the Tor software version of this relay is
recommended by the directory authorities or not.
Uses the relay version in the consensus.
Omitted if either the directory authorities did not recommend versions, or
the relay did not report which version it runs.

Status of the Tor software version of this relay based on the versions
recommended by the directory authorities.
Possible version statuses are:
"recommended" if a version is listed as recommended;
"experimental" if a version is newer than every recommended version;
"obsolete" if a version is older than every recommended version;
"new in series" if a version has other recommended versions with the same first
three components, and the version is newer than all such recommended versions,
but it is not newer than every recommended version;
"unrecommended" if none of the above conditions hold.
Omitted if either the directory authorities did not recommend versions, or the
relay did not report which version it runs.
Added on April 6, 2018.

Array of fingerprints of relays that are in an effective,
mutual family relationship with this relay.
These relays are part of this relay's family and they consider this relay
to be part of their family.
Always contains the relay's own fingerprint.
Omitted if the descriptor containing this information cannot be found.
Updated to always include the relay's own fingerprint on
March 14, 2018.

Array of fingerprints of relays that are not in an effective,
mutual family relationship with this relay.
These relays are part of this relay's family but they don't consider this
relay to be part of their family.
Omitted if empty or if descriptor containing this information cannot be
found.

Array of fingerprints of relays that are not in an effective,
mutual family relationship with this relay but that can be reached by
following effective, mutual family relationships starting at this relay.
Omitted if empty or if descriptor containing this information cannot be
found.

Fraction of this relay's consensus weight compared to the sum of all
consensus weights in the network.
This fraction is a very rough approximation of the probability of this
relay to be selected by clients.
Omitted if the relay is not running.

Probability of this relay to be selected for the guard position.
This probability is calculated based on consensus weights, relay flags,
and bandwidth weights in the consensus.
Path selection depends on more factors, so that this probability can only
be an approximation.
Omitted if the relay is not running, or the consensus does not contain
bandwidth weights.

Probability of this relay to be selected for the middle position.
This probability is calculated based on consensus weights, relay flags,
and bandwidth weights in the consensus.
Path selection depends on more factors, so that this probability can only
be an approximation.
Omitted if the relay is not running, or the consensus does not contain
bandwidth weights.

Probability of this relay to be selected for the exit position.
This probability is calculated based on consensus weights, relay flags,
and bandwidth weights in the consensus.
Path selection depends on more factors, so that this probability can only
be an approximation.
Omitted if the relay is not running, or the consensus does not contain
bandwidth weights.

Boolean field saying whether the consensus weight of this relay is based
on a threshold of 3 or more measurements by Tor bandwidth authorities.
Omitted if the network status consensus containing this relay does not
contain measurement information.

Array of IPv4 or IPv6 addresses and TCP ports or port lists where the
relay claims in its descriptor to accept onion-routing connections but
that the directory authorities failed to confirm as reachable.
Contains only additional addresses of a relay that are found unreachable
and only as long as a minority of directory authorities performs
reachability tests on these additional addresses.
Relays with an unreachable primary address are not included in the
network status consensus and excluded entirely.
Likewise, relays with unreachable additional addresses tested by a
majority of directory authorities are not included in the network status
consensus and excluded here, too.
If at any point network status votes will be added to the processing,
relays with unreachable addresses will be included here.
Addresses are in arbitrary order.
IPv6 hex characters are all lower-case.
Omitted if empty.

Array of sanitized IPv4 or IPv6 addresses and
TCP ports or port lists where the bridge accepts onion-routing
connections.
The first address is the primary onion-routing address that the bridge
used to register in the network, subsequent addresses are in arbitrary
order.
IPv6 hex characters are all lower-case.
Sanitized IP addresses are always in 10/8 or
[fd9f:2e19:3bcf/48] IP networks and are only useful to
learn which
IP version the bridge uses and to detect whether the bridge changed its
address.
Sanitized IP addresses always change on the 1st of every month at 00:00:00
UTC, regardless of the bridge actually changing its IP address.
TCP ports are not sanitized.

Bandwidth in bytes per second that this
bridge is willing and capable to provide.
This bandwidth value is the minimum of bandwidth_rate,
bandwidth_burst, and observed_bandwidth.
Missing if router descriptor containing this information cannot be
found.

Tor software version without leading "Tor" as reported
by the bridge in the "platform" line of its server descriptor.
Omitted if not provided by the bridge, if the descriptor containing this
information cannot be found, or if the bridge runs an alternative Tor
implementation.

Boolean field saying whether the Tor software version of this bridge is
recommended by the directory authorities or not.
Uses the bridge version in the bridge network status.
Omitted if either the directory authorities did not recommend versions, or
the bridge did not report which version it runs.

Status of the Tor software version of this bridge based on the versions
recommended by the directory authorities.
Possible version statuses are:
"recommended" if a version is listed as recommended;
"experimental" if a version is newer than every recommended version;
"obsolete" if a version is older than every recommended version;
"new in series" if a version has other recommended versions with the same first
three components, and the version is newer than all such recommended versions,
but it is not newer than every recommended version;
"unrecommended" if none of the above conditions hold.
Omitted if either the directory authorities did not recommend versions, or the
bridge did not report which version it runs.
Added on April 6, 2018.

Bandwidth documents contain aggregate statistics of a relay's or
bridge's consumed bandwidth for different time intervals.
Bandwidth documents are only updated when a relay or bridge publishes a
new server descriptor, which may take up to 18 hours during normal
operation.

Object containing graph history objects with written bytes for different
time periods.
Keys are string representation of the time period covered by the graph
history object.
Keys are fixed strings "3_days",
"1_week", "1_month",
"3_months", "1_year", and
"5_years".
Keys refer to the last known bandwidth history of a relay, not to the time
when the bandwidth document was published.
A graph history object is only contained if the time period it covers is
not already contained in another graph history object with shorter time
period and higher data resolution.
Similarly, a graph history object is excluded if the relay did not provide
bandwidth histories on the required level of detail.
The unit is bytes per second.
Contained graph history objects may contain null values if the relay did
not provide any bandwidth data or only data for less than 20% of a given
time period.
Scheduled to no longer contain a "3_months" graph and instead
a "6_months" graph after September 3, 2018.

Weights documents contain aggregate statistics of a relay's probability
to be selected by clients for building paths.
Weights documents contain different time intervals and are available for
relays only.

History object containing the
fraction of this relay's consensus weight compared to the sum of all
consensus weights in the network.
This fraction is a very rough approximation of the probability of this
relay to be selected by clients.
Keys are string representation of the time period covered by the graph
history object.
Keys are fixed strings "1_week",
"1_month", "3_months",
"1_year", and "5_years".
Keys refer to the last known weights history of a relay, not to the time
when the weights document was published.
A graph history object is only contained if the time period it covers is
not already contained in another graph history object with shorter time
period and higher data resolution.
The unit is path-selection probability.
Contained graph history objects may contain null values if the relay was
running less than 20% of a given time period.
Scheduled to no longer contain a "3_months" graph and instead
a "6_months" graph after September 3, 2018.

History object containing the probability
of this relay to be selected for the guard position.
This probability is calculated based on consensus weights, relay flags,
and bandwidth weights in the consensus.
Path selection depends on more factors, so that this probability can only
be an approximation.
The specification of this history object is similar to that in the
consensus_weight_fraction field above.

History object containing the probability
of this relay to be selected for the middle position.
This probability is calculated based on consensus weights, relay flags,
and bandwidth weights in the consensus.
Path selection depends on more factors, so that this probability can only
be an approximation.
The specification of this history object is similar to that in the
consensus_weight_fraction field above.

History object containing the probability
of this relay to be selected for the exit position.
This probability is calculated based on consensus weights, relay flags,
and bandwidth weights in the consensus.
Path selection depends on more factors, so that this probability can only
be an approximation.
The specification of this history object is similar to that in the
consensus_weight_fraction field above.

Clients documents contain estimates of the average number of clients
connecting to a bridge every day.
There are no clients documents available for relays, just for bridges.
Clients documents contain different time intervals and are available for
bridges only.

Object containing graph history objects with the average number of clients
connecting to this bridge.
Keys are string representation of the time period covered by the graph
history object.
Keys are fixed strings "1_week",
"1_month", "3_months",
"1_year", and "5_years".
Keys refer to the last known clients history of a bridge, not to the time
when the clients document was published.
A graph history object is only contained if the time period it covers
is not already contained in another clients graph object with shorter
time period and higher data resolution.
The unit is number of clients.
Contained graph history objects may contain null values if the bridge did
not report client statistics for at least 50% of a given time period.
Scheduled to no longer contain "1_week", "1_month", and
"3_months" graphs and instead a "6_months" graph after September 3, 2018.

Object containing graph history objects with the fractional uptime of this
relay.
Keys are string representation of the time period covered by the graph
history object.
Keys are fixed strings "1_week",
"1_month", "3_months",
"1_year", and "5_years".
Keys refer to the last known uptime history of a relay, not to the time
when the uptime document was published.
A graph history object is only contained if the time period it covers is
not already contained in another graph history object with shorter time
period and higher data resolution.
The unit is fractional uptime from 0 to 1.
Contained graph history objects may contain null values if less than 20%
of network statuses have been processed for a given time period.
Scheduled to no longer contain a "3_months" graph and instead
a "6_months" graph after September 3, 2018.

Object containing fractional times of this relay having relay flags
assigned.
Keys are flag names like "Running" or
"Exit", values are objects similar to the
uptime field above, again with keys like
"1_week" etc.
If a relay never had a given relay flag assigned, no object is included
for that flag.

The following examples illustrate how to build requests for some trivial
and some more complex use cases.
While Onionoo is designed mainly for developers and not end users, there
may be cases when it's easier to quickly write a specific query Onionoo
rather than to find an Onionoo client that provides the desired
information.

This material is supported in part by the National Science Foundation
under Grant No. CNS-0959138. Any opinions, finding, and conclusions or
recommendations expressed in this material are those of the author(s) and do not
necessarily reflect the views of the National Science Foundation. "Tor" and the
"Onion Logo" are registered trademarks of The Tor Project, Inc.. Data on this
site is freely available under a CC0 no
copyright declaration: To the extent possible under law, the Tor Project has
waived all copyright and related or neighboring rights in the data. Graphs are
licensed under a Creative Commons Attribution 3.0 United States License.