iOS verklaard: zonder apparaat geen sleutel, en dus geen synchronisatie

De gebruiker merkte op dat hij op de Mac per wallet op de hardware wallet moest
goedkeuren, en dat zijn model nog niet aan een iPhone te koppelen is. Dat sluit de
keten, en die is in de broncode van Suite na te lezen.

De OwnerId wordt op het apparaat afgeleid: createRetrieveSuiteSyncOwner begint met
een harde controle op device.connected. selectIsSuiteSyncInitPossible eist
connected plus ondersteuning. En selectSuiteSyncInteraction geeft null zodra er
geen deviceStaticSessionId is, waarna useTurnOnSuiteSyncGuard in dezelfde tak
belandt als 'unsupported' en gewoon ok() teruggeeft.

Dat verklaart elke waarneming tegelijk: de schakelaar liet zich aanzetten, want
dat is alleen een instelling; er kwam geen foutmelding; er was geen groen bolletje;
en onze relay zag nooit een eigenaar. Zonder een Trezor die aan de telefoon kan is
er geen eigenaar, en zonder eigenaar valt er niets te synchroniseren, met of zonder
relay.

Dit is dus geen tekortkoming van dit pakket en er valt niets aan te repareren. Wat
het wel betekent voor de app-tekst is dat werken op een telefoon niet beloofd moet
worden zolang dat van het model afhangt.

