operator.yaml

operator.yaml is het enige bestand dat je bewerkt. Kopieer het vanuit scripts/tc-operator/operator.yaml.example, houd het op modus 0600, en commit het nooit — het bevat je SMTP-wachtwoord, het enige geheim dat erin staat. Elk ander geheim wordt gegenereerd in /etc/trusted-codes/secrets.env.

Verplicht

home_server: node1.example.com
admin_email: ops@example.com

home_server is de identiteit van de node. Hij kan niet worden gewijzigd op een draaiende node — zie Grenzen hieronder.

E-mail

smtp:
  host: smtp.resend.com
  port: 465
  user: resend
  pass: <jouw API-sleutel>
  sender_name: Jouw Node
  sender_email: '' # standaard noreply@<home_server>

Eén provider voor alle post van de node. Houd de poort op 465. Zie Voordat je begint voor waarom, en voor de eis rond het geverifieerde domein, wat het andere is dat meestal misgaat.

Wie een account mag hebben

auth:
  registration_mode: invitation_only

Alleen invitation_only (de standaard) en closed zijn aan jou om te zetten. Je mag verstrengen, nooit versoepelen. Open, organische registratie wordt centraal geautoriseerd via de ondertekende grant van de node; open hier zetten wordt genegeerd en behandeld als invitation_only.

Twee verwante vragen worden niet in dit bestand gezet, maar in de beheerapp onder Node Settings:

1. Wat er gebeurt wanneer een van je leden iemand uitnodigt die nergens een account heeft — weigeren, of doorsturen naar Trusted Codes om zich te registreren. Kiezen voor doorsturen stuurt het e-mailadres van de uitgenodigde persoon naar Trusted Codes. Het is een dubbele poort: de centrale server moet aanbiedingen van jouw node ook accepteren, anders mislukt de uitnodiging van je lid gewoon zonder dat een reden wordt getoond.
2. Of andere servers uitnodigingen op jouw node mogen plaatsen voor je leden. Dit is jouw inkomende noodschakelaar, en kan vanuit elke staat op weigeren worden gezet.

Ze staan met opzet buiten dit bestand, omdat elke reload de federatievlaggen onvoorwaardelijk herschrijft — een waarde die hier is gezet zou een beslissing die je later nam stilzwijgend terugdraaien.

Federatievlaggen

federation: true

federation: true zet de hele deelnemende set aan — code_lookup, open_link_claim, invitations, groups en multi_account. Elke individuele vlag overschrijft de afkorting.

Twee dingen om te weten:

• Een e-mailtransport is een harde vereiste. Zonder smtp.host zet de installer de hele set gedwongen uit en vertelt je dat.
• Het voorbeeldbestand zet elke vlag expliciet op false. Kopieer je het onbewerkt, dan krijg je een node met federatie uit, ook al staat een node met geconfigureerde SMTP verder standaard aan. Zet ze bewust.

Wat elk oppervlak blootlegt, en waarom twee ervan beveiligingsbevindingen waren, staat in de sectie Gefedereerde server. Lees dat voordat je ze aanzet.

WebFinger-ontdekking staat altijd aan. Een node moet vindbaar zijn om te federeren.

Oppervlakken

Welke weboppervlakken deze node aanbiedt onder jouw domein. Gebruik de blokvorm; de inline vorm my: { enabled: true } wordt niet geparst.

surfaces:
  admin:
    enabled: true
  my:
    enabled: false
  verify:
    enabled: false
  provider:
    enabled: false
  status:
    enabled: false
  business:
    enabled: false
    # host: verify.example.com   # domeinoverschrijving per oppervlak

admin staat standaard aan en kan nooit worden gestopt — het is het herstelvlak. Elk aangezet oppervlak wordt op de doos gebouwd en heeft zijn eigen DNS A-record nodig.

Branding

branding:
  product_name: Trusted Codes
  primary_color: '#1a3a5c'
  # logo_url: https://node1.example.com/logo.svg

De naam, kleur en het logo worden gepubliceerd in de ondertekende node-informatie en toegepast op de eigen inhoud van de node — e-mails, hulp, onboarding.

Optionele integraties

