Files
UmbrelApps/Docs/Plannen/Actief/008-Umbrelapp/PROGRESS.md
T
HarmenandClaude Opus 5 fc5a941de0 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>
2026-08-28 13:38:18 +02:00

13 KiB

Voortgang - Umbrelapp

Chronologisch sessielog, nieuwste bovenaan. Kort: 3 tot 6 regels per entry. Wat er is gebeurd en waarom, niet wat er nog moet: dat staat in TAKEN.md.

28-08-2026 (slot) - de app draait en wordt gebruikt; iOS doet niet mee

Het pakket is af en geïnstalleerd als 0.3.0. De Mac synchroniseert eroverheen, over TLS via Zoraxy op een eigen subdomein; de handshake-curl geeft daar 101 Switching Protocols. De allowlist werkt in beide richtingen: een eigenaar geleerd, de deur gesloten, en een tweede eigenaar die daarna aanklopte alsnog toegelaten met de knop op de pagina.

Twee dingen die uit echt gebruik kwamen en die geen nadenken had opgeleverd. Eén cliënt kan meer dan één eigenaar hebben, want een OwnerId hoort bij een wallet en niet bij een apparaat; "de eerste eigenaar wint" sloot daarmee de tweede wallet van de gebruiker buiten. En de korte containernaam agent is op het 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 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 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.

28-08-2026 (avond) - het pakket is omgebouwd: relay, agent en pagina

De app-map is nu de kale relay met onze allowlist eromheen. De poorten zijn omgedraaid: de statuspagina hangt achter app_proxy mét de inlog van umbrelOS, de relay publiceert 3852 waar Zoraxy met TLS naartoe gaat wijzen. Postgres, het wachtwoord en de quota-manager zijn eruit.

De gebruiker heeft de image gebouwd en naar het Gitea-register geduwd; de compose is gepind op tag plus digest. Manifest naar 0.2.0, met een beschrijving en releaseNotes die niet langer over Trezor's relay en een quota-manager gaan.

Het relay-programma is daarna wél gemeten, losgedraaid uit het register en buiten de app om: het log meldde learned a new owner, en in /app/data stonden evolu-relay.db van 49152 bytes en owners.json van 241 bytes. De hele keten werkt dus. Wat nog ongetest is, is de pagina en de agent: alleen op syntaxis gecontroleerd, nooit gerenderd, en of een knop bij het relay-proces aankomt is niet gemeten.

Terzijde, want het leek een storing: Suite meldt bij een nieuwe migratie "0 labels migrated successfully, 11 skipped". Dat is geen fout. Uit hun eigen teksten: alleen ontbrekende labels worden gekopieerd, en die elf stonden al in de lokale Evolu-database.

Geraakt: de hele app-map, tools/evolu-relay/build.sh en de documentatie van dit plan. Tests: alle vier groen (32, 54, 39 en 60 goed, 0 fout).

28-08-2026 (later) - het relay-programma staat, met een test erop

tools/evolu-relay/src/ bevat nu een eigen programma dat createRelay uit @evolu/nodejs aanroept met onze twee terugroepfuncties. Het beleid staat apart in policy.js als pure functies, zodat het te toetsen is zonder relay en zonder Docker: node tests/test_limiter.mjs, 60 toetsen. De beslissende regel is muteertest gedaan, en de juiste toets viel om: een geblokkeerde eigenaar mag er niet alsnog in via de leerstand.

build.sh bouwt niet langer de repo van Trezor maar onze eigen Dockerfile, en Git is daarvoor niet meer nodig. Onderweg bleek dat de 1 MB uit de gepubliceerde image per schrijfactie geldt en niet per eigenaar; dat is op twee plekken rechtgezet waar het verkeerd stond.

Geraakt: tools/evolu-relay/, tests/test_limiter.mjs, CLAUDE.md en de documentatie van dit plan. Tests: alle vier groen (32, 54, 39 en 60 goed, 0 fout).

28-08-2026 - de proef is geslaagd: de kale relay werkt

Trezor Suite op de desktop stuurde elf labels naar docker.io/evoluhq/relay:latest en die kwamen aan: de database in het volume groeide van 40960 naar 49152 bytes. Daarmee klopt de protocolversie en is de richting van 27-08 een gemeten feit. Geen Postgres, geen quota-manager, geen eigenaarsregistratie. De leeskant is niet bewezen: er is geen tweede cliënt geweest.

