This Server

This Server is the last group in the sidebar, and it only exists on a node. It holds three screens: Surfaces, Node Settings and Connection Activity.

Surfaces

A read-only status view of the portal surfaces this server runs: Admin, Personal portal, Business portal, Verification page, Provider portal and Status page. Each row shows its host and a state — Serving, Enabled · not served, or Off. The page re-reads itself every half minute.

It shows status only. The console never starts or stops a service, deliberately: host control must not live in the web tier. When a surface is enabled but not being served, the row prints the exact command to run on the box, with a Copy button:

tc-operator service start <surface>

That command is the only control plane for surface serving. Admin is always on.

Node Settings

Two things live here: the addresses this node uses, and the policy for who may connect to it.

Portal URLs

Four fields — Personal portal URL, Admin portal URL, Business portal URL and Provider portal URL. These are the addresses that platform invitation links and portal references resolve to at runtime.

They are derived from your home server at install, so a node on police.org starts with https://my.police.org and its siblings. Change any of them to any http or https address and press Save changes; the count of pending changes is shown beside the button, and an invalid address is marked before you can save. The change takes effect immediately.

Re-running tc-operator install never overwrites a URL you have customised.

Who Can Connect Here

The card below the URLs. A member is somebody with an account on this server; an external user has an account on another Trusted Codes server.

The first row is status, not a control: New accounts on this server tells you whether anybody may register, whether it is invitation only, or whether the server is closed. That is set in operator.yaml under auth.registration_mode, applied with tc-operator reload. Open registration has to be authorised by Trusted Codes, and the row tells you the state of that authorisation.

Two questions on this card are yours to answer, and they are separate on purpose. They were one switch until they were split, which meant you could not stop other servers placing records here without also stopping your own members from inviting anybody outward.

The first is what happens when one of your members invites somebody who has no account anywhere: refuse the invitation, or send that person to the central server to register. Sending them there means sending their address there. Routing outward is only offered where an offer could actually succeed.

The second is whether other servers may place invitations on your node for your members. This is your inbound kill switch and it can be set to deny from any state.

Address reveal is the third control, and it needs the can_reveal permission. With it off, invited addresses are stored masked and cannot be recovered by anybody, you included. Switching it on makes this server keep a recoverable copy of every address your members invite — including people who never sign up — for 90 days. After 90 days the address is gone, but the record that somebody looked at it is kept.

Under the controls is a canned preview, What happens, with these settings. It walks ten situations and says what your node would do in each, with the blocked ones marked, and quotes word for word what a member would read when an invitation is refused. It is worked examples only. Nothing on it contacts another server.

Connection Activity

What actually happened, and with whom. Addresses are masked throughout.

The invitation log covers both directions and includes refused incoming attempts — without those, a working deny switch looks exactly like nobody offering. Filter by All, Sent from here or Offered to us. Each row gives the time, the direction, the masked address, the other server, what the lookup found, which rule decided it and what that rule held at the time, and the result. Rows that arrived since you last looked are marked new.

Export as CSV (masked) downloads the log. It carries masked values only, so it needs no extra permission.

The log is kept 90 days. The settings history, and the record of who looked at an address, are kept permanently.

Where you hold can_reveal, a show button sits beside a masked address. It asks why you need it, and will not proceed on a short answer. Your name, the time and your reason are recorded permanently.

External servers lists every server this one has dealt with, with counts of what was accepted from them, refused from them and sent to them, and when they were last active. This list exists because you cannot choose your peers in advance — incoming invitations are accepted from every server the registry lists as active. Reviewing this list afterwards is the compensating control.

External users here counts the people connected here who hold their account on another server, grouped by that server.

Settings history records who changed what, when, and from what to what.

Cutting a Server Off

The Cut off button on a server row needs can_revoke. Without it the cell reads needs permission.

It is a real consequence, so the confirmation says what it costs before you press it: how many people are connected from that server now, and how many of their invitations are waiting here. New invitations and lookups stop at once in both directions. Nothing is deleted, and existing connections stay, but they stop syncing with that server. The waiting invitations are rejected, because that server can no longer withdraw them. The other server is not told.

You are asked to type a reason, which goes into the settings history. The row then shows when it was cut off, by whom, and why, and the button becomes Let back in. It is reversible at any time.