Enumerate every host the core may contact, and refuse everything else

[iderex]

A rule about where data goes is only as good as the list of destinations. Written
down, the list is short and checkable. Left implicit, it grows by one entry per
convenience, and nobody notices until an image proxy in a dependency starts
resolving hostnames.

What this produces

The complete list of destinations the core may reach. Today that is the server
address the operator configured, and nothing else. Artwork, metadata, playback
and authentication all resolve to that one host or to whatever it redirects to
within its own origin.

A stated rule for redirects, since a server that redirects artwork to a public
content network is sending a request, and therefore an address and a user agent,
somewhere the operator did not choose. Following it is a decision with a reason,
either way.

The rule for a server that delegates sign-in to an identity provider, where a
second host is genuinely involved and the operator's own server named it.

Done when

The list is recorded, every entry names who chose that destination, the redirect
rule is decided with its reason, and the list is the input to the check in #70.
Blocked on #68 and #29.

[iderex]

The list landed as docs/decisions/0069-every-host-the-core-may-contact.md, on cf9705d.

The list is one row, and every entry names the operator as the one who chose it: the origin of a server the operator configured, reached by everything the core does, from sign-in through to progress reports. The number of rows in a running core is the number of servers the operator added, the first at sign-in and any further one through the deliberate act in 0072, which adds a row rather than widening one. The set is empty before anything is configured, which is what makes #70's failure unambiguous.

The list is derived rather than written out for the same reason a document does not enumerate anything else here. A destination is in the set because the operator configured it, and a table naming particular hosts would drift against what a running core actually holds.

An origin is the scheme, the host and the port of the base address 0028 produced, not the host alone. Not the host alone, because a server behind a reverse proxy may share a machine with something else on another port, and because 0028 already fixes that a typed http:// is honoured rather than upgraded, which makes the scheme part of what the operator chose. A path is not part of it, since 0028 joins by concatenation and a server at a sub-path is one origin.

The redirect rule is decided with its reason. A redirect inside an origin already in the set is followed, which covers a server correcting a path or a version prefix. A redirect to anywhere else is refused, and it is refused before a request is sent to the new location, so nothing reaches it: not a credential, not a device identity, not the query. That is the same shape 0029 states for a connection whose certificate was not accepted, and for the same reason, which is that a failure discovered after the request went out is a request already delivered.

Name resolution is inside the set rather than something that happens before it. A name is resolved only for a host in the set, because a resolution is itself a request to somebody, it carries the name being looked up, and on a home network that somebody is frequently the operator's own router and afterwards their provider. A core that resolved first and checked afterwards has already told a third party which server the person uses.

The identity provider case is answered by not being in the set at all, and the record says why rather than leaving it to be assumed. The second host is genuinely involved and the operator's own server named it. The core still never contacts it: 0005 has the core hand back what the client must open, the platform open it, and the core receive only the result the server issues at the end, so every request the core makes on that route goes to the configured server. The place a server fetched its artwork from is named the same way, as a fact about the operator's server rather than a destination.

One thing is worth flagging rather than leaving inside the record. The refusal is answer-not-understood from 0004, because 0004's own table already routes a 3xx that surfaces to the caller there and a sixteenth kind is a change to that record and to every client. The fit is imperfect and the record says so: a cross-origin redirect is a shape the core understood and refused, and the word in the kind says the opposite. 0004 already names the measurement that would overturn it, which is answer-not-understood becoming the kind an operator sees most, read off the events in #100.

This stays open on its last condition. The list is recorded, every entry names who chose that destination, and the redirect rule is decided with its reason. Being the input to the check in #70 is not met, because #70 does not exist, and until it does this is a rule nothing refuses, which is 0068's own sentence about itself.