Het testprotocol staat nu uitgeschreven in PLAN.md §6a, en het is tijdens de sessie drie keer gecorrigeerd op instrumenten die een vals negatief gaven: docker diff kijkt niet in een volume, een browser of gewone curl krijgt van deze WS-server niets terug, en healthy komt uit een healthcheck die alleen een TCP-verbinding opent. Alle drie wezen ze een probleem aan dat er niet was.

iOS deed niet mee en dat is een eigen vraag geworden (open punt 9). Het veld voor de relay-URL bestaat daar wel, valideert op http(s):// en onthoudt zijn waarde, maar de app doet geen enkele verbindingspoging. Het vermoeden is TLS; dat is niet gemeten en het is duur, want een certificaat voor een LAN-adres bestaat niet.

Het ontwerp van de limiter en de pagina staat er ook, en de limiter bleek veel kleiner dan Bereikbaarheid §4b aannam: createRelay neemt twee terugroepfuncties, en Trezor doet zelf niets anders. De poorten gaan om, zodat de pagina achter de umbrelOS-inlog kan en Zoraxy met TLS naar de relay wijst. De gebruiker heeft de oude installatie weggehaald; die wordt niet geüpdatet maar opnieuw gebouwd.

Geraakt: documentatie van dit plan plus Referenties/Upstream-evolu-relay.md §8. Tests: niet van toepassing.

27-08-2026 - richting gekozen: kaal, met een limiter en een pagina erop

Nog niets gebouwd; dit is een sessie waarin alleen vastgelegd is. De gebruiker kiest voor de kale Evolu-relay, met een eigen limiter erop en de statuspagina uit open punt 2. Zijn woorden: "dat wordt beter." De app staat op dit moment uit op de Umbrel.

Die drie horen bij elkaar en dat is het inzicht van vandaag. De kale relay heeft geen toegangscontrole, en dat is bij Evolu het ontwerp en geen omissie. Wat vandaag de schade beperkt is juist een applicatiecontrole: Trezor's relay weigert elke eigenaar zonder limietenrij. Kaal gaan haalt precies die bescherming weg, dus de limiter is de vervanging ervan en geen extraatje. En de statuspagina krijgt er een taak bij: tonen wélke eigenaar toegelaten is, met de knop om die keuze te wissen.

De spanning is opgeschreven in plaats van weggepoetst: de meest voor de hand liggende limiter breidt de relay uit via createRelay, en dan komen de bouwstap en het eigen register terug die kaal gaan juist zou besparen. De gebruiker heeft dat ondervangen: de broncode staat nog op zijn Umbrel, dus opnieuw bouwen en naar het eigen Gitea-register duwen kan gewoon. Wat sowieso vervalt zijn de Postgres en het wachtwoord.

Het blijft een richting en geen besluit, want de proef is niet gedaan: klopt de protocolversie van docker.io/evoluhq/relay:latest met de @evolu/web@3.0.0-next.1 plus patch die Suite gebruikt? Die proef blijft de eerste taak, en er wordt niets verbouwd voordat hij geslaagd is.

Geraakt: alleen documentatie van dit plan. Tests: niet van toepassing.

25-08-2026 - hij draait, en de weg erheen liep via een verkeerde aanname

Gebouwd op de Umbrel in 50 seconden, en toen twee keer misgegaan op dezelfde muur voordat die muur begrepen was.

De installatie faalde met pull access denied op een image die lokaal gebouwd was. Mijn eerste verklaring kwam uit app-script van umbreld, waar install een compose "${app}" pull doet, en de reparatie was pull_policy: never. Dat faalde identiek. De oorzaak stond in de stacktrace en niet in de foutmelding: at /opt/umbreld/node_modules/docker-modem/lib/modem.js:382. umbreld haalt élke image via de Docker Engine API op en niet via compose, dus pull_policy wordt nooit gelezen. app-script is de legacy-compat-laag en niet het pad dat umbrelOS 1.x loopt. Les die breder is dan deze app: een bron die overtuigend leest, is nog geen bron die het draaiende pad beschrijft.

Daarmee was "lokaal bouwen als eerste stap" geen keuze meer. Elke image moet anoniem uit een register komen. Dat werd het Gitea-register op dezelfde server als de store: sc.kamenier-hamer.nl/sysop/evolu-relay, gepind op tag plus digest. Anoniem halen is eerst met een uitgelogde pull gecontroleerd, met dezelfde valkuil als bij het klonen van de store (uitloggen in de context waarin je inlogde, anders meet je je eigen sessie).

Daarna draaide hij in één keer. Drie containers omhoog, db gezond, de app-proxy op 3851. De lokale images waren vooraf weggehaald, dus de pull is echt gedaan en het hele pad is bewezen: broncode van Trezor → bouwrecept → eigen register → gepinde digest → installatie.

