jlxq0/matrix-botfather

Fork 0

Possible: mint a per-bot credential for cross-signing, if matrix-mcp#139 finds UIA needs a password #5

New issue

Open

opened 2026-08-28 01:28:56 +00:00 by jlxq0 · 2 comments

jlxq0 commented

2026-08-28 01:28:56 +00:00

Owner

Filed so this outlives the session that holds it. Nothing to do yet, and the condition that starts it is measured elsewhere.

The state

Four fleet bots have unsigned devices or no cross-signing keys at all (@alan_ai_bot, @clark_ai_bot, @mantis_ai_bot unsigned; @lucybot and seven others with no keys). Fixing that needs each bot to sign its own device, because /keys/device_signing/upload is per-user behind UIA and bootstrap_cross_signing targets the authenticated account. A Synapse admin cannot sign another user's device. That is a property of Matrix, not of our deployment.

Each director's channel mount is already authenticated as its own bot, so the credential is in the right place and only the tool was missing. matrix-mcp#139 adds bootstrap_cross_signing to CHANNEL_TOOLS, turning it into self-service calls with no token moving.

What would make this botfather's job

#139 is measuring whether UIA can be completed with an access token alone. If it cannot and a password is required, a bot holding only a long-lived token cannot bootstrap itself, and the answer becomes a botfather-managed credential per bot. That is the minting half and it is ours.

So: do nothing until matrix-mcp#139 reports the UIA result. If it says access-token-only works, close this. If it says a password is needed, the work is a credential per bot, and Alan is to supply which bots are botfather-managed rather than us guessing.

Constraint that does not move

Token delivery is 1:1 to Julian by design (dc58ea3). Any design here delivers through that path or changes it deliberately in its own issue. Reading his DMs to harvest a token is not an implementation detail to be worked around — it is the property the hardening exists to hold.

Incidental

The matrix-mcp device MATRIXMCP-DLX8SKHK (@julian) is also cross_signed=false against an existing master key. It is why this session cannot read botfather's DM replies, so a botfather change verified through Matrix needs someone whose device is signed, or the health endpoint and pod logs instead. Verified that way for v0.1.3 (see #3).

Filed so this outlives the session that holds it. Nothing to do yet, and the condition that starts it is measured elsewhere. ## The state Four fleet bots have unsigned devices or no cross-signing keys at all (`@alan_ai_bot`, `@clark_ai_bot`, `@mantis_ai_bot` unsigned; `@lucybot` and seven others with no keys). Fixing that needs each bot to sign its own device, because `/keys/device_signing/upload` is per-user behind UIA and `bootstrap_cross_signing` targets the authenticated account. **A Synapse admin cannot sign another user's device.** That is a property of Matrix, not of our deployment. Each director's `channel` mount is already authenticated as its own bot, so the credential is in the right place and only the tool was missing. `matrix-mcp#139` adds `bootstrap_cross_signing` to `CHANNEL_TOOLS`, turning it into self-service calls with no token moving. ## What would make this botfather's job `#139` is measuring **whether UIA can be completed with an access token alone**. If it cannot and a password is required, a bot holding only a long-lived token cannot bootstrap itself, and the answer becomes a botfather-managed credential per bot. That is the minting half and it is ours. So: **do nothing until `matrix-mcp#139` reports the UIA result.** If it says access-token-only works, close this. If it says a password is needed, the work is a credential per bot, and Alan is to supply which bots are botfather-managed rather than us guessing. ## Constraint that does not move Token delivery is 1:1 to Julian by design (`dc58ea3`). Any design here delivers through that path or changes it deliberately in its own issue. **Reading his DMs to harvest a token is not an implementation detail to be worked around** — it is the property the hardening exists to hold. ## Incidental The matrix-mcp device `MATRIXMCP-DLX8SKHK` (`@julian`) is also `cross_signed=false` against an existing master key. It is why this session cannot read botfather's DM replies, so a botfather change verified through Matrix needs someone whose device is signed, or the health endpoint and pod logs instead. Verified that way for v0.1.3 (see #3).

jlxq0 commented

2026-08-28 01:35:10 +00:00

Author

Owner

Two corrections to the body above, and the condition narrows.

The MATRIXMCP-DLX8SKHK paragraph was wrong and is withdrawn. I described it as a fifth unsigned device alongside four bots. It is @julian's own device, so it is a human's device rather than a bot's and does not belong in a bot count. What is true and unchanged: whoami from this mount returns exactly that device id, so verify_status was reporting on this session's own device, and this mount is @julian.

The decryption claim was also wrong. Botfather's replies read unable_to_decrypt at 03:36 and the same events read decrypted on a later fetch. The keys arrived; the failure was transient rather than a property of an unsigned device. So an unsigned device is not established as the cause of anything here, and any design that assumed it should be rechecked.

