To build the list of trusted Satellite URLs each entry in the configuration is
traversed in order, parsed, and processed accordingly:
1. If the entry begins with a `!`, it represents an untrusted Satellite entry. It is added to the `untrusted` list, which is used later.
1. If the entry begins with `file://`, `http://`, or `https://`, it is a Trusted Satellite List URL. The URL is used to fetch a list of Trusted Satellite URLs that are added into the `trusted` list.
1. If the entry begins with `storj://`, or otherwise does not use a scheme, it is a trusted Satellite URL entry. It is added into the `trusted` list.
1. If an entry does not match any of the above, it is a configuration error.
If a Trusted Satellite List cannot be fetched a warning should be logged. If
available, the last known copy from the Trusted Satellite List URL should be
used. Storage Nodes should attempt to persist the downloaded lists. If they
cannot, a warning should be logged.
After all configuration entries have been processed, each URL in the `trusted`
list is checked against the `untrusted` list and removed if it matches an entry
. An `untrusted` entry matches a URL using the following criteria:
* When the `untrusted` entry is just a Satellite ID, it matches any URL with
that ID.
* When the `untrusted` entry is just a host, it matches any URL with the same
host. If the host is a domain name, then the entry also matches URLs within a
subdomain of that host.
* When the `untrusted` entry is a full Satellite URL, it matches any URL that
is equal.
After the `trusted` list has been pruned, the remaining URLs are aggregated
according to the following rules:
* A Satellite URL is considered _authoritative_ if it matches either of the
following criteria:
* Configured via a Trusted Satellite URL entry
* Configured via a `file://` URL
* Configured via an `https://` or `http://` Trusted Satellite List URL AND matches the domain or is a subdomain of the domain name in the Trusted Satellite List URL.
* Satellite URLs are equivalent if the address portions are equal.
* When aggregating equivalent Satellite URLs (i.e. address matches) with
differing IDs, the _authoritative_ Satellite URL wins. If neither or both are
_authoritative_, the one aggregated first wins.
#### Example
Consider the following Trusted Satellite List URLs and their contents. For
brevity sake, the full ID of each URL is being shortened (real configurations
**MUST** specify the full ID).
*`file:///path/to/some/trusted-satellites.txt`
```
1@bar.test:7777
```
*`https://foo.test/trusted-satellites`
```
2@f.foo.test:7777
2@buz.test:7777
2@qiz.test:7777
5@ohno.test:7777
```
*`https://bar.test/trusted-satellites`
```
3@f.foo.test:7777
3@bar.test:7777
3@baz.test:7777
3@buz.test:7777
3@quz.test:7777
```
*`https://baz.test/trusted-satellites`
```
4@baz.test:7777
4@qiz.test:7777
4@subdomain.quz.test:7777
```
Now consider the following configuration:
```
- !quz.test
- file:///path/to/some/trusted-satellites.txt
- https://foo.test/trusted-satellites
- https://bar.test/trusted-satellites
- https://baz.test/trusted-satellites
- 0@f.foo.test:7777
- !2@qiz.test:7777
- !5
```
After expanding each entry, we have the following unaggregated `trusted` list:
```
1@bar.test:7777 (authoritative due to file:// URL)
2@f.foo.test:7777 (authoritative due to foo.test domain)
2@buz.test:7777
2@qiz.test:7777
5@ohno.test:7777
3@f.foo.test:7777
3@bar.test:7777 (authoritative due to bar.test domain)
3@baz.test:7777
3@buz.test:7777
3@quz.test:7777
4@baz.test:7777 (authoritative due to baz.test domain)
4@qiz.test:7777
4@subdomain.quz.test:7777
0@f.foo.test:7777 (authoritative due to explicit configuration)