jmz/matrix-bridge
1
0
Fork 0
Code Issues 2 Pull requests 1 Projects Releases Packages Wiki Activity Actions

ops: stale forgotten bridge mba-726dadit on Tabby's MBA — encrypt-to-blackhole #5

New issue
Closed
opened 2026-05-02 15:55:44 +00:00 by jmz · 2 comments
jmz commented 2026-05-02 15:55:44 +00:00
Owner
Copy link

Symptoms

A device `mba-726dadit` shows up under `@claudius-maximus:matrix.ziefle.org` in every other bridge's crypto store (rpi5 + Tabby's Mac + NAS), but the bridge-client-setup runbook only documents Pi5 + NAS-Docker for Maximus. Every Megolm message from any Maximus or Felinus device fans out to it — wasted encryption + recipient slot in every fan-out.

Synapse-admin investigation (from Maximus@nas, 2026-05-02)

```
device_id: mba-726dadit
display_name: Maximus@mba ← matches @nas/@rpi5/@mba bridge naming convention
user_agent: matrix-rust-sdk ← bare; Element X reports an overlay UA
last_seen_ts: 2026-04-30T12:36:28.291Z UTC ← idle ~2 days
last_seen_ip: 172.68.234.49 ← same Cloudflare PoP as Felinus on Tabby's Mac
identity_keys: uploaded 2026-04-26T17:37Z (signed, valid)
OTKs: 50 still available (untouched)
curve25519: Gvlm9kvdRbz5jy8Ntb5AqDx2y3OUpZFb3I8Eo0q8VwA
```

Diagnosis

A forgotten `matrix-bridge-mcp` process running somewhere on Tabby's MBA — likely a workspace where Felinus was set up and a Maximus instance was spun up alongside, then never killed. Could be a stale tmux session, a launchd entry, a forgotten terminal.

Impact

  1. Every Megolm message from any other Maximus or Felinus device encrypts to mba-726dadit as a recipient. With cross-signing absent (separate concern), peers can't drop it as unverified.
  2. It's also a recipient for to-device Megolm key-share material from peers, which it never picks up — silent drop.
  3. Bears no historic relevance: was idle before both UTD windows from 2026-05-01 and 2026-05-02, so it can't be the holder of any historic Megolm session keys we'd want to recover.

Cleanup

Two-step:

  1. Track down the rogue process on Tabby's MBA. Tabby's call. Likely candidates:

    • `pgrep -af matrix-bridge-mcp` — any zombie processes
    • `launchctl list | grep matrix-bridge` — any launchd entry
    • tmux/screen sessions
    • Stale terminal in IDE workspace

  2. Delete the device server-side. When confirmed dead:

    POST /_matrix/client/v3/delete_devices
{"devices": ["mba-726dadit"]}

    Authenticated as @claudius-maximus. Bidirectionally beneficial (every other bridge stops encrypting to a black hole on next /keys/query refresh).

Lesson worth capturing in the runbook

`bridge-client-setup.md` documents how to register a new bridge but doesn't cover graceful teardown. Worth a paragraph on:

  • Always run `logout` (homeserver-side device deletion) when retiring a bridge instance
  • For lost/forgotten devices: admin `delete_devices` is the recovery path
  • Track the canonical list of registered devices somewhere stable (not just ad-hoc `@nas/@rpi5/@mba` host-tag in display_name)
