Repository navigation
Conversation
…roof Stage 2 of #331, the Burrow half. A paired session may list the ACL's records and revoke one by its device id, inside the Noise session, so the Relay holds no device directory. A revoke always needs a proof over a challenge that request was just answered with, in a new `session` presence binding, verified by the Burrow's one verifier against its own state and the session's own record. The list needs a proof the session has shown, at its connection or since, so a window ride shows one first. Revocations go through the service under a `pocket` requester no Client and no command can claim. A one-time session gets no port, so the verbs are the unknown method they are on an older Burrow, and hello says which is which. A session revoking itself is answered before the revocation runs, since the goodbye ends it and nothing after that is read. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each paired, online Burrow row reaches its list on a session of its own, with no wall behind it, and the wall's Settings reach the same panel on the session they have. Every action starts on a tap, since each may raise the passkey prompt, and the confirmation is inline: this is touch UI. A Burrow older than the verbs, and a Relay older than the binding, each read as what they are, never as no devices. A browser revoking its own pairing drops its authorization as an authenticated `pairing-required` does, keeping the pin, and its row then offers Pair again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stage 2 of #331 is built, so "Account-wide devices" leaves `## Future` for "Revocation from Pocket", and remote-api's stage 10 for "Paired browsers", where protocol-v1's scope rule now names them. New audited rules S302-S304 sit under Trust boundary, with the e2e-lint rule that holds the one-time phone to no verb and a self-test for each spelling. security.md states the limit: the prompt guards Pocket's Revoke, not an attached terminal's `dor remote revoke`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ttings Mutation found three lines nothing held. Clearing the session's challenge on spend was unobservable, since consuming it is the single use, so it goes. Voiding an older challenge only bounds the issuer, and resolving the id again at the revoke only matters against another revocation: each now has a test. Hosted's reauth routes get the `session` binding's case beside the self-host Relay's, and the revoke guarantee names Pocket. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Beside a Revoke button, Last seen was the part cut off. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Wrapping hello in an async method put its answer a turn behind a later request's, which the direct path's drain test reads as out of order. Read the flag off the core's own promise instead. A panel test's key generation also ran inside a mock the screen settles on, so it failed under load. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…t-devices Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deploying mouseterm with
|
| Latest commit: |
df06ce2
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://8cf36a49.mouseterm.pages.dev |
| Branch Preview URL: | https://issue-331-stage2-pocket-devi.mouseterm.pages.dev |
dormouse-bot
reviewed
Nov 3, 2026
dormouse-bot
left a comment
dormouse-bot
left a comment
Collaborator
There was a problem hiding this comment.
The new devices.* declarations were inserted between ConnectResult's doc comment and its type. As a result, DEVICE_REFUSAL_MESSAGES now carries two stacked JSDoc blocks, and ConnectResult lost its doc, so hovers show the wrong text for both. The two suggestions below move the comment back.
Ned's decision on #1528: a window ride lists with no prompt. An authorized session reads the same through `dor remote list` in an attached terminal, so a prompt there would cost a tap and protect nothing. Revoking still takes a fresh proof, never a window ride or the connection's. With no prompt to wait on a tap for, the panel reads the list on opening, in Settings as on a Burrow's row, and offers Try again only after a failure. The `presence-required` answer and a list's proof param leave the wire, since nothing ever sent them. Also moves the `devices.*` declarations out from under `ConnectResult`'s doc comment, which had left `DEVICE_REFUSAL_MESSAGES` with two and `ConnectResult` with none; a scan of this branch's source finds no other stacked doc comment. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ned is removing `dor remote` before it ships, in its own PR, so the security.md gap about typing `dor remote revoke` closes with it, and the rationale gives the list's reason on its own terms. Also pins why each proof is refused and that a malformed list reads as the Burrow failing, which mutation found nothing held. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dormouse-bot
reviewed
Nov 3, 2026
dormouse-bot
left a comment
dormouse-bot
left a comment
Collaborator
There was a problem hiding this comment.
On the new standalone "Paired browsers" screen (phase.at === 'devices'), nothing watches the session the way the wall's adapter does. If the session ends while the screen is open (Burrow restart, Relay drop, the reaper), #core.establishedRoute becomes null, so #servesDevices() is false. The next "Try again" or Revoke then answers DEVICES_UNSUPPORTED_MESSAGE. listDevices also sets unsupported: true, which switches the panel to its permanent "too old" view. The person is told to update a Dormouse that is current, when reconnecting would fix it. The suggestions below report an ended session as ended.
`#servesDevices` answered one question for two facts: no session, and a session whose hello said no `devices`. So a list or revoke after a session ended read "too old", and the panel stuck on that view. Only a live session's own answered hello now speaks for the Burrow; with none, either verb reports the connection ended, which connecting again mends. A test had pinned the old reading. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dormouse-bot
approved these changes
Nov 3, 2026
Member
Author
|
Closing per the maintainer's decision: not building stage 2. #1527 covers the lost-phone case by revoking a removed passkey's pairings on every computer, and Settings revokes one browser on the computer itself. The branch stays if this is ever revisited. |
This was referenced Nov 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stage 2 of the design merged in #1473, stacked on #1527: from Pocket, a person can see the browsers paired with each online Burrow and revoke one. Its base is
issue-331-stage1-passkey-revocation; it retargetsmainwhen #1527 merges.Wire. Protocol-v1 gains
devices.listanddevices.revoke, inside the Noise session. The Relay sees only ciphertext: no record's label,deliveryId, approval time, ordeviceIdForid reaches it. One-time sessions get neither verb. An older Burrow or Relay reads as "too old", never as "no devices".Listing takes no prompt. Any paired session can list, a window ride included.
Revoking takes a fresh presence proof. A new
sessionpresence binding carries no target, and the Burrow remembers which id each challenge answers. Neither a window ride nor the connection's own proof counts. Revocation goes bydeviceIdForid throughBurrowService.revokeunder requesterpocket, which the service sets; a Client can't name it.UI. Burrow rows gain "Paired browsers", and wall Settings show the same list on opening. Revoking your own browser is answered before the goodbye, and the row then offers Pair again.
Specs. The stage is promoted, and "Account-wide devices" is deleted from
## Futuresince nothing is left. New rulesS302-S304, and a newe2e-lintrule with self-tests.remote-api.md's terminal-only scope now names these verbs.Verified on this head:
test:audit(197),test:checks, the specs, md, e2e, outbound and public-docs lints,tscin lib, standalone, vscode-ext and hosted, remote-lib-common (363), the Relay reauth, e2e-ceremony and malicious-relay tests (30), lib'ssrc/remote,src/host/remoteandsrc/componentssuites (3504, no unhandled errors), and these stories on Chromium through the Argos config. Before the list change: Hostedrelay.test.ts,lint:deployandlint:workflows. Every mutation went red: 35 before the list change, 10 on the replacement, and 7 on the ended-session fix, the five survivors resolved with one line deleted and four tests added or tightened. Not verified: a live app, a real Relay with a phone, or WebKit stories.iPhone checklist, required before shipping (Home Screen install and Safari tab):
Deploy: either order is safe; the verbs are unavailable until both ends are new. Relay and Pocket first, for self-host and Hosted, then Burrows.
Argos: new
Pocket/PairedBrowsersstories,InSettingsnow showing the list rather than a button, andPocket/BurrowsViewmoves because rows gain "Paired browsers".Closes #331 together with #1527.
🤖 Generated with Claude Code