v4: an instance can be named by the address of its pages — sign-in and the trust list took only an instance's issuer, its API's origin, so where the pages live elsewhere the address people see in their browser named no instance: in development, localhost:3000 answered its /.well-known with index.html, and the sign-in failed as "doesn't answer as a gerbeur". resolveIssuer (remote/gerbeur-instance.ts) now reads the metadata at the address given and, when it names another issuer, takes it only if that issuer's own metadata names those pages back as where its /authorize is, so an impostor can't claim one; sign-in, the trust list and the check against this instance go through it. The Vite dev server passes /.well-known on to its API, as whatever serves the pages must in production (README). A handle still carries the API's host.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -152,10 +152,13 @@ home instance, and the others follow its changes.
 
 Every instance is ready for it: nothing to configure, as long as
 `GERBEUR_PUBLIC_URL` is the instance's https origin (no path) and the instances
-can reach each other. Either way can be turned off:
-`GERBEUR_FEDERATION_INCOMING=0` takes no users of other instances, and
-`GERBEUR_FEDERATION_OUTGOING=0` lets no user sign in elsewhere. An admin decides
-who comes in, on `/manage`:
+can reach each other. Users and admins may name an instance by the address of
+its API or of its pages: when the frontend runs on a host of its own
+(`GERBEUR_FRONTEND_URL`), that host must pass `/.well-known/` on to the API, as
+the Vite dev server does. A handle carries the API's host. Either way can be
+turned off: `GERBEUR_FEDERATION_INCOMING=0` takes no users of other instances,
+and `GERBEUR_FEDERATION_OUTGOING=0` lets no user sign in elsewhere. An admin
+decides who comes in, on `/manage`:
 
 - users of a **trusted** instance sign in directly, from a button on the login
   page;