# Deploying the Matey demo with `sm` (mycopunk.it)

Deploys the demo behind the supramundane Caddy front
(`~/Code/darobin/caddy-front`) as three services:

| Service | Domain | What |
|---|---|---|
| `matey-auth` | `matey-auth.mycopunk.it` | the Matey broker (AT auth adapter) |
| `matey-matrix` | `matey-matrix.mycopunk.it` | Tuwunel homeserver (native next-gen auth; broker as its identity provider) |
| `matey-counter` | `matey-counter.mycopunk.it` | the counter demo app (static SPA) |

## One-time setup

1. **DNS**: point the three subdomains above at the supramundane server (the
   front's automatic ACME needs them resolving before first deploy).
2. **Secrets**: one shared secret ties Tuwunel to the broker:

   ```sh
   cd deploy/sm
   cp matey-auth/.env.example matey-auth/.env
   cp matey-matrix/tuwunel.toml.example matey-matrix/tuwunel.toml
   openssl rand -base64 32   # paste into BOTH files (client_secret / MATEY_BROKER_CLIENT_SECRET)
   ```

   Both files are git-ignored and travel to the server via `sm deploy`'s rsync.

3. **Data-dir ownership**: the broker container runs unprivileged (uid 1000)
   but `sm` creates the data dir as root, so once, after the first
   `matey-auth` deploy:

   ```sh
   ssh $SM_REMOTE_USER@$SUPRAMUNDANE 'chown 1000:1000 /srv/supramundane/data/matey-auth && docker restart matey-auth'
   ```

   (Symptom if skipped: `matey-auth` crash-loops on
   `EACCES /data/broker.keys.json` and Tuwunel reports a 502 for the broker's
   openid-configuration at login.)

## Every deploy

```sh
pnpm sm:prepare        # builds counter → matey-counter/site, broker → matey-auth/dist

cd deploy/sm/matey-auth    && sm deploy
cd ../matey-matrix         && sm deploy
cd ../matey-counter        && sm deploy
```

Order matters on first deploy only (Tuwunel validates its identity provider by
talking to the broker; the app needs both). `sm deploy` wires each service into
the front and reloads it.

Smoke checks:

```sh
curl https://matey-auth.mycopunk.it/.well-known/openid-configuration
curl https://matey-auth.mycopunk.it/atproto/client-metadata.json
curl https://matey-matrix.mycopunk.it/_matrix/client/v1/auth_metadata
curl https://matey-counter.mycopunk.it/oauth-client-metadata.json
```

Then open <https://matey-counter.mycopunk.it>, enter your handle, and walk the
flow (no mooring → "create an account on matey-matrix.mycopunk.it" → PDS
consent → provisioned account → run the linking ceremony from the banner).

## Notes

- **Federation** is delegated to `:443` via Tuwunel-served
  `/.well-known/matrix/server` (`well_known.server` in `tuwunel.toml`), since
  the front only exposes 80/443 — no `:8448` needed.
- **Server name is permanent**: `matey-matrix.mycopunk.it` is baked into the
  Tuwunel database (the sm data dir `…/data/matey-matrix`). To rename, wipe it.
- **Broker keys** persist in `…/data/matey-auth` (id_token signing + atproto
  client keys). Wiping them rotates the broker's identity; in-flight logins die,
  nothing else.
- The counter app is built with `VITE_DEFAULT_HOMESERVER=matey-matrix.mycopunk.it`
  and serves its own atproto client-metadata document (for the ceremony's
  `identity:*` session). Different hosts: override `MATEY_COUNTER_HOST` /
  `MATEY_MATRIX_HOST` when running `pnpm sm:prepare`, and edit the two
  service.json `domains` + the two secret files to match.
- The other deployment route (plain docker-compose with its own Caddy) remains
  in `deploy/` for non-supramundane hosts; known Tuwunel-topology limitations
  are listed in `deploy/README.md` and spec Appendix B.1.