Kleinigheid met een staart: de gebruiker umbrel zit hier niet in de groep docker, dus bouwen vraagt sudo. Dat komt bij elke herbouw terug en staat daarom in het plan.

Geraakt: whatsnext-evolu-relay/docker-compose.yml en umbrel-app.yml (0.0.2), tools/evolu-relay/build.sh, Docs/Referenties/Umbrel-appstore-spec.md, dit plan. Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.

Nagekomen dezelfde dag, op de vraag van de gebruiker of deze app kwaad kan: er is een tweede weg naar binnen die in geen enkel bestand van deze app staat. umbrelOS maakt per app een Tor hidden service, en die stond aan. In combinatie met PROXY_AUTH_ADD: "false" betekent dat: de relay bereikbaar vanaf het internet, alleen beschermd doordat het .onion-adres onraadbaar is. De gebruiker zet hem uit.

Het mechanisme geldt voor élke app en staat daarom in de gedeelde naslag en niet alleen hier. Het gevólg verschilt: bij Electrum Gate legt dezelfde hidden service alleen de inlogpagina van umbrelOS bloot, want daar staat de proxy-inlog gewoon aan. De les is de combinatie en niet de instelling: wie PROXY_AUTH_ADD op "false" zet, moet meteen de hidden service beoordelen.

Wat nog steeds niet bewezen is: of het databaseschema zichzelf aanmaakt, of Trezor Suite dit adres accepteert, en of een eigenaar te registreren is. "Draait" is hier nog geen "synchroniseert".

25-08-2026 - plan werd actief, en het pakket staat er

De gebruiker besloot het pakket meteen te maken in plaats van te wachten op de proefopstelling. Dat kon, omdat fase 1 van Proefopstelling die middag de feiten had opgeleverd: één image met meerdere startscripts, een quota-manager die in de praktijk verplicht is, en geen publieke image.

De zwaarste ontwerpvraag is met een precedent beslecht en niet met een gok. Trezor Suite kan niet achter de inlog van umbrelOS, en het was onduidelijk of PROXY_AUTH_ADD: "false" dan een verantwoorde keuze is of een omweg. De eigen nostr-relay-app van Umbrel doet exact hetzelfde, om precies dezelfde reden, en heeft ook geen eigen ports:. Daarmee is de vorm van de compose niet zelfbedacht.

Twee dingen kwamen boven die niet in het ontwerp zaten. build/ staat in .gitignore als bouwselmap, dus het bouwrecept zou stilzwijgend buiten de repo zijn gebleven; het staat nu onder tools/. Dat kwam pas bij het stagen aan het licht en niet bij het schrijven, wat precies is waarom git status lezen erbij hoort. En de poort werd 3851 en niet 4000: 4000 is de eigen poort van de relay, maar ook een veelgebruikte poort, en een botsing op de host merk je pas als de app niet start. Die les komt van 50002 tegen Fulcrum.

Er is een derde testbestand, tests/test_appstore_vorm.py, en het gaat over de store en niet over één app: id gelijk aan mapnaam, store-voorvoegsel, veldvolgorde, app_proxy die naar een bestaande service wijst, en elke gemounte map die in de repo bestaat. Het vindt zijn apps zelf, dus een derde app valt er automatisch onder. Digests toetst het expres niet: geen van de twee apps haalt die regel vandaag, en een suite die altijd rood staat wordt niet gelezen.

Mutatie-getest met drie ingrepen: het app-id laten afwijken van de mapnaam, APP_HOST naar een niet-bestaande service laten wijzen, en de .gitkeep weghalen. Alle drie vielen om bij de juiste toets, met een bruikbare melding, en git diff was daarna leeg.

Geraakt: whatsnext-evolu-relay/ (nieuw), tools/evolu-relay/build.sh (nieuw), tests/test_appstore_vorm.py (nieuw), Docs/CHANGELOG-evolu-relay.md (nieuw), dit plan, Docs/CONTINUE_HERE.md, CLAUDE.md, README.md. Tests: 32 goed 0 fout (nieuw), 39 goed 0 fout en 54 goed 0 fout (bestaand), niets overgeslagen.

Wat er níet geverifieerd is, en dat is veel: er is nog niets gebouwd en niets geïnstalleerd. Of het databaseschema zichzelf aanmaakt, of Trezor Suite dit adres accepteert, en of een eigenaar te registreren is zonder iets extern: alle drie onbekend. "Gebouwd" is hier nadrukkelijk niet "werkend".