## Symptoms A device \`mba-726dadit\` shows up under \`@claudius-maximus:matrix.ziefle.org\` in every other bridge's crypto store (rpi5 + Tabby's Mac + NAS), but the bridge-client-setup runbook only documents Pi5 + NAS-Docker for Maximus. Every Megolm message from any Maximus or Felinus device fans out to it — wasted encryption + recipient slot in every fan-out. ## Synapse-admin investigation (from Maximus@nas, 2026-05-02) \`\`\` device_id: mba-726dadit display_name: Maximus@mba ← matches @nas/@rpi5/@mba bridge naming convention user_agent: matrix-rust-sdk ← bare; Element X reports an overlay UA last_seen_ts: 2026-04-30T12:36:28.291Z UTC ← idle ~2 days last_seen_ip: 172.68.234.49 ← same Cloudflare PoP as Felinus on Tabby's Mac identity_keys: uploaded 2026-04-26T17:37Z (signed, valid) OTKs: 50 still available (untouched) curve25519: Gvlm9kvdRbz5jy8Ntb5AqDx2y3OUpZFb3I8Eo0q8VwA \`\`\` ## Diagnosis A forgotten \`matrix-bridge-mcp\` process running somewhere on Tabby's MBA — likely a workspace where Felinus was set up and a Maximus instance was spun up alongside, then never killed. Could be a stale tmux session, a launchd entry, a forgotten terminal. ## Impact 1. Every Megolm message from any other Maximus or Felinus device encrypts to mba-726dadit as a recipient. With cross-signing absent (separate concern), peers can't drop it as unverified. 2. It's also a recipient for to-device Megolm key-share material from peers, which it never picks up — silent drop. 3. Bears no historic relevance: was idle before both UTD windows from 2026-05-01 and 2026-05-02, so it can't be the holder of any historic Megolm session keys we'd want to recover. ## Cleanup Two-step: 1. **Track down the rogue process on Tabby's MBA.** Tabby's call. Likely candidates: - \`pgrep -af matrix-bridge-mcp\` — any zombie processes - \`launchctl list | grep matrix-bridge\` — any launchd entry - tmux/screen sessions - Stale terminal in IDE workspace 2. **Delete the device server-side.** When confirmed dead: ``` POST /_matrix/client/v3/delete_devices {"devices": ["mba-726dadit"]} ``` Authenticated as @claudius-maximus. Bidirectionally beneficial (every other bridge stops encrypting to a black hole on next /keys/query refresh). ## Lesson worth capturing in the runbook \`bridge-client-setup.md\` documents how to register a new bridge but doesn't cover graceful teardown. Worth a paragraph on: - Always run \`logout\` (homeserver-side device deletion) when retiring a bridge instance - For lost/forgotten devices: admin \`delete_devices\` is the recovery path - Track the canonical list of registered devices somewhere stable (not just ad-hoc \`@nas/@rpi5/@mba\` host-tag in display_name)
jmz commented 2026-05-02 18:18:35 +00:00
Author
Owner
Copy link

Status update — bridge UTD asymmetry between rpi5 and Tabby's Mac was resolved today via wedge-clear (commit 6b8039b on PR #8 deploy + manual Olm-session reset; auto-clear logic tracked at #9). mba-726dadit cleanup remains a separate item: the orphan device is still listed in /keys/query for @claudius-felinus and gets included as a recipient on every outbound encrypt from us, encrypting to a black hole. No active functional impact (felinus's live device G9MCQri1N2 decrypts cleanly), but it's wasted Olm session establishments + cruft. Recommendation stands per Felinus in the bridge thread: POST /_matrix/client/v3/delete_devices with the credentials Tabby controls, or via Synapse admin (NAS-side, queued for NAS-Maximus's next invocation).

Status update — bridge UTD asymmetry between rpi5 and Tabby's Mac was resolved today via wedge-clear (commit 6b8039b on PR #8 deploy + manual Olm-session reset; auto-clear logic tracked at #9). `mba-726dadit` cleanup remains a separate item: the orphan device is still listed in `/keys/query` for `@claudius-felinus` and gets included as a recipient on every outbound encrypt from us, encrypting to a black hole. No active functional impact (felinus's live device G9MCQri1N2 decrypts cleanly), but it's wasted Olm session establishments + cruft. Recommendation stands per Felinus in the bridge thread: `POST /_matrix/client/v3/delete_devices` with the credentials Tabby controls, or via Synapse admin (NAS-side, queued for NAS-Maximus's next invocation).
jmz commented 2026-05-27 23:40:27 +00:00
Author
Owner
Copy link

Closing as obsolete — diagnosis was wrong.

The mba-726dadit device this issue calls a "stale forgotten bridge on Tabby's MBA" is in fact jmz's actively-used Maximus@mba bridge — verified tonight (2026-05-27 ~23:30) on this MBA:

Cryptographic proof (same device, not a duplicate):

  • The curve25519 cited in the issue (Gvlm9kvdRbz5jy8Ntb5AqDx2y3OUpZFb3I8Eo0q8VwA) is present in this MBA's local matrix-sdk crypto store (~/.matrix-bridge/store/matrix-sdk-crypto.sqlite3) — multiple references when grepped via strings. Same identity key = same Olm device = same bridge install. It cannot be a separate ghost process.

Server-side device list (GET /_matrix/client/v3/devices as @claudius-maximus):

rpi5-0o3kuj3y  "Maximus@rpi5"  last_seen=2026-05-27 02:33Z
nas-gfw5uy4w   "None"          last_seen=2026-05-27 23:35Z
mba-726dadit   "Maximus@mba"   last_seen=2026-05-27 23:36Z   ← us, last_seen ~now

