Bendik LynghaugandClaude Opus 5
44c7ee6870
iOS is the one client none of the mail autoconfiguration reaches: Apple Mail reads neither Mozilla autoconfig nor Autodiscover for IMAP, so adding an account means the device probing for ports - and a probe that meets a filtered port waits out a TCP timeout and reports the account as unverifiable, which the person reads as a wrong password. A profile states the hosts and the ports instead, and carries mail, calendars and contacts in one install. It invents none of them: site.yaml names a PACC document - the standard defined to be fetched from the mail domain itself - and every host, port and collection path comes from there, so the server is described in one place and the profile follows it. The document holds no address, username or password. iOS asks for those at install, which means one profile serves everyone with an account and it can be fetched by anyone: it says no more than PACC already says in public. Identifiers are derived from the site and the payload rather than drawn at random, because iOS replaces a profile whose ids it knows and stacks a duplicate when they differ. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
portal documentation
Portal turns a Git repo of YAML into a running site. Almost everything here is about that YAML: what a content repo may say, and what the engine does with it.
| Getting started | Bringing your people in: from an empty Kanidm to everyone at their own desk, from what the content says. |
| Architecture | What the engine is made of and where each piece lives in the source. |
| Content reference | Every key a content repo may write, and what it does. |
| State machines | aggregates.yaml: stages, who moves a case, mail, deadlines, memberships. |
| Access | How the Cedar policy is compiled from content, and who may ask it what. |
| Storylines | The same site told several ways: lists of texts, one storyline per visitor, counted per storyline. |
| Memberships | Groups kept by portal itself: a membership as a case, a person as a phone number first, and the provider only saying who. |
| Operations | Releasing, deploying, adding a site, environment variables. |
| Training a site | portal plan and portal build: a business in plain words becomes a content repo, held to the lint. |
| The lint | portal lint: what a content repo's CI runs before anything reaches a site. |
| Filesystem routes | Why the questions/ tree is the router. |
One repo in the same family carries its own docs:
- uhhm/gdo — the mailer. Delivers what content asked to be sent, and carries replies back.
The lint (once uhhm/iris) and the trainer (once uhhm/portal-trainer)
are commands of the portal binary since 0.6; their chapters are
above, and the trainer's runs stay in the old repo.