Read whether this install allows mature content

GET

/admin/system/mature-content

• Local development behind nginx (port 8088 by default)

The operator’s install-wide mature-content switch (#1116, epic #1114, ADR 0090 §2).

An install that has never configured this reads back allowed: true, and that default is deliberate: an install upgraded into this feature has consented to nothing, and the only safe reading of “no row” is the behaviour it already had — which is one with no mature machinery at all, i.e. one where nothing is filtered. The reading that seems safer (absent means disallowed) is the one that breaks an upgrade, by making every existing install refuse mature publication on the day it upgraded, for a flag none of their assets carry.

Note what allowing does NOT do: it shows nothing to anybody on its own. A viewer still has to be signed in AND opted in, and the opt-in defaults OFF. This switch is permissive about the OPERATOR’s intent, never about a reader’s.

There is no public counterpart to this endpoint. Every consumer of the answer — the upload self-label, the operator override, the account opt-in — is behind authentication, so the value rides the session response as CurrentUser.mature_content_allowed instead of being published to anonymous callers.

Authorizations

• cookieAuth
• bearerAuth

Responses

200

The install’s mature-content switch

The install-wide mature-content switch (#1116, ADR 0090 §2).

⚠️ THE WIRE FIELD IS NAMED FOR THE PERMISSIVE DIRECTION AND THE STORED ONE IS NOT, and the difference is not an oversight. The stored struct’s field is disallowed, so its ZERO VALUE — an empty blob, a partial decode, an install that has never configured this — reads as the permissive upgrade default. The wire field is allowed, because that is the question an operator is answering, and it is REQUIRED so no zero value is ever in play on this side: a body that omits it is a 400, not a silent switch-off.

object

allowed

required

Whether this install permits mature content at all. true for an install that has never configured it.

Allowing shows nothing to anybody by itself — the viewer still has to be signed in and opted in, and the opt-in defaults off. DISallowing is absolute: it outranks an opted-in reader’s own preference, because the operator’s answer is about the install and the reader’s is about themselves.

boolean

401

Authentication required, missing, or invalid

object

error

required

Human-readable error summary

string

Example

the request could not be completed

Example

{
  "error": "authentication required: sign in and retry with a valid session or API token"
}

403

Authenticated but missing required capabilities

object

error

required

Human-readable error summary

string

Example

the request could not be completed