Alles hier is optioneel. Laat een sleutel leeg en die functie staat gewoon uit: de node blijft draaien, en zowel de installatiesamenvatting als tc-operator status tonen welke integraties aan en welke uit staan. Niets faalt stilzwijgend. Je haalt deze sleutels zelf op, voor je eigen inzet; Trusted Codes ziet ze nooit.

Integratie	Sleutels	Leeg betekent
MaxMind — geografie en fraudescore bij aanmelden en opzoeken	integrations.maxmind.account_id, license_key	aanmeldingen gaan door ongescoord, fail-open
AI-chat	integrations.ai.mistral_api_key of gemini_api_key	de assistent staat uit
Metabase — ingesloten dashboards in de beheerapp	integrations.metabase.site_url, embedding_secret	dashboards niet beschikbaar

De standaard van MaxMind is een tweede blik waard. Voor een node die aanmeldingen zou moeten blokkeren wanneer scoring niet beschikbaar is in plaats van ze door te laten, is er een aparte parameter om te zetten.

Facturatie en mobiele push zijn alleen centraal en hebben hier geen instelling.

Push-relay

push_relay_server: app.trusted.codes

Een federatieserver-naam, geen URL. Jouw node bezit de pushtokens van zijn gebruikers, maar de pushinloggegevens van de gedeelde mobiele app zijn van Trusted Codes, dus kan jouw node niet rechtstreeks met de pushdiensten van de app stores praten. Met dit ingesteld reizen pushberichten als ondertekende federatie-envelopes via de relay.

De relay ziet een token, een tijdstip en de naam van jouw server. Nooit inhoud. In deze versie reizen alleen stille “word wakker en synchroniseer”- prikkels. Het apparaat haalt daarna de echte data op van jouw node en toont die. Het gevolg is echt: je gebruikers krijgen achtergrondsynchronisaties, geen door de server verstuurde meldingstekst. Zichtbare meldingen verschijnen wanneer de app op de voorgrond komt en synchroniseert.

Niet instellen houdt directe verzending aan, wat werkt totdat pushbeveiliging platformbreed wordt ingeschakeld. Als push helemaal uitvalt, breekt er niets — clients vallen terug op voorgrondsynchronisaties. Push is in dit product nooit kritiek.

Een wijziging toepassen op een draaiende node

sudo scripts/tc-operator/tc-operator reload --config operator.yaml

Beschouw het als de hele node bijwerken naar wat het bestand nu zegt. Het verifieert SMTP opnieuw tegen de live provider voordat er iets wordt toegepast, hertekent secrets.env vanuit het bestand, laat Docker precies de containers herscheppen waarvan de instellingen zijn gewijzigd, past de instellingen aan de databasekant opnieuw toe (federatievlaggen, oppervlakteschakelaars, branding, portaal-URL’s), ondertekent de gepubliceerde informatie van de node opnieuw, herlaadt de proxy en test zichzelf.

Gegenereerde geheimen — de JWT-sleutels, de versleutelingssleutels, de federatie-identiteit — worden nooit geroteerd door een reload. Een ongewijzigde configuratie is een no-op, dus is het veilig om op elk moment te draaien.

Gedekt: smtp, auth, integrations, branding, surfaces, de federatievlaggen, push_relay_server, en de overschrijvingen van registry en grant.

Wat reload niet doet

• home_server kan niet worden herladen. Hem wijzigen is een verandering van identiteit — DNS, TLS, toelating tot het register. Reload weigert en verwijst je naar install.
• admin_email wordt maar gedeeltelijk toegepast. Reload werkt het contactadres van het certificaat bij. Een nieuw beheeraccount vraagt om tc-operator add-admin --email <adres>.
• Een nieuw aangezet oppervlak wordt niet gebouwd. Reload waarschuwt en verwijst je naar tc-operator service start <oppervlak>, dat het bouwt en aanbiedt.
• Reload is leidend voor oppervlakken. Elke ad-hoc schakelaar die sinds de laatste reconciliatie in de beheerapp is gezet, wordt teruggezet naar wat het bestand opgeeft. Install gedraagt zich hetzelfde.
• Nieuwe code en nieuwe migraties reizen nooit via reload. Dat is bijwerken.