hobbs-iac/docs/superpowers/plans/mas-auth-inventory.md

Matrix Auth Inventory — baseline before MAS migration

Captured 2026-08-20 from /var/lib/synapse/homeserver.db (SQLite, pre-migration).

Totals: 20 users (7 deactivated), 65 devices, 54 access tokens, 9 e2e device key entries.

Per-account baseline

Account	Devices	Tokens	Password hash	Credential location	Auth style
@jeremy	12 (incl. cross-signing keys)	3	yes	user-typed (bigdog01)	password + Element sessions
@clippyauto	17	17	yes	n8n credential store (encrypted, /home/node/.n8n/database.sqlite on .100)	repeated password login — new device per login
@pluto	15	15	yes	unknown (OpenClaw Gateway devices)	repeated password login
@julie	5	2	yes	Element X Android	password
@spirit	2	3	yes	/mnt/infrastructure/spirit/openclaw.json → key accessToken only	access token
@margaret	2	2	yes	/mnt/infrastructure/margaret/openclaw.json → keys accessToken and password	token + password
@frigate	2	2	yes	compose/hf-pdocker-01/frigate-notify/.env → MATRIX_ACCESS_TOKEN=syt_ZnJpZ2F0…	access token
@alertbot	2	2	yes	/mnt/docker-data/configs/alertmanager/matrix-receiver-config.yml → token: "syt_YWxlcnRib3Q…"	access token
@hermes	2	2	yes	unknown	unknown
@fry	1	1	yes	unknown	unknown
@testbot	1	1	yes	TESTBOT_CI device	unknown
@admin1, @adminuser	2 each	2 each	yes	unknown	admin accounts
@aaron, @bob, @clippy, @travis, @tempadmin, @resetadmin, @resetadmin2	0	0	none	—	deactivated

Risk read

• Access-token accounts (spirit, frigate, alertbot) are the safest: syn2mas imports access tokens, so they should continue uninterrupted.
• @clippyauto and @pluto are the canaries. The 1:1 device-to-token ratio and high counts mean they authenticate with a password on each connect, creating a fresh device every time. Post-migration they exercise the MAS compatibility layer (/_matrix/client/*/login proxied to MAS). If the bcrypt unicode_normalization: true scheme is misconfigured, these break first and loudest — @clippyauto polls every ~2s, so failure is visible within seconds.
• @jeremy's 12 devices include cross-signing keys (master/self_signing/user_signing), not just sessions. Cross-signing state must survive or Element will prompt to re-verify.

Post-migration verification command

ssh glyptic@192.168.86.192 'docker exec synapse-db psql -U synapse -d synapse -tc "
 select u.name,
        (select count(*) from devices d where d.user_id=u.name) dev,
        (select count(*) from access_tokens a where a.user_id=u.name) tok
 from users u where u.deactivated=0 order by u.name;"'

Compare against the table above. Device counts may grow (new logins) but must not shrink for token-based accounts.

---

syn2mas dry-run results (2026-08-20 20:07Z)

syn2mas check: "Check completed successfully with no errors or warnings."

Dry-run migration summary (rolled back automatically):

20 users migrated (0 skipped)
 0 third-party IDs migrated (0 skipped)
 0 upstream links (external IDs) migrated (0 skipped)
53 non-refreshable access tokens migrated (0 skipped)
 0 refreshable token pairs migrated (0 skipped)
53 devices migrated (0 skipped)

Reconciliation against the pre-migration baseline

Metric	Synapse	syn2mas	Explanation
Users	20	20	exact match
Devices	65	53	12 of the 65 are cross-signing key pseudo-devices (display_name like '%signing key%'), not login sessions. Real login devices = 53. Verified by query. Cross-signing keys stay in Synapse's own e2e tables.
Access tokens	54	53	The one token not migrated is device-less, and MAS compat sessions are device-scoped. Identified as syt_Ym9i_… — Ym9i is base64 for "bob", a leftover token from the decommissioned @bob agent, attached to @spirit. Last validated months ago.

Spirit is safe: its configured accessToken (syt_c3Bpcml0…, base64 c3Bpcml0 = "spirit") maps to device CEBHTAXUAY, which migrates. Verified by joining the config token against access_tokens.

Conclusion: go. No account loses a credential it actually uses.