From 0c61ea3a97fe51f49621c427de9f0393c3656b8d Mon Sep 17 00:00:00 2001 From: Jaap-Jan de Wit | DodoTech Date: Wed, 5 Aug 2026 19:10:25 +0200 Subject: [PATCH] Let a vault be shared from the phone, not only read there MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This screen's own comment argued ADD out: an address typed into a box, a directory lookup, a role picker and a paragraph saying what adding somebody did not do, for an act a colleague at a desktop is already performing. That was a cost argument and it was wrong about who is holding what. The person who needs to let somebody into a vault is often the one away from their desk, and answering them with "go and find a desktop" is the thing this head exists to stop doing. Making a vault was already here on exactly that reasoning. Nothing shared changed — AddMemberCommand, the role and the chips are the same members the desktop binds — so what this is, is markup and the argument it reverses. Four rows under the members list: the box, three role chips rather than a picker because the answer is one of three short words, ADD, and the paragraph. Gated on being able to administer the vault, so a plain member sees nothing rather than a button whose only outcome is a 403. The paragraph is not the optional part. Adding somebody changes what the server will serve and nothing else; the key is still wrapped by a machine that holds one — which on an unlocked phone is this one, in the same press. A screen that offered the first and stayed quiet about the second would imply the server can hand out access, which is the single claim this product is built to refuse. What the phone still does not draw is anything that takes access away. REMOVE and WITHDRAW KEY act on the first press, and an irreversible revocation under a thumb with its explanation in a tooltip no touch screen can show is the wrong trade — which is the line this file already drew and this does not move. Check 12.4 walks it, including the locked-keychain case: the membership is made and the line says the key could not be wrapped, which is a state somebody can act on rather than silence. --- README.md | 7 +- docs/design-import-gaps.md | 3 +- docs/manual-checks.md | 23 ++++++ .../Views/VaultsScreen.axaml | 80 +++++++++++++++++-- 4 files changed, 106 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index c1a7897..0373ea2 100644 --- a/README.md +++ b/README.md @@ -546,7 +546,12 @@ desktop job. Pins and import have no phone screen either, and importing an `~/.s on a phone at all. **VAULTS does have one**, behind MORE, and it is there for a reason the design could not have anticipated: a vault arrives without being asked for — somebody wraps its key to you — so the person it arrives for is at least as likely to be holding a phone as sitting at a desktop, and a membership -visible only on a head they have not installed is a membership they cannot see. +visible only on a head they have not installed is a membership they cannot see. **Somebody can be added to +a vault from the phone too**, with the same box, the same role and the same sentence about what adding does +not do — and if that phone can open the vault, it wraps the key in the same press. What the phone still +does not draw is anything that takes access away: REMOVE and WITHDRAW KEY act on the first press, and an +irreversible revocation under a thumb with its explanation in a tooltip nothing can show is the wrong +trade. **Port forwarding is not built anywhere**, and the phone's More screen says so in a paragraph rather than leaving a gap. The v2 design draws a whole screen for it; nothing in the SSH layer forwards anything, so diff --git a/docs/design-import-gaps.md b/docs/design-import-gaps.md index b0c0258..6e3ab79 100644 --- a/docs/design-import-gaps.md +++ b/docs/design-import-gaps.md @@ -30,7 +30,8 @@ the chrome, hosts and terminals, file transfer, the vault, teams, and preference > SFTP and S3 are one screen over one `TransfersViewModel`, differing only in which picker they offer. > > **A sixth is behind MORE that v2 never drew: VAULTS.** It is the reverse case — a shipped screen the -> design had no slot for — and it is on the phone because a vault arrives without being asked for. +> design had no slot for — and it is on the phone because a vault arrives without being asked for, and +> because somebody can be let into one from there. > Somebody wraps its key to you from their machine, and the person it arrives for is at least as likely to > be holding a phone as sitting at a desktop; a vault the server has just put somebody in, visible only on > a head they may not have installed, is a membership they cannot see. It runs over the same view model diff --git a/docs/manual-checks.md b/docs/manual-checks.md index 4720de2..630b734 100644 --- a/docs/manual-checks.md +++ b/docs/manual-checks.md @@ -1427,6 +1427,29 @@ instead — distinct from the "no account here" refusal in 12.1, because the two **Failure means:** the two refusals reading alike leaves somebody checking what they typed when the answer is that the person is already in. +### 12.4 Somebody can be added from the phone, and the key goes with them · **needs a device and two accounts** + +On the phone: Settings → Vaults, choose a shared vault this account administers. + +**Pass:** under the members list there is an ADD SOMEBODY box, three role chips with MEMBER lit, an ADD +button, and a paragraph saying that adding lets the server serve them and does not let them read anything. +On a vault this account only belongs to, none of that is drawn at all — not greyed, absent. + +Type a colleague's address and press ADD, with the phone unlocked. + +**Pass:** they appear in the members list, and the status line says both halves — that they were added, and +what happened to the key. On an unlocked phone that holds the vault key it says it shared it; the colleague +syncs and the vault opens. + +Now lock the phone's keychain and add somebody else. + +**Pass:** it refuses to pretend. The membership is made and the line says the key could not be wrapped +because this keychain is locked — which is a state somebody can act on, unlike silence. + +**Failure means:** a screen that adds somebody and says nothing about the key is implying the server can +hand out access, which is the one claim this product exists to refuse. ADD drawn for a plain member is a +button whose only outcome is a 403 from the server. + ### 12.5 LAST ACTIVE is a real time, and a coarse one · **needs a couple of hours** Use one account and leave the other idle for two or three hours, then read the members table. diff --git a/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml b/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml index 87290d8..e2dd024 100644 --- a/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml +++ b/src/DodoSSH.Client.Android/Views/VaultsScreen.axaml @@ -2,6 +2,7 @@ xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:vm="using:DodoSSH.Client.Shell.ViewModels" xmlns:views="using:DodoSSH.Client.Android.Views" + xmlns:contracts="using:DodoSSH.Contracts" x:Class="DodoSSH.Client.Android.Views.VaultsScreen" x:DataType="vm:VaultsViewModel" Background="{StaticResource Canvas}"> @@ -45,11 +46,22 @@ plainer reason: it decides who controls the vault, which is not a thing to do while walking. Nor is renaming, which is a keyboard on a screen that is otherwise all reading. - **ADD is not drawn either**, and it is the operation this screen least needs. It is an address typed - into a box, a directory lookup, a role picker, and a paragraph beside it saying what adding somebody - did *not* do — five controls for the one act on this screen that a colleague at a desktop is already - doing. Making a vault is here, because it is one field and because it is what a person carrying a - phone can usefully start. + ◆ **ADD is drawn, where it was not.** The argument against it was that it is an address typed into a + box, a directory lookup, a role picker and a paragraph saying what adding somebody did *not* do — five + controls for an act a colleague at a desktop is already performing. That was a cost argument and it was + wrong about who is holding what: the person who needs to let a colleague into a vault is often the one + away from their desk, and telling them to go and find one is the same answer this head exists to stop + giving. Making a vault was already here on exactly that reasoning. + + What it costs is four rows under the members list rather than five controls, because three of them are + the role and are chips rather than a picker — the same chips the host editor wears for tags, so the + choice is visible without being opened. It is gated on being able to administer the vault, so on a + membership where the answer would be a refusal there is nothing to press. + + **The paragraph comes with it and is not the optional part.** Adding somebody is a change to what the + server will serve and nothing else; the key still has to be wrapped from a machine that holds it, which + on this head is the bar below. A screen that offered the first and stayed quiet about the second would + be implying the server can hand out access, which is the one claim this product is built to refuse. **The key-holder list is not drawn.** It is a third list, and what the phone can answer about a vault is the more useful half of the same question and is on the vault's own row: whether *this* machine can @@ -243,6 +255,64 @@ + + + + + + + + + + + + + + + + +