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:
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user