swarm-matrix-ctl: mint the swarm's own appservice registration

The swarm gets an appservice identity of its own, separate from each hive's
`hyperhive` registration. `swarm-matrix-ctl appservice render` mints its
tokens inside the matrix container when they are absent and renders the
registration tuwunel loads; `appservice publish` writes its as_token to
`swarm/controller/swarm-controller/matrix/appservice-token`, the one kind no
hive's policy grants.

The homeserver calls move out of swarm-matrix-ctl into swarm-matrix-client,
with a `whoami`, so swarm-controller can mint agents' accounts through the
same pinned device id instead of a copy of them.
This commit is contained in:
atlas 2026-09-24 23:42:36 +02:00 • committed by mara
commit 89aff8d613
10 changed files with 523 additions and 23 deletions

View file

@ -0,0 +1,17 @@
# swarm-matrix-client
The appservice calls against the swarm's homeserver, shared by the two binaries
that make them: `swarm-matrix-ctl` (inside the matrix container, for a hive's
sender account) and `swarm-controller` (for each agent's account, with the
swarm's own appservice token).
Three calls, all client-server API: register an account as the appservice, log
in to an existing one as the appservice, and ask a token who it is. Both mints
pin the device id `hyperhive-<localpart>`, so a second login **replaces** that
device's token instead of adding a device.
## 🩸 A secret is a path, never a value
Every error here is built from the response's status and its `errcode`, never
its body: a successful `/register` or `/login` body is an access token, and an
error body is one malformed response away from being the same bytes.