How trust works here

The short version: this service handles accounts, routes, availability, hosted code, installers, and optional encrypted push delivery. A daemon grant can only be minted by that daemon's local IAM.

What this service actually does

Connect serves this discovery client and its installers, publishes daemon routes and presence, stores client-signed fleet records, and remembers which routes an account linked. A link creates no daemon principal or grant. This hosted build and its fleet WebPKI names are discovery-only and cannot open a daemon control session; use a trusted local or independently verified direct-mTLS surface for access. No signed/notarized native release exists for this alpha.

"But I sign in with a passkey…"

A fair question: doesn’t signing in give the server something it could use?

The authenticator’s passkey secret remains non-extractable: this service does not receive the private key and cannot use it at another origin. But this service controls the JavaScript running at this origin. Malicious replacement code could prompt for user verification, request a valid assertion or PRF evaluation, and then use or exfiltrate the resulting assertion, PRF output, or decrypted account state available to that page. The passkey authenticates you only for Connect account, route, and encrypted-metadata operations; none of those results authenticates to a daemon or grants daemon authority.

If this service turned malicious

It could lie in introductions.It can alter account and routing metadata, substitute the daemon key at first introduction, or deny a route. A daemon signature checked by this page proves consistency with the key Connect linked; it is not an independent key pin, because this service supplies both the first key record and the browser code doing the check. Account assertions never authenticate to a daemon, and this hosted build has an immutable role:none ceiling: it cannot open a control session even if local state is edited to grant its browser key.
It could deny service.Connect controls availability for its account, route, presence, and push services. Denial does not add daemon authority, but it can hide or delay those updates.
It could serve malicious code or installers.Hosted code can misuse Connect account state and any decrypted vault or fleet data made available after a user gesture; a replaced installer can compromise what it installs. There is no hosted or fleet-name daemon-control session in the default product. Use a trusted local or independently verified direct-mTLS root surface; self-host or verify artifacts out of band if you do not trust this deployment. The current native artifact is unsigned development-only.

The rule the protocol follows: authority records are minted and enforced only by the target daemon's local access control; the rendezvous API cannot mint one. Connect is still trusted for availability, account and route metadata, and the code and installers it serves. A malicious installer can compromise what it installs, so those are real limits rather than a claim that the service is powerless.

Notifications

Optional Web Push alerts ("your computer went offline") are composed from the polling presence this service already sees — no new knowledge — and each payload is encrypted to your browser’s subscription, so the push relays in between carry ciphertext.

Names are checkable here

Every name binding this service hands out — which daemon key Connect recorded for a linked computer, handle creations, revocation lists, verified badges — is committed to an append-only transparency log. Your browser pins the signed tree head and re-verifies on every visit that history only ever grew. This makes later rewriting detectable; it does not independently validate the first key or the browser code served by this origin. Handles can carry verified identity badges (a DNS record or GitHub gist you control); verification is decoration, never authority. Dormant handles with no computers and no sign-ins are eventually freed — squatted names don’t keep.

Organizations

Org membership is a document signed by the organization’s own key, verified by each of its computers directly. This service stores at most the org’s revocation list, also root-signed. A computer that has recorded a sequence high-water mark rejects rollback below it; a fresh computer can still be shown an older signed list. A malicious board can withhold or serve stale data, but cannot forge a newer valid list.

Verify all of this

The component is open and self-hostable: run your own rendezvous, read the full trust architecture, or audit the source.

This instance: https://intendant.dev — one deployment of an open component, not a chokepoint.