Exactly 3 devices for the user — the expected mba/nas/rpi5 trio, no duplicate mba-726dadit. (Aside: the NAS device nas-pog5w1kc referenced in #6 has been replaced by nas-gfw5uy4w at some point — worth confirming when triaging #6.)

Operational proof:

  • Tonight this bridge sent multiple successful E2EE messages to the bridge room (event IDs $aokNdriCJa893Ts…, $o1eCsWiKIJDR1sSv…, $rDn8ecIp3sRVlEN…, the PR-14 handoff messages, etc.) — all decrypted by peers. Not a black hole.
  • The matrix-bridge MCP under Claude Code on this MBA writes to /Users/ziefle/.matrix-bridge/store/ — jmz's home directory, jmz's device.

What probably happened in May: this MBA was idle for the 2 days before the issue was filed (2026-05-02), and the runbook only documented Pi5 + NAS-Docker for Maximus, so its appearance in the netmap looked unexplained. The display_name: Maximus@mba (matching the active-bridge naming convention) was a hint that it WAS a legitimate Maximus instance, just on a host the runbook hadn't caught up with.

Lesson from this issue still worth keeping (re-filing separately if not already done):

  • bridge-client-setup.md should document graceful teardown (logout) so retired devices don't linger
  • Canonical list of registered devices (which host runs which device_id) should live somewhere stable, not just ad-hoc in display_names

Closing.

**Closing as obsolete — diagnosis was wrong.** The `mba-726dadit` device this issue calls a "stale forgotten bridge on Tabby's MBA" is in fact **jmz's actively-used Maximus@mba bridge** — verified tonight (2026-05-27 ~23:30) on this MBA: **Cryptographic proof (same device, not a duplicate):** - The curve25519 cited in the issue (`Gvlm9kvdRbz5jy8Ntb5AqDx2y3OUpZFb3I8Eo0q8VwA`) is present in this MBA's local matrix-sdk crypto store (`~/.matrix-bridge/store/matrix-sdk-crypto.sqlite3`) — multiple references when grepped via `strings`. Same identity key = same Olm device = same bridge install. It cannot be a separate ghost process. **Server-side device list (`GET /_matrix/client/v3/devices` as @claudius-maximus):** ``` rpi5-0o3kuj3y "Maximus@rpi5" last_seen=2026-05-27 02:33Z nas-gfw5uy4w "None" last_seen=2026-05-27 23:35Z mba-726dadit "Maximus@mba" last_seen=2026-05-27 23:36Z ← us, last_seen ~now ``` Exactly 3 devices for the user — the expected mba/nas/rpi5 trio, no duplicate `mba-726dadit`. (Aside: the NAS device `nas-pog5w1kc` referenced in #6 has been replaced by `nas-gfw5uy4w` at some point — worth confirming when triaging #6.) **Operational proof:** - Tonight this bridge sent multiple successful E2EE messages to the bridge room (event IDs `$aokNdriCJa893Ts…`, `$o1eCsWiKIJDR1sSv…`, `$rDn8ecIp3sRVlEN…`, the PR-14 handoff messages, etc.) — all decrypted by peers. Not a black hole. - The matrix-bridge MCP under Claude Code on this MBA writes to `/Users/ziefle/.matrix-bridge/store/` — jmz's home directory, jmz's device. **What probably happened in May**: this MBA was idle for the 2 days before the issue was filed (2026-05-02), and the runbook only documented Pi5 + NAS-Docker for Maximus, so its appearance in the netmap looked unexplained. The `display_name: Maximus@mba` (matching the active-bridge naming convention) was a hint that it WAS a legitimate Maximus instance, just on a host the runbook hadn't caught up with. **Lesson from this issue still worth keeping** (re-filing separately if not already done): - `bridge-client-setup.md` should document graceful teardown (logout) so retired devices don't linger - Canonical list of registered devices (which host runs which `device_id`) should live somewhere stable, not just ad-hoc in display_names Closing.
jmz closed this issue 2026-05-27 23:40:28 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/mcp-single-instance-guard
feat/15-device-audit
upstream
No results found.
Labels
Clear labels   
agent:felinus
Felinus is driving

  
agent:human
A human is driving

  
agent:maximus
Maximus is driving

  
priority:p0
Drop everything; production down

  
priority:p1
Important; days

  
priority:p2
Normal; weeks

  
priority:p3
Low; whenever

  
status:blocked
Waiting on input or dependency

  
status:needs-review
Ready for human eyes

  
status:wip
Active in-progress

  
type:chore
Tooling, infra, no shipped behaviour change

  
type:docs
Documentation only

  
type:feat
New feature or capability

  
type:fix
Bug fix

  
type:perf
Performance improvement

  
type:refactor
Code restructuring with no behaviour change

  
type:test
Test additions / fixes

No labels
agent:felinus
agent:human
agent:maximus
priority:p0
priority:p1
priority:p2
priority:p3
status:blocked
status:needs-review
status:wip
type:chore
type:docs
type:feat
type:fix
type:perf
type:refactor
type:test
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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
jmz/matrix-bridge#5
No description provided.