The condition narrows to one account. Of the accounts in scope, only one lacks a cross-signing identity outright; the rest hold complete identities whose device signature did not attach, and bootstrap_cross_signing correctly refuses to replace an existing identity. So the UIA question gets measured on a single account rather than four, and this issue's trigger is that single measurement.

What is newly known and is ours: the accounts in question are botfather-managed, and botfather already exposes per-bot token and revoke. So if the UIA answer is that an access token alone cannot complete the flow, the rotation mechanism exists and does not need building — the work is the delivery design, not the minting.

Roster and account identifiers deliberately omitted: this repository is public.

Two corrections to the body above, and the condition narrows. **The `MATRIXMCP-DLX8SKHK` paragraph was wrong and is withdrawn.** I described it as a fifth unsigned device alongside four bots. It is `@julian`'s own device, so it is a human's device rather than a bot's and does not belong in a bot count. What is true and unchanged: `whoami` from this mount returns exactly that device id, so `verify_status` was reporting on this session's own device, and this mount is `@julian`. **The decryption claim was also wrong.** Botfather's replies read `unable_to_decrypt` at 03:36 and the same events read `decrypted` on a later fetch. The keys arrived; the failure was transient rather than a property of an unsigned device. So an unsigned device is not established as the cause of anything here, and any design that assumed it should be rechecked. **The condition narrows to one account.** Of the accounts in scope, only one lacks a cross-signing identity outright; the rest hold complete identities whose device signature did not attach, and `bootstrap_cross_signing` correctly refuses to replace an existing identity. So the UIA question gets measured on a single account rather than four, and this issue's trigger is that single measurement. **What is newly known and is ours:** the accounts in question are botfather-managed, and botfather already exposes per-bot `token` and `revoke`. So if the UIA answer is that an access token alone cannot complete the flow, the rotation mechanism exists and does not need building — the work is the delivery design, not the minting. Roster and account identifiers deliberately omitted: this repository is public.

jlxq0 added the

waiting-on-julian

label

2026-08-28 01:48:41 +00:00

jlxq0 commented

2026-08-29 12:24:43 +00:00

Author

Owner

Off his list: this issue's own first line says it is not waiting on anybody

Filed so this outlives the session that holds it. Nothing to do yet, and the condition that starts it is measured elsewhere.

A conditional that has not fired is not an ask. It became a row on bin/fleet-ledger.sh waiting that Julian could not act on, next to rows he could, which is the cost. matrix-mcp#139 fires it or it never fires.

One connection worth recording before this goes quiet, because it was found today from the other end. @julian's own matrix-mcp device MATRIXMCP-DLX8SKHK will not cross-sign: he completed /setup/recover successfully at 12:18 UTC, the page reported the private keys imported and a self-sign within 30 seconds, and verify_status still answers cross_signed: false ten minutes later.

That is the same signature this issue records for @lucybot and seven others — a device with no keys of its own. A master key cannot sign a device key that was never uploaded, and no amount of correct recovery material changes it.

It is not the same account and not necessarily the same cause, and saying so is the point: this is a lead to check, not a conclusion. If matrix-mcp never calls /keys/upload for its own device, then the bots and the principal are one bug rather than two, and the per-bot credential this issue is about would not fix either of them.

## Off his list: this issue's own first line says it is not waiting on anybody > Filed so this outlives the session that holds it. **Nothing to do yet, and the condition that starts it is measured elsewhere.** **A conditional that has not fired is not an ask.** It became a row on `bin/fleet-ledger.sh waiting` that Julian could not act on, next to rows he could, which is the cost. `matrix-mcp#139` fires it or it never fires. **One connection worth recording before this goes quiet**, because it was found today from the other end. `@julian`'s own matrix-mcp device `MATRIXMCP-DLX8SKHK` will not cross-sign: he completed `/setup/recover` successfully at 12:18 UTC, the page reported the private keys imported and a self-sign within 30 seconds, and `verify_status` still answers `cross_signed: false` ten minutes later. **That is the same signature this issue records for `@lucybot` and seven others — a device with no keys of its own.** A master key cannot sign a device key that was never uploaded, and no amount of correct recovery material changes it. **It is not the same account and not necessarily the same cause**, and saying so is the point: this is a lead to check, not a conclusion. If matrix-mcp never calls `/keys/upload` for its own device, then the bots and the principal are one bug rather than two, and **the per-bot credential this issue is about would not fix either of them.**

jlxq0 removed the

waiting-on-julian

label

2026-08-29 12:24:44 +00:00

No labels

waiting-on-julian

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jlxq0/matrix-botfather#5

No description provided.

Rows
Columns