HarmenandClaude Opus 5
64ba74e053
Twee onbekende eigenaars krijgen allebei HTTP 401 op de WebSocket-upgrade van de echte relay. Daarmee is de bewering uit paragraaf 10 van Upstream-evolu-relay.md geen redenering uit de broncode meer maar gezien gedrag. Gratis erbij bewezen: de reverse proxy laat de upgrade door en het certificaat klopt, dus de relay is over wss:// bruikbaar, en dat raakt het masterplan Bereikbaarheid. De eerste poging faalde met ECONNREFUSED op een adres van de vorm wss://host:3852. Dat is een tegenstrijdigheid: 3852 is waar de relay zelf luistert in plat ws binnen het netwerk, terwijl het certificaat op de reverse proxy zit en die op 443 luistert. Zonder poort werkt het. Die valstrik staat nu in .env.sample, want hij kost anders iedereen dezelfde ronde. Wat de client niet kan zien en dus bij de gebruiker ligt: staan die twee in de weigerlijst op de statuspagina. Suite: 475 goed, 0 fout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.2 KiB
Voortgang - Testclient
09-09-2026 - plan geschreven, gepromoveerd, en de samenstelling werkt
Het masterplan is geschreven en dezelfde dag gepromoveerd naar Actief/003-Testclient/, op verzoek van de
gebruiker. Bij het schrijven ging §4b eerst over de verkeerde vraag: "alles vanuit één scherm" werd gelezen
als een scherm over cliënt én relay. De server-app blijft ongemoeid en synchroniseert met Trezor Suite op
de Mac, dus dat is herschreven naar wat het scherm zelf doet.
Fase 1 is af, en dat was de stap waarvan het plan zei dat hij eerst moest. @evolu/nodejs bevat geen
cliënt, alleen de relay plus losse bouwstenen; createEvolu krijgt zijn afhankelijkheden nu uit
tools/relay-client/src/evolu-node.js, samengesteld uit de in-memory workers van @evolu/common. Vier
dingen zaten in de weg, alle vier stil falend: de ontbrekende installPolyfills() (Node 24 mist
Map.getOrInsertComputed), createEvoluDeps overslaan ("Expected tab leader port."), de
AsyncDisposableStack van initSharedWorker laten vallen, en workers zonder eigen reportDefect. Dat
laatste is waarom de andere drie te vinden waren; zonder dat zegt elke fout hetzelfde en noemt geen oorzaak.
Bewezen met een wegwerpproef: eigenaar aanmaken, transports: [], een rij met een Uint8Array-kolom
wegschrijven en teruglezen. De bytes komen er ongeschonden uit en het proces sluit schoon af.
Nog niet geprobeerd: praten met de relay. Daar is het adres van de Umbrel voor nodig en dat komt van de gebruiker; het gaat niet in deze publieke repo.
09-09-2026 - de cliënt staat: opdrachtregel, bedieningsvlak en twee starters
Fase 2, 3 en 5 in één sessie. Er is een register (owners.json met naam, mnemonic en OwnerId), een
opdrachtregel met acht opdrachten, en een bedieningsvlak op http://127.0.0.1:4380 met per eigenaar de
knoppen uit PLAN.md §4b. Start.bat en Start.command erbij op verzoek van de gebruiker: die draaien
npm install als het nodig is, waarschuwen als .env ontbreekt en openen de browser.
OPEN.md punt 1 is opgelost voordat het een probleem werd. src/probe.js doet de WebSocket-upgrade met
node:http in plaats van met de WebSocket van Node, want die laatste geeft je bij een weigering een
error en geen statuscode. De opdracht klop en de knop "Aankloppen" tonen dus 101 of 401.
Twee echte fouten gevonden en vastgezet in een toets. De eerste: de databasemap werd niet aangemaakt, en
omdat better-sqlite3 dat in een worker meldt was het symptoom een lees die nooit antwoordde. De tweede,
en die is er een om te onthouden: evolu.insert geeft meteen een id terug en zet de schrijfactie in de
wachtrij van de worker, dus wie vlak daarna afsluit is de rij kwijt. Het symptoom was een lees die
"nog geen blobs" meldde over een blob die zojuist bevestigd was. schrijf wacht nu op een query erachter,
en de toets sluit af en heropent.
In de browser nagekeken: een blob schrijven en teruglezen werkt vanuit de pagina, de gegevens zijn dezelfde als die van de opdrachtregel, en licht en donker kloppen allebei.
Wat er nu ligt te wachten is één regel in .env. Alles wat de relay raakt is gebouwd en niets ervan is
beproefd, en dat blijft zo tot het adres er is.
09-09-2026 - de eerste proef, en hij slaagde
De gebruiker vulde .env in en de eerste poging faalde met ECONNREFUSED, op een adres van de vorm
wss://host:3852. Dat is een tegenstrijdigheid: poort 3852 is waar de relay zelf luistert in plat ws
binnen het netwerk, terwijl het certificaat op de reverse proxy zit en die op 443 luistert. Zonder poort
werkt het, en die valstrik staat nu in .env.sample.
Daarmee is de eerste proef uit PLAN.md §4c gedaan, en hij bevestigt wat er tot nu toe alleen beredeneerd
was: twee onbekende eigenaars krijgen allebei HTTP 401 op de WebSocket-upgrade. Zie §10 van
Upstream-evolu-relay.md, waar dat uit de broncode was
afgeleid. Gratis erbij bewezen: de reverse proxy laat de WebSocket-upgrade door en het certificaat klopt,
dus de relay is over wss:// bruikbaar. Dat raakt het masterplan Bereikbaarheid.
Wat deze cliënt niet kan zien, en dus bij de gebruiker ligt: staan die twee eigenaars in de weigerlijst op de statuspagina van de app?