Wat erdoor open blijft is de leeskant: dat een tweede apparaat de labels terugkrijgt
is nooit gezien, en iOS zou die tweede client zijn geweest. Dat is nu de
belangrijkste openstaande controle, en er is een client voor nodig die wel een
sleutel kan afleiden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Harmen
2026-08-28 13:38:18 +02:00
co-authored by Claude Opus 5
parent bf8bedcda9
commit fc5a941de0
4 changed files with 47 additions and 12 deletions
+28 -1
View File
@@ -123,7 +123,34 @@
- **geen regel** → de telefoon bereikt die naam niet. Dan is het DNS of routering: mobiel netwerk in
plaats van WiFi, of een subdomein dat alleen in de interne DNS bestaat.
**Moment:** de volgende sessie, als eerste taak van dit punt · **Eigenaar:** gebruiker
**En aan het eind van de dag kwam het antwoord alsnog, uit de cliëntcode en uit een opmerking van de
gebruiker: het ligt aan het apparaat, niet aan het netwerk.** Hij merkte op dat hij op de Mac per wallet
op de hardware wallet moest goedkeuren, en dat zijn model nog niet aan een iPhone te koppelen is; de
Safe 7 wel.
Dat sluit de keten, en die is in de broncode van Suite na te lezen:
- de `OwnerId` wordt op het apparaat afgeleid. `createRetrieveSuiteSyncOwner.ts` begint met
`if (!device.connected) return err(DeviceNotConnectedError(...))`;
- `selectIsSuiteSyncInitPossible` eist `device.connected && isSuiteSyncSupportedByDevice(device)`;
- `selectSuiteSyncInteraction` geeft **`null`** zodra er geen `deviceStaticSessionId` is, dus zodra de
app helemaal geen apparaat kent;
- en in `useTurnOnSuiteSyncGuard` valt `null` in dezelfde tak als `'unsupported'`: **`return ok()`**.
Het label wordt lokaal opgeslagen, er gebeurt verder niets, en er is niets te melden.
Dat verklaart alle waarnemingen tegelijk: de schakelaar liet zich aanzetten (dat is een instelling,
`settings.isSuiteSyncEnabled`, en die zegt op zichzelf niets), er kwam geen foutmelding, er was geen
groen bolletje, en onze relay zag nooit een eigenaar. **Zonder een Trezor die aan de telefoon kan, is er
geen eigenaar, en zonder eigenaar valt er niets te synchroniseren, met of zonder relay.**
**Conclusie: dit is geen tekortkoming van dit pakket en er valt hier niets te repareren.** De relay
werkt; de cliënt komt op dat platform niet aan een sleutel. Wat het wél betekent voor de app-tekst is dat
"werkt op je telefoon" niet beloofd moet worden zolang dat van het model afhangt.
Wat nog de moeite waard is om te meten, en alleen omdat het goedkoop is: of het verzoek de telefoon
überhaupt verlaat, via het log van Zoraxy. Bij de verklaring hierboven hoort dat het níet vertrekt. Zie
je toch verzoeken, dan klopt er iets niet aan deze redenering en begint het opnieuw.
**Moment:** beantwoord op 28-08-2026; de controle in Zoraxy is optioneel · **Eigenaar:** gebruiker
8. **Welke limiter komt er op de kale relay?** - **beslist op 28-08-2026: weg 1, de relay uitbreiden via
`createRelay`.** Het ontwerp staat in [PLAN.md](PLAN.md) §4g en bleek veel kleiner dan hieronder
+10 -5
View File
@@ -16,11 +16,16 @@ wint" sloot daarmee de tweede wallet van de gebruiker buiten. En de korte contai
gedeelde Docker-netwerk niet uniek, waardoor de helft van de verzoeken bij Electrum Gate uitkwam en die app
kapotging. Beide zijn gerepareerd, de tweede met een toets erop.
**iOS blijft open en het vermoeden is weerlegd.** TLS was niet de verklaring: met een geldig certificaat,
een opgeslagen URL en de sync-schakelaar aan komt er nog steeds niets aan. Sinds 0.3.0 logt de relay élke
eigenaar die zich meldt, ook bekende en geweigerde, en van de telefoon verschijnt niets. De volgende stap
staat in [OPEN.md](OPEN.md) punt 9: kijken of het verzoek de telefoon überhaupt verlaat, via het log van
Zoraxy.
**iOS is aan het eind van de dag alsnog verklaard, en het ligt niet aan dit pakket.** TLS was niet de
oorzaak: ook met certificaat, opgeslagen URL en de sync-schakelaar aan kwam er niets aan, en sinds 0.3.0 is
dat hard gemeten omdat de relay élke eigenaar logt. De verklaring kwam uit de cliëntcode plus een opmerking
van de gebruiker: de `OwnerId` wordt op de Trezor afgeleid, en zijn model kan nog niet aan een iPhone. Zonder
apparaat kent de app geen device state, en dan slaat Suite een label lokaal op en doet verder niets, zonder
melding. Bronregels in [OPEN.md](OPEN.md) punt 9.
Daardoor blijft de leeskant ongemeten, en dat is nu de belangrijkste openstaande controle. Er is een tweede
cliënt voor nodig die wél een sleutel kan afleiden; een tweede desktop met dezelfde Trezor is de kortste
weg.
**Geraakt:** de hele app-map, `tools/evolu-relay/`, `tests/`, `CLAUDE.md`, `whatsnext-electrum-gate/` en de
documentatie. **Tests:** alle vier groen.
+8 -5
View File
@@ -19,12 +19,15 @@
van 40960 naar 49152 bytes. **De protocolversie klopt**, en daarmee is de richting uit
[OPEN.md](OPEN.md) punt 6 gemeten in plaats van verwacht. Het protocol en alle metingen staan in
[PLAN.md](PLAN.md) §6a
- [ ] **Kijken of het verzoek de iPhone überhaupt verlaat.** Dit is de volgende stap van dit plan, en hij
kost een minuut: open op de telefoon `https://<subdomein>/` in Safari en kijk of Zoraxy een regel
logt. Wél een regel betekent dat de app niet belt; geen regel betekent dat de telefoon die naam niet
bereikt. Zie [OPEN.md](OPEN.md) punt 9 voor alles wat al uitgesloten is. **Eigenaar: gebruiker**
- [x] **Uitgezocht waarom iOS niets doet (28-08-2026): het ligt aan het apparaat en niet aan dit pakket.**
De `OwnerId` wordt op de Trezor afgeleid, en het model van de gebruiker kan nog niet aan een iPhone
gekoppeld worden. Zonder apparaat kent de app geen `deviceStaticSessionId`, en dan slaat Suite een
label lokaal op en doet verder niets, zonder melding. De hele redenering met bronregels staat in
[OPEN.md](OPEN.md) punt 9
- [ ] **De leeskant nog meten.** Er is nooit een tweede werkende cliënt geweest, dus dat een ander apparaat
de labels terugkrijgt is niet gezien. Dit hangt aan de vorige taak: iOS zou die tweede cliënt zijn.
de labels terugkrijgt is niet gezien. **Dit is nu de belangrijkste openstaande controle van dit plan**,
en er is een tweede cliënt voor nodig die wél een sleutel kan afleiden: een tweede desktop met
dezelfde Trezor is de kortste weg. iOS valt af zolang het apparaat niet aan de telefoon kan.
**Eigenaar: gebruiker**
- [x] **Besloten wat er met het huidige pakket gebeurt (28-08-2026): het gaat eruit.** De relay van Trezor,
de quota-manager en de Postgres vervallen. Wat ervoor in de plaats komt staat in [PLAN.md](PLAN.md)