De teller met wachtenden heette ook "Waiting" en zei hetzelfde als het kader met
de lijst. Het aantal staat nu in de kop van dat kader, met de regel eronder
erbij; bij nul staat er geen getal, want de lijst zegt dan al "None." De plek in
de bovenste rij blijft leeg, op verzoek van de gebruiker: schuiven de andere
drie op, dan verliest "Status" de rechterkolom.
Met de adresregel weg viel op dat "About this app" eiste dat het sync-adres met
http begint en niet met ws, terwijl het kader onderaan ws:// toont. Beide
beweringen waren waar: de relay spreekt WebSocket, en het veld van Trezor Suite
neemt http(s)://, gemeten op 28-08-2026. Wat eruit moest was dus de eis. Er
staat nu dat het van de app afhangt, met dezelfde host en poort in beide
vormen, en de regel over wss:// zonder poort staat bij de alinea over van buiten
verbinden.
Nagekeken in voorbeeld/: de widget is weg met de lege plek op zijn positie, de
kop leest "Waiting 2", en het getal verdwijnt met de hidden-klasse.
Nog steeds 0.7.1 en nog niet gebouwd, dus de compose blijft zonder digest.
Suite groen: 22, 42, 90, 36, 54 en 68 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemeld door de gebruiker: een eigenaar uit het register halen liet de relay hem
zien tot het proces stopte. `vergeet` koppelt netjes af, maar de socket zit niet
in de Evolu-instantie: hij zit in de gedeelde worker, en die blijft staan zolang
er nog een eigenaar open is. Een transport dat je in de config van `createEvolu`
meegeeft, kun je daarna nergens opzeggen.
Nu start de instantie met `transports: []` en gaat de transport erin met
`evolu.useOwner`, ook al is het de eigen appOwner. Die geeft een opzegging terug
en Evolu telt de verwijzingen, dus de laatste opzegging sluit de socket.
Bewezen met een wegwerpproef tegen een relay op localhost die iedereen toelaat:
twee eigenaars open, dan de ene sluiten. Gemeten in de verbindingstabel van het
besturingssysteem en niet met de `dicht`-melding van de cliënt, want
`closeSocket` in @evolu/common zet `socket.onclose` op null voordat het sluit.
Oude vorm: 2 verbindingen na het sluiten. Nieuwe vorm: 1, en de andere eigenaar
kon daarna nog schrijven.
Suite groen: 42, 90, 36, 22, 54 en 68 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier punten van de gebruiker na een dag met 0.7.0. Drie zijn woordkeuze:
"Accepted owners" en "Waiting list" heten "Accepted" en "Waiting", de badge
"Waiting" is weg en de regel onder het adres is weg. De badge kon eruit zonder
verlies, want het onderscheid waarvoor hij er was blijft staan: een
geblokkeerde eigenaar is nu precies de regel met badge.
Het vierde punt was echt werk: elke rij is nu even hoog. Een rij werd hoger op
het moment dat je hem een naam gaf, want het label duwde het id naar een derde
regel. Nu deelt het id de onderregel met de tijden, afgekapt met een puntje en
volledig in de tooltip. Een vaste hoogte in CSS laat witruimte achter onder een
rij zonder label en leest dan als een weergavefout.
Nagekeken in voorbeeld/: vijf rijen, alle vijf 68px, ook tijdens het labelen.
Op het apparaat nog ongezien, want er is geen image: VERSION, het manifest en
de compose staan op 0.7.1 zonder digest.
Suite groen: 42, 90, 36, 22, 54 en 68 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De digest van de geduwde image staat achter de tag in de compose, drie keer
(relay, agent en server). Het manifest stond al op 0.7.0.
Suite groen: 42, 90, 36, 22, 54 en 68 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Testclient kan niet verder tot 0.7.0 op het apparaat draait: de proeven daar
vragen een relay die eigenaars toelaat. Een stap bij de gebruiker blokkeert dus
twee plannen, en dan hoort dat plan bovenaan te staan in plaats van in tier B.
Umbrelapp houdt zijn nummer 008; alleen de bovenkant van de reeks hoeft op
tier-orde te staan en 003 voor 008 klopt. De regel van Testclient noemt nu waar
hij op wacht in plaats van de .env die inmiddels gevuld is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier punten van de gebruiker, opgekomen tijdens het beproeven met de testclient.
De getimede leerstand is eruit; de wachtlijst is de enige weg naar binnen. Zijn
redenering: allebei de wegen vragen iemand die bij de app kan, dus het is
dubbelop, en het venster is de zwakste omdat het iedereen toelaat die er
toevallig in verbindt. Dat weegt zwaarder nu de relay op een publiek wss-adres
kan staan. De oorspronkelijke reden voor de leerstand, dat je je eigen OwnerId
nergens kon aflezen, verviel toen de weigerlijst dat id ging tonen. Daarmee
verdwijnt ook de bug die hij dezelfde dag meldde: een geleerde eigenaar bleef in
de weigerlijst staan terwijl hij al kon schrijven en lezen, want decideOwner
haalde hem niet van die lijst af en de knop allow wel.
"Refused owners" heet "Waiting list", met de badge Waiting en een teller waar de
widget van het tijdvenster stond. Het veld op schijf blijft rejected: hernoemen
zou een migratie zijn voor een woord dat niemand ziet.
Het adres onderaan zei http:// en dat kan nergens werken, want de relay spreekt
WebSocket en nooit HTTP. Nu ws://<host>:3852, met een regel over wss://<domein>
zonder poort achter een reverse proxy. Dat is precies de fout die diezelfde dag
een ronde kostte bij het koppelen van de testclient.
De melding bij elke klik is weg. Die stond in de gewone stroom van de pagina,
dus alles eronder schoof omlaag en weer omhoog. Nu gaan de knoppen in de lijsten
even op slot tot de ronde de nieuwe stand heeft; foutmeldingen blijven wel staan,
want die zeggen iets wat je nergens anders ziet.
STATE_VERSION blijft 1 en een owners.json van 0.6.0 leest door: learning en
learningUntil worden gelezen, genegeerd en niet teruggeschreven. Een verhoging
zou store.js de allowlist van een werkende installatie opzij laten schuiven.
Twee toetsen bewaken dat de leerstand niet terugsluipt: een onbekende eigenaar
wordt geweigerd ook met learning: true in het bestand, en set-learning is een
onbekende actie. Beide mutatie-getest.
De compose staat op 0.7.0 zonder digest, zodat het hard faalt tot de image
bestaat. Bouwen, duwen en pinnen ligt bij de gebruiker.
Suite: 424 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Voorstel van de gebruiker, en het tweede deel loste meer op dan een knop. Een
verbinding die geweigerd wordt bleef eindeloos opnieuw proberen, en elke poging
is een regel in de weigerlijst van de relay; zo liep die lijst tijdens deze
sessie ook vol.
- klop heet test op de opdrachtregel en Testen op de pagina.
- Verbinden gaat uit zodra een test zegt dat de eigenaar geweigerd wordt, met de
uitkomst in het rood naast de naam. Onbekend telt als toegestaan, want anders
moet je eerst testen om iets te mogen en is dat zelf ook een poging. Blob
schrijven gaat door dezelfde poort en schrijft dan lokaal verder.
- Een lopende verbinding stopt zichzelf: na drie mislukte sockets wordt er
precies een keer getest, en bij een weigering gaat de verbinding eruit. Is het
geen weigering, dan blijft hij staan, want dan is opnieuw proberen juist goed.
De melding in een dialoogvenster is eruit; de uitkomst staat naast de naam en in
het log en die blijven staan. In de browser nagekeken: testen geeft 401, de
regel verschijnt rood, en Verbinden is uitgegrijsd voor de geteste eigenaar
terwijl de ongeteste hem houdt.
Suite: 478 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Een fout van ons, gevonden door de gebruiker bij de tweede eigenaar: "Expected
tab leader port.". createEvoluDeps vraagt via navigator.locks het slot "tab" aan
en kondigt de houder aan als tab leader, en dat slot kan er maar een hebben.
openStore maakte per eigenaar een eigen stel afhankelijkheden, dus de tweede
werd nooit leider. Nu een stel per proces met een teller, zodat het pas
opgeruimd wordt als de laatste store sluit. Dit stond al als valstrik 2 in
PLAN.md 4e en was er alsnog in geslopen; de toets met twee eigenaars tegelijk
brengt hem terug zodra iemand dit ongedaan maakt.
Twee dingen erbij om te kunnen zien wat er met de relay gebeurt:
- spiegel <naam> opent dezelfde eigenaar in een lege database naast de
bestaande. Alles wat daar binnenkomt heeft de heen- en terugreis over de relay
gemaakt, en dat is de enige manier waarop de clientkant kan bewijzen dat er
werkelijk iets op de relay staat; lees toont je altijd je eigen rijen.
- onWebSocket meldt welke URL geopend wordt en wat ermee gebeurt. Zonder dat
ziet een relay die de socket dichtgooit er hetzelfde uit als een trage relay.
Dat luikje gaf meteen het antwoord: de socket komt nooit open, 1006, in een
herhaallus, en met het ws-pakket ernaast staat er wat de globale WebSocket
verzwijgt: 401. Twee eigenaars die eerder allebei 101 gaven zijn dus uit de
allowlist van de relay verdwenen. Dat is een vraag over de server-app en staat
als open punt 9, met vier verklaringen en wat ze uit elkaar houdt.
Suite: 478 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
De client staat. Een register (owners.json met naam, mnemonic en OwnerId), acht
opdrachten op de opdrachtregel, en een bedieningsvlak op 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, openen de browser en houden het venster open bij een fout.
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 geeft je bij een weigering een error en geen statuscode. De opdracht klop en
de knop Aankloppen tonen dus 101 of 401, en dat is precies wat de proeven uit
4c moeten kunnen aflezen.
Twee echte fouten gevonden en vastgezet in een toets. De databasemap werd niet
aangemaakt, en omdat better-sqlite3 dat in een worker meldt was het symptoom een
lees die nooit antwoordde. En evolu.insert geeft meteen een id terug maar zet de
schrijfactie in de wachtrij van de worker, dus wie vlak daarna afsluit is de rij
kwijt; schrijf wacht nu op een query erachter en de toets sluit af en heropent.
tests/test_client_register.mjs heeft geen pakketten nodig, want register.js,
argumenten.js en config.js raken Evolu niet aan. Drie mutaties geprobeerd en
alle drie lieten de juiste toets omvallen.
In de browser nagekeken: schrijven en teruglezen werkt vanuit de pagina, de
gegevens zijn dezelfde als die van de opdrachtregel, en licht en donker kloppen.
Alles wat de relay raakt is gebouwd en niets ervan is beproefd; daarvoor wacht
er een RELAY_URL in .env, en die komt van de gebruiker.
Suite: 475 goed, 0 fout over alle negen de toetsen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Het plan is gepromoveerd naar Actief/003-Testclient en tier A, en fase 1 is af.
De uitkomst die het plan als eerste wilde weten: @evolu/nodejs 3.1.0 bevat geen
client. Het pakket levert de relay plus losse bouwstenen, maar er is geen
createEvoluDeps voor Node zoals @evolu/web die voor de browser heeft. De
afhankelijkheden voor createEvolu worden nu samengesteld in
tools/relay-client/src/evolu-node.js, uit de in-memory workers van
@evolu/common; src/client.js is de publieke kant met eigenaars en blobs.
Vier dingen zaten in de weg en alle vier faalden ze stil, met een instantie die
het lijkt te doen tot de eerste schrijfactie: de ontbrekende installPolyfills
(Node 24 mist Map.getOrInsertComputed), createEvoluDeps overslaan, de
AsyncDisposableStack van initSharedWorker laten vallen, en workers zonder eigen
reportDefect. Dat laatste is waarom de andere drie te vinden waren. Uitgeschreven
in PLAN.md 4e.
tests/test_client_lokaal.mjs schrijft daarom een blob weg en leest hem terug in
plaats van alleen een instantie te maken, en heeft een wachthond: bij een defect
in een worker blijft de suite anders hangen in plaats van rood te worden, en dat
gebeurde bij de mutatietoets letterlijk. Beide mutaties lieten de juiste toets
omvallen.
Nog niet geprobeerd: praten met de relay. Daarvoor is het adres van de Umbrel
nodig en dat komt van de gebruiker; het gaat niet in deze publieke repo.
Suite: 405 goed, 0 fout over alle acht de toetsen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vandaag is Trezor Suite de enige client, en die vraagt hardware die aan het
toestel kan. Daardoor rusten vier beweringen over deze app op redenering uit de
broncode in plaats van op een proef, waaronder dat blokkeren pas bij de volgende
verbinding werkt. Paragraaf 4c zet die vier op een rij als proeven.
Alles wordt vanuit een scherm bediend, en dat scherm gaat over de client. Aan de
server-app wordt niets gedaan: die draait en synchroniseert met Trezor Suite op
de Mac, bevestigd door de gebruiker op 09-09-2026. De leerstand openzetten en
iemand blokkeren blijft dus op de statuspagina van de app, want de agent-API
hangt achter de inlog van umbrelOS. Dat staat er als feit om te kennen, zodat er
later geen knoppen bij komen die niet kunnen werken.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Relay 0.6.0 draait en synct; de gebruiker haalde de achtergebleven
programmabestanden met de hand uit de app-datamap. Het plan verhuist naar
Docs/Plannen/Archief/Eigenimage/, de eerste in die map. CONTINUE_HERE krijgt
een archiefsectie; Publicatie-Relay wacht niet meer op een te pinnen image,
en in Publicatie-Gate en Images-pinnen.md is het pinnen van vreemde images
geschiedenis. Wat er voor publicatie nog ontbreekt is linux/arm64.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Gebouwd en geduwd op de Umbrel, digest drie keer in de compose. Geen versieverhoging: 0.6.0 is nog nergens geinstalleerd.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Plan Eigenimage, fase 5, op keuze van de gebruiker: een image met de relay
erbij en geen tweede recept. agent.py, nginx.conf en index.html verhuizen
naar tools/evolu-relay/ naast src/; de Dockerfile blijft op node:24-slim en
haalt nginx en python3 uit apt. Drie containers uit een image: de relay als
node via de compose, de agent en nginx als root.
Anders dan alleen verplaatst: user www-data in nginx.conf (Debian heeft geen
gebruiker nginx), geen USER meer in de image, de versie in de kop via
api/status met RELAY_APP_VERSION. VERSION 0.6.0, manifest 0.6.0, drie keer
dezelfde tag in de compose, ongepind tot de eerste push.
Tests mee verhuisd; de vormtest toetst de drie tags tegen VERSION. Niet
gebouwd: er is hier geen Docker.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Gebouwd en geduwd op de Umbrel, digest twee keer in de compose. Geen
versieverhoging: 0.1.0 is nog nergens geinstalleerd.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Plan Eigenimage, fase 1 tot en met 3. De vier templates verhuizen naar
tools/electrum-gate/ zonder extensie; daarnaast Dockerfile (nginx:1.30-alpine
plus python3), entrypoint.sh (het command-blok van de compose, zonder $$) en
build.sh naar het voorbeeld van Evolu Relay. Een image voor beide containers,
gebouwd op de Umbrel; open punt 2 en 3 daarmee beslist.
Inhoudelijk anders dan alleen verplaatst: het log_format staat in stream.conf
zelf, het backend-adres komt via twee plaatshouders zonder dollarteken uit de
omgeving (ook in de server-service), en de pagina haalt versie en adres uit
status.json via GATE_APP_VERSION.
Tests mee verhuisd en uitgebreid: entrypoint.sh en Dockerfile in plaats van het
command-blok, en de tag in de compose gelijk aan VERSION in build.sh voor elke
eigen image. Mutatie-getest met drie ingrepen.
Nog niet gebouwd: er is hier geen Docker. De tag staat ongepind tot de eerste
push; dat is fase 4 en die is van de gebruiker.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Meest recent bovenaan, in beide kaders en over de groepen heen. De rijen
stonden in de volgorde van het bestand, dus van binnenkomst. De volgorde
schuift mee zonder herladen: de ronde van vijf seconden bouwt de lijsten
toch al opnieuw op. Alleen de pagina, dus geen nieuwe image.
Erbij gevonden en als open taak genoteerd: lastSeen wordt alleen bij de
verbinding gezet, niet bij een sync erover.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Op verzoek van de gebruiker, in beide apps. De accentgloed uit Gate 0.0.25 en
Relay 0.5.2 gaat uit; de rand, de schaduw, het randlicht en de doorschijnende
kleur van de vlakken blijven staan.
Het is een schakelaar geworden en geen verwijdering: data-glow="on" op het
html-element zet hem terug, en alleen samen met data-depth="deep". Die tweede
eis is van de gebruiker en hij is juist: de gloed is de onderste van de vier
dieptelagen, dus aanzetten op een vlakke pagina legt een verloop achter vlakken
die er dekkend voor staan.
De blur hangt nu aan de gloed en niet aan de diepte, want een backdrop-filter
op een egale ondergrond levert per definitie niets op. Daarmee verviel het
mobiele terugvalblok (Gate 0.0.26, Relay 0.5.3) volledig: dat zette gloed, blur
en vlakkleur om, en de eerste twee staan nu al uit.
Meegevonden en gerepareerd: een selector met twee attributen wint van de :root
in de prefers-reduced-transparency-query, die daardoor de blur niet meer uit
kreeg. Die query noemt de gloedselector nu letterlijk.
Alle zeven tests groen: 22 + 43 + 39 + 54 + 28 + 115 + 65 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Op verzoek van de gebruiker. Dit is een TLS-voordeur op een Electrum-server;
wat de keten doet staat in elke wallet die hij al heeft. Vier widgets over,
alle vier over deze gateway.
De leeftijd van de meting stond onder de blokhoogte en was daarmee de laatste
plek waar de pagina zei hoe oud zijn gegevens zijn: de voetregel en de badge
die hetzelfde zeiden zijn in augustus weggehaald met precies dat argument. Die
regel staat nu onder de reactietijd, na de sparkline zodat de vier onderregels
op een lijn blijven.
De rij is een raster van vier met breekpunten op 1100 en 560 pixels; vier
deelt door twee, dus de stap die bepaalde welke widget alleen kwam te staan is
vervallen. In de agent is de hoogte uit het antwoord gehaald maar het verzoek
niet: daar wordt de reactietijd uit gemeten.
Alle tests groen: 22 + 43 + 39 + 54 + 28 + 115 + 65 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De melding van de gebruiker was "Not answering" met [Errno 111] Connection refused, terwijl de
gateway van buiten gewoon werkte. Het was een startvolgorde en geen storing:
1. de compose laat `server` ná de agent starten (depends_on: [agent]), want nginx lost
http://agent:8000 bij het starten op en breekt af op een onbekende naam;
2. build_status draait meteen bij het opstarten, vóór de eerste WAKE.wait;
3. de branch die de meting uitstelt hing alleen aan `reloaded`, en die is bij een herstart met een
ongewijzigd certificaat False, dus er werd gemeten;
4. nginx luisterde toen nog niet op 50022;
5. en het bleef staan, want de volgende meting kwam pas na SELF_CHECK_INTERVAL.
Twee reparaties, elk voor een helft. De eerste ronde van een proces meet niet maar zet `pending`
(die toestand heeft geen `at`, dus de ronde daarna meet gewoon), en na een mislukking wordt er na
GATE_SELF_CHECK_RETRY (60s) opnieuw gemeten in plaats van na 300. Een geslaagde meting blijft op
300, want dat is de waarde die zelden verandert en die het activiteitenlog belast.
De fout zat er sinds de zelfcontrole bestaat (27-08-2026) en was alleen binnen vijf minuten na een
herstart te zien. Mutatie-getest: de eerste-rondebranch uitschakelen laat twee tests omvallen, de
snelle herhaling uitschakelen precies één.
Relay: de statuswidget staat nu rechts in de bovenste rij en heet Status in plaats van Relay, gelijk
aan Electrum Gate. De twee pagina's zijn één app store en horen op dezelfde manier te lezen, en dit
is de widget die als enige begrijpelijk is zonder buur. De id's relay-state en relay-sub blijven.
Suite groen: 54 + 28 + 65 + 39 + 43 + 22 + 115.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Twee bijstellingen op de opfrisbeurt van vanochtend, allebei op verzoek van de gebruiker.
"Running" staat weer in de accentkleur. In Evolu Relay hing die tekst aan --pos, en die ging van
oranje naar groen omdat --pos het accent volgde en dat als merkkleur las in plaats van als
betekenis. In Electrum Gate hing hij aan niets en was hij gewoon --text-primary. Beide staan nu op
--accent-text, met een eigen .stat-val.ok: "Running" is de eigen toestand van de app en geen
positief cijfer, en --pos blijft groen voor "het staat in de plus". In Gate wordt die klasse
alleen bij state 'ok' gezet; 'off' en 'pending' zijn niet fout maar ook niet in orde en houden de
gewone tekstkleur.
Op een telefoon valt de pagina terug op de vlakke stand. De gloed is 58rem breed, ongeveer 928
pixels, dus op een telefoonscherm is het beeld smaller dan de gloed zelf en wordt het een egale
waas in plaats van een verloop. De blur gaat in dezelfde stap eruit, en dat is geen extraatje:
doorzichtigheid met niets erachter is gewoon grijs, terwijl een backdrop-filter op een telefoon wel
per frame rekenwerk kost. Rand, schaduw en randlicht blijven staan. Grens 900 pixels.
De selector is html[data-depth] en niet :root, want :root heeft dezelfde specificiteit als de
[data-theme]-blokken en zou dan alleen winnen zolang hij er in het bestand onder staat.
Alleen de pagina's, dus opnieuw geen nieuwe images.
Suite groen: 22 + 43 + 22 + 115 op de geraakte delen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beide pagina's volgen nu HomeGit/Docs/website-design-system.html, in dezelfde ronde als AssetApp.
Drie dingen, en de volgorde is niet willekeurig:
- een accentgloed achter de pagina, uit de linkerbovenhoek. Dit is de VOORWAARDE voor de rest en
niet de finishing touch: een backdrop-filter op een egale ondergrond levert per definitie niets
op, dus er moet eerst iets achter de vlakken staan;
- kaarten doorschijnend, met een randlicht bovenlangs en een schaduw uit een token;
- één hoek voor elk buitenste kader. De kaart van --radius-xl naar --radius-lg, gelijk aan het
logkader, dat zijn geneste hoek daarvan afleidt.
Het volle accentpalet van AssetApp (vijf kleuren, licht en donker) staat erin; beide apps blijven
op oranje en krijgen bewust geen knop. Om dezelfde reden staat de diepte hier vast aan, terwijl het
in AssetApp een instelling is: dit zijn statuspagina's met licht/donker en verder geen bediening.
--pos is groen geworden in plaats van oranje. Hij volgde het accent, en dat las als merkkleur in
plaats van als betekenis; zichtbaar gevolg is dat de badge "Running" nu groen is.
Meegevonden en meteen gerepareerd: prefers-reduced-motion en prefers-reduced-transparency mogen
niet in één media-query. Windows heeft een schakelaar "Animatie-effecten" die bij veel mensen uit
staat en die zet reduced-motion op reduce; samen in één query bleef er van de hele opmaak niets
over. Ze staan apart, en reduced-motion haalt alleen de overgang weg.
Alleen de pagina's, dus geen nieuwe images: VERSION in tools/evolu-relay/build.sh blijft staan en
alleen de manifesten gaan omhoog.
Suite groen: 22 + 43 + 54 + 22 + 65 + 39 + 115.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Alleen documentatie. Op aanwijzing van de gebruiker bij het afsluiten: de suite
meldt bij elke ronde dat python:3-alpine en nginx:alpine niet gepind zijn, en de
verleiding is dat even te doen. Dat is de verkeerde volgorde. Pinnen is een eis van
Publicatie, maar daarvoor gaat de app-inhoud eerst een eigen image in, en dan
bestaan die twee niet meer als de plek waar onze code draait.
De regel staat nu in KNOWLEDGE.md, want vier plannen raken hem en geen van de vier
bezit hem: de eis komt uit Publicatie, de oorzaak zit in Eigenimage, en de taak
stond in Umbrelapp en Appstore. Met twee grenzen erbij, anders slaat het de andere
kant op door: de eigen image pin je wel meteen bij elke verhoging, en de melding in
de suite blijft een afdruk en geen toets, zodat de suite niet rood staat tot
Eigenimage klaar is.
Onderweg bleek Eigenimage PLAN.md 8 achterhaald en misleidend. Daar stond dat het
bouwrecept van Evolu Relay misschien zou vervallen zodra de kale relay de weg werd,
en dat je er daarom niets aan moest verbeteren. Wij bouwen juist een eigen image,
want de twee terugroepfuncties zitten niet in de gepubliceerde. En de paragraaf
onderschatte wat er nog te doen is: ook bij die app staan de agent en de pagina nog
op vreemde images, alleen de relay zelf is klaar. Herschreven, en de kolom App van
dat plan in CONTINUE_HERE staat daarom op "beide" in plaats van op Gate.
Verder de taak in Umbrelapp gemarkeerd als wachtend op Eigenimage in plaats van
open, een verwijzing bovenaan Images-pinnen.md, en de regel voor Umbrelapp in
CONTINUE_HERE ingekort en bijgewerkt naar 0.5.1.
Geen tests gedraaid: er is niets buiten Docs/ geraakt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemeld door de gebruiker binnen een uur na 0.5.0, op de pagina op zijn eigen
Umbrel. "Sent. The relay applies changes within a few seconds." bleef staan tot je
de pagina herlaadde, dus ook lang nadat hij niet meer waar was.
Een ontbrekende tak: de ronde die elke vijf seconden loopt zette de melding wel aan
maar nooit uit. De regel die daaruit volgt en die in het commentaar staat: de
melding hoort van de RONDE te zijn en niet van de klik, want alleen de ronde weet
of hij nog waar is. Hij verdwijnt nu zodra het relay-proces de opdracht heeft
opgepakt, en blijft staan zolang de opdracht in de postbus ligt. Dat is het geval
waarin er iets te melden valt, want normaal duurt dat twee seconden.
Een weigering is de uitzondering en blijft staan tot de volgende opdracht: het is
de enige uitleg die je krijgt van wat er misging, en die mag niet binnen vijf
seconden verdwijnen. Met een vlag en niet door naar de klasse van het element te
kijken, zoals de vorige versie van deze pagina deed; dan hangt gedrag aan een naam
die er ook om opmaakredenen kan staan.
Bijvangst: die weigering stond in de neutrale stijl en is nu rood. Een geweigerde
opdracht in de neutrale stijl leest als een mededeling.
Alleen index.html.template geraakt, dus geen nieuwe image: build.sh blijft op
0.5.0 en het manifest gaat naar 0.5.1. De changelog beweerde sinds diezelfde
ochtend dat die twee nummers gelijk gehouden worden; de regel is dat een hogere
VERSION een hoger manifest vraagt en niet andersom. Rechtgezet.
Beide gedragingen zijn in een browser nagegaan tegen de voorbeeldweergave: de
bevestiging is na zeven seconden verborgen, de weigering staat er dan nog.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De image is op de Umbrel gebouwd en naar het eigen register geduwd, dus de tag
bestaat nu en de digest kan erbij: sha256:1e4dafdc...acea49a.
Bewaard voor de volgende verhoging, want dit is twee keer bijna misgegaan:
- laat de digest er even van af zolang de image niet bestaat. Staan er een tag en
een digest, dan bepaalt de digest wat er gehaald wordt, dus een oude digest onder
een nieuwe tag levert stilzwijgend de oude image. Ongepind faalt hard en
zichtbaar, en dat is hier het gedrag dat je wil;
- doe beide repo-pushes voordat de app in umbrelOS geupdatet wordt. Anders is het
toevoegen van de digest een tweede compose-wijziging en kost het een extra
versienummer, want umbrelOS rolt alleen uit bij een hoger version.
buildx imagetools meldt MediaType manifest.v2+json en dus een enkele architectuur,
geen multi-arch index. Bij bouwen op het apparaat zelf klopt dat per constructie
met de host; arm64 hoort erbij voor de officiele store en staat bij
Publicatie-Relay.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Negen punten uit echt gebruik met 0.4.0, alle negen gedaan. Twee ervan waren
onderzoeksvragen en die staan onderaan.
Evolu Relay 0.5.0
- Een tijdvenster van twee minuten voor nieuwe eigenaars, met een stopknop. De
teller zit in het relay-proces en niet in de pagina: een teller in een tabblad
dat je sluit, sluit de deur niet. policy.js kreeg learningUntil, isLearningOpen
en expireLearning.
- decideOwner kijkt naar isLearningOpen en niet naar het veld learning. De lus die
een verlopen venster opruimt loopt elke twee seconden, en in dat gat zou een
onbekende alsnog binnenkomen.
- Zonder STATE_VERSION te verhogen, met een toets die dat verdedigt: een verhoging
zou de allowlist van de draaiende installatie laten afwijzen en de deur sluiten
voor eigenaars die er al in stonden.
- Labels op een eigenaar-id, in een eigen labels.json met de agent als enige
schrijver. Een label zegt niets over toegang, dus de relay hoeft het niet te
weten; het is daardoor meteen opgeslagen en werkt ook als de relay omligt.
- Geblokkeerde en geweigerde eigenaars in een kader, met een badge die zegt welke
van de twee het is. De badge staat buiten het hover-blok, anders is dat
onderscheid onzichtbaar tenzij je over de regel gaat.
- Maatvoering gelijk aan Electrum Gate: 1760px, hetzelfde raster, icoon van 64
pixels, dezelfde kop, versienummer erachter. Uitleg uit de kaders, knoppen pas
bij hover, geen voetregel.
Electrum Gate 0.0.24
- Menu-item "About this app", in beide apps.
- De statuswidget zei "Answering" met "answered in 7 ms, from inside the app" en
zegt nu "Running" met de meting eronder. De nuance dat de controle van container
naar container loopt is verplaatst naar een eigen kopje in die dialoog, waar er
ruimte voor is; vier woorden waren te weinig.
Toetsen en gereedschap
- tests/test_relay_agent.py (nieuw, 65 toetsen) en tests/test_paginas_parsen.mjs
(nieuw). Muteertests gedraaid op de beslissende regels.
- Een dollarteken-toets in test_appstore_vorm.py. Het commentaar in drie bestanden
beweerde al dat die test bestond; nu is dat waar.
- Een toets dat er geen werkbestanden in een app-map staan. umbreld kopieert de
hele map naar het apparaat en in de back-up.
- tools/voorbeeldpagina.mjs maakt van een *.template een pagina die je in een
browser kunt openen. Dat vond meteen twee echte opmaakfouten.
De twee onderzoeksvragen
- Een geweigerde eigenaar komt niet in de database: isOwnerAllowed zit in de
WebSocket-upgrade, dus het is een 401 en een gesloten socket. Het gewenste gevolg
treedt wel op, via de client: die is local-first en levert bij toelating de hele
geschiedenis. Blokkeren werkt daarentegen pas bij de volgende verbinding, en dat
staat als open punt.
- De blobs zijn niet met een xpub te ontcijferen; een OwnerId komt daar niet uit.
Met de SLIP-21-node van het apparaat kan het wel, maar die geeft volledige
zeggenschap, dus dat hoort niet in een relay. Als plan-punt opgenomen bij de tool
in HomeGit/Trezor.
Nog niet uitgerold: de image 0.5.0 moet gebouwd en geduwd worden. De digest staat
daarom niet in de compose, want een oude digest onder een nieuwe tag levert stil de
oude relay.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De gebruiker gaat er eerst mee werken en komt dan met wat er beter moet. Tot die
lijst er is, is dit geen werk: de pagina doet wat hij moet doen, en een gevoel is
geen taak.
Met de volgorde erbij, want die is niet vrijblijvend: verbeteren gaat voor het in
een image stoppen. Zolang de pagina een template is, bereikt elke wijziging een
installatie met een push en een versieverhoging; in een image kost elke tweak een
bouw, een push naar het register en een nieuwe digest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Getest met een tweede gebruikersaccount op dezelfde Mac, en dat is schoner dan een
tweede apparaat: die installatie begint met een lege lokale Evolu-database, dus
alles wat daar verschijnt kan alleen van de relay komen. De labels kwamen door, en
een wijziging aan die kant komt ook weer terug. Beide richtingen dus, met bewijs.
Daarmee staat er wat dit plan beloofde: een tweede app in deze store,
geinstalleerd op de Umbrel, met Trezor Suite die erop synchroniseert. Het restwerk
is klein en wacht nergens op: een herstart van de app overleven, twee images
pinnen, en data per eigenaar kunnen wissen.
Prioriteitsherziening die daarbij hoort. Umbrelapp zakt van A naar B. Eigenimage
gaat naar A, want dat lag alleen stil omdat de gebruiker eerst Evolu Relay wilde
afmaken; het is hernummerd naar 004 zodat de bovenkant van de reeks weer op
tier-orde staat. Proefopstelling zakt naar B en is klaar voor het archief: alle
vragen die het bezat zijn hier beantwoord, en de rest gaat over een pakket dat niet
meer bestaat.
De takenlijst is opgeschoond van regels die over het oude pakket gingen: de
Postgres-pin, de schemavraag, het adres op 3851 en de twee blokkades. In plaats
daarvan staan de twee images die nu nog ongepind zijn. En de controle of deze app
Electrum Gate raakt is afgevinkt met wat er werkelijk gebeurde: dat deed hij, via
een gedeelde containernaam, en dat is gerepareerd.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rechtgezet op aanwijzing van de gebruiker; ik had aangenomen dat overal hetzelfde
veld gebruikt was. Het maakt de conclusie sterker in plaats van zwakker: op iOS is
juist de ondersteunde weg genomen en er gebeurde nog steeds niets, dus valt de
verklaring 'verkeerd veld' af en blijft die uit open punt 9 over.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nagetrokken op hun documentatiepagina's nadat op iOS niets bleek te werken. Drie
feiten die dit pakket raken, en ze staan verspreid over pagina's die elkaar niet
noemen.
Een eigen relay is bij Trezor een gedocumenteerde functie: "Custom server" staat
gewoon in de interface, met een invoerveld voor je eigen adres, ook op mobiel. Wat
wij verpakken is dus een ondersteund gebruikspatroon en geen omweg. Let op dat dat
iets anders is dan het dev-utils-veld waarmee wij getest hebben.
Suite Sync werkt op Safe 3, 5 en 7 en vraagt altijd een bevestiging op het
apparaat, ook op mobiel. En op iOS werkt alleen de Safe 7, want die verbindt over
Bluetooth terwijl de andere modellen USB gebruiken en dat ondersteunt iOS niet.
De combinatie van die twee wordt nergens genoemd, en dat is precies waar deze
store een dag aan kwijt was: de Suite Sync-pagina beschrijft de mobiele stappen
alsof ze op elk toestel werken. Er bestaat een forumdraad over verwarring rond
apparaatcompatibiliteit, maar die is zonder inloggen niet te lezen, dus wat daar
staat is niet bevestigd.
Tot slot een getal dat het verschil laat zien: hun eigen dienst kapt af op 1 MB,
ongeveer 2500 bewerkingen per apparaat, waarna de rest lokaal blijft. Dat is een
totaal en het is wat hun quota-manager bewaakt. Een zelf-gehoste relay kent die
grens niet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De controle op een aangesloten apparaat zit in de client en niet in de relay, dus
het ontbreken van synchronisatie op die iPhone staat los van waar de relay draait.
Dat is de zin die vandaag het verschil maakt tussen een teleurstelling en een
grens van het platform, en hij hoort in het open punt te staan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
De app draait als 0.3.0 en wordt gebruikt: kale relay met een eigen
eigenaars-allowlist, statuspagina achter de umbrelOS-inlog, en TLS via Zoraxy op
een eigen subdomein waar de handshake 101 geeft. De desktop synchroniseert
eroverheen, met een geleerde eigenaar en een gesloten deur erna.
iOS blijft open, en het vermoeden van vanmiddag is weerlegd in plaats van
bevestigd: TLS was niet de verklaring. Met een geldig certificaat, een opgeslagen
URL en de sync-schakelaar aan komt er nog steeds niets aan, en sinds 0.3.0 is dat
hard gemeten in plaats van afgeleid: het relay-proces logt elke eigenaar die zich
meldt, ook bekende en geweigerde, en van de telefoon verschijnt niets. Daarmee is
de hele app vrijgepleit. De volgende stap staat als eerste taak en kost een
minuut: kijken of het verzoek de telefoon uberhaupt verlaat, via het log van
Zoraxy.
Doordat iOS niet meedoet is de leeskant nooit gemeten. Dat is de tweede taak en
hij hangt aan de eerste, want iOS zou die tweede client zijn.
Proefopstelling is hiermee volledig ingehaald: beide vragen die dat plan nog
bezat zijn beantwoord, en wat er verder in stond gaat over een pakket dat niet
meer bestaat. Dat staat als een beslissing in de index, niet als een daad.
De reparatie aan Electrum Gate heeft een eigen entry gekregen in het plan
Webinterface, want die app ging kapot door de tweede app en dat hoort daar
nagelezen te kunnen worden.
Tests: alle vier groen (34, 54, 39 en 61 goed, 0 fout).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De tag stond er al, de digest kon pas toen de image geduwd was. Zonder digest
draait er iets anders dan hier staat zodra dezelfde tag opnieuw geduwd wordt.
Tests: test_appstore_vorm 34 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nagelezen in de broncode van Suite nadat er op de eigen relay tot verrassing twee
eigenaars verschenen. De eigenaar wordt op de Trezor zelf afgeleid, via
trezorConnect.evoluGetNode met een proof of delegated identity, en Suite bewaart
hem per device state. Een wachtwoordzin geeft een andere state.
Twee installaties met dezelfde Trezor en dezelfde wallet komen dus op dezelfde
OwnerId uit; dat is juist wat synchroniseren tussen apparaten mogelijk maakt. Meer
dan een OwnerId betekent meer dan een wallet, niet meer dan een app.
Dat is bepalend voor een relay met een allowlist: het aantal eigenaars dat je
toelaat is het aantal wallets dat je synchroniseert. Het maakt ook voorspelbaar
wat er bij de iOS-test hoort te gebeuren: dezelfde wallet levert een OwnerId op
die al toegelaten is, dus daar hoeft de leerstand niet voor open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drie dingen die vandaag misgingen of ontbraken, en die alle drie uit gebruik
kwamen en niet uit nadenken.
De allowlist logde niets als een bekende eigenaar terugkwam en niets als er een
geweigerd werd. Daardoor stond er een tweede eigenaar drieentwintig keer aan de
deur zonder dat het log er iets over zei; het stond alleen op de pagina. Nu is er
een regel per eigenaar per keer dat het proces draait, dus ook bij terugkomst en
bij weigering, met een bovengrens omdat een weigering een id bevat dat de ander
zelf verzint. Een geweigerde schrijfactie logt voortaan hoeveel bytes er gevraagd
werden en welke grens gold, met de naam van de variabele erbij.
Allow gooide de geschiedenis weg. Een eigenaar die je alsnog toeliet kreeg "first
seen" op het moment van de klik, terwijl hij al twintig minuten stond te
kloppen. Juist daar wil je zien sinds wanneer. Met een toets erop.
En de knoppen stonden niet recht: id, gegevens en knoppen stonden naast elkaar,
dus de lengte van de gegevensregel bepaalde of de rij afbrak. Een eigenaar met
een last seen duwde zijn knoppen naar de volgende regel en dus naar links.
Nu staan naam en gegevens onder elkaar in een kolom en worden de knoppen altijd
naar rechts geduwd.
Inhoudelijk het belangrijkste: "de eerste eigenaar wint" is te smal. Een enkele
app kan meer dan een eigenaar gebruiken, en de pagina adviseerde de deur te
sluiten zodra de eerste binnen was. Daarmee sluit je je eigen tweede eigenaar
buiten. De tekst zegt nu te wachten tot er een minuut niets nieuws meer bij komt.
Image naar 0.3.0. De digest van 0.2.0 is uit de compose gehaald in plaats van
blijven staan: die zou naar de vorige image wijzen terwijl de tag iets anders
belooft.
Tests: alle vier groen (34, 54, 39 en 61 goed, 0 fout).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De hele keten is gemeten: de knop Close schreef een opdracht, de agent legde hem
in de postbus, het relay-proces paste hem toe en schreef hem weg, en de pagina las
de nieuwe toestand terug. De leerstand staat op closed en de geleerde eigenaar
staat in de lijst met eerste en laatste verschijning. Dat was het laatste stuk van
dit pakket dat nog nooit gelopen had.
Wat daarbij opviel: de uitleg onder de schakelaar bleef de open toestand
beschrijven terwijl hij dicht stond. Hij volgt nu de toestand, met een derde tekst
voor het geval de relay nog niets gemeld heeft.
Versie naar 0.2.2. De vorige stond mogelijk al geinstalleerd, en zonder verhoging
bereikt een gewijzigde template geen bestaande installatie.
Tests: test_appstore_vorm 34 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Op verzoek van de gebruiker is dit geen app meer over de labels van een bepaalde
wallet, maar wat het technisch al was: een relay voor apps die op Evolu gebouwd
zijn. De tagline, de beschrijving, de releaseNotes en de statuspagina noemen geen
enkele client meer, en category gaat van bitcoin naar files, waar de officiele
store ook synchronisatie tussen apparaten onderbrengt.
De tekst leunt op wat Evolu zelf schrijft en niet op een verzinsel: local-first,
end-to-end versleuteld voordat het je apparaat verlaat, en een relay die alleen
een owner id, tijdstempels en gevulde blobs ziet. Daar staat expliciet bij wat
zelf hosten wel en niet verandert, want geheimer wordt de data er niet van; wie de
versleutelde kopie bewaart en wie kan zien dat je synchroniseert wel.
De tegenwerping is niet weerlegd maar geaccepteerd, en dat staat als zodanig in
open punt 7: "Evolu Relay" zegt een Umbrel-gebruiker niets, terwijl de labels van
een bekende wallet een concrete reden zijn om te installeren. Vindbaarheid
inleveren is hier een keuze. Blijkt het te knellen, dan is daar terug te lezen
waarom.
In het Nederlandse codecommentaar blijft de historische toelichting staan, want
die legt uit waarom de relay van Trezor eruit is gegaan. Alleen de regels die de
app beschrijven zijn generiek gemaakt.
Tests: test_appstore_vorm 34 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Alle apps van umbrelOS delen een Docker-netwerk, dus een servicenaam als 'agent'
is daar niet uniek. Electrum Gate heeft er een op poort 8000 en Evolu Relay sinds
vandaag ook, en Docker verdeelde de naam netjes over allebei. Gemeten op het
apparaat: van tien verzoeken vanuit de nginx-container kwamen er vijf bij de
verkeerde app uit, met een 404 tot gevolg. Op de statuspagina zag dat eruit als
een status die wisselde tussen "running" en "agent unreachable".
Dit raakte twee apps, en de tweede is de vervelende: de pagina van Electrum Gate
proxyde ook naar http://agent:8000 en werkte alleen omdat die app tot vandaag de
enige met die naam was. Het installeren van Evolu Relay heeft die pagina dus
kapotgemaakt. Beide gaan nu naar <app-id>_agent_1, en beide manifesten gaan
omhoog, want zonder verhoging bereikt een gewijzigde template geen bestaande
installatie.
Dezelfde les stond al in de compose van Electrum Gate, over de servicenaam
'server', en die is bij het schrijven van de nginx-config genegeerd. Daarom nu een
toets erop: test_appstore_vorm controleert voor elke app dat een proxy_pass en
elke *_HOST-variabele een naam gebruiken die met het app-id begint. Muteertest
gedaan, de toets viel om op precies de korte naam.
Bijgewerkt in build.sh: VERSION daar is het etiket op de image, en `version` in
het manifest is een ander nummer dat erop vooruit mag lopen. Ze lopen uiteen zodra
er een reparatie in de app-map zit zonder dat de image wijzigt, en dat is nu het
geval.
Tests: alle vier groen (34, 54, 39 en 60 goed, 0 fout).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Losgedraaid uit het register, buiten de app om. Het log meldde "learned a new
owner", en in /app/data stonden daarna evolu-relay.db van 49152 bytes en
owners.json van 241 bytes. Die eerste omvang is exact die van de proef van
vanochtend, dus dezelfde elf labels zijn geland.
Daarmee is de hele keten gemeten in plaats van aangenomen: isOwnerAllowed wordt
aangeroepen met iets wat ons beleid als eigenaar herkent, de leerstand doet wat
hij moet doen, en de allowlist gaat naar schijf en overleeft dus een herstart. Dat
was het onzekerste deel van het pakket.
Onze image declareert geen VOLUME waar die van Evolu dat wel doet. Dat is een
bewuste keuze, want de compose bind-mount de map zelf en een gedeclareerd volume
levert dan zwerfvolumes op. Gevolg bij een losse proef zonder -v: docker inspect
toont geen mounts, en docker diff werkt hier juist wel.
Terzijde, want het leek een storing: Suite meldt bij een nieuwe migratie "0 labels
migrated successfully, 11 skipped". Uit hun eigen teksten blijkt dat alleen
ontbrekende labels worden gekopieerd, dus skipped betekent "stond er al".
Nog ongetest: de pagina en de agent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De app-map is niet langer de relay van Trezor met een Postgres en een
quota-manager ernaast, maar de relay van Evolu met onze eigen allowlist eromheen.
Drie containers werden relay, agent en nginx; het wachtwoord en de database zijn
verdwenen.
De poorten zijn omgedraaid en dat is de kern. Tot 0.0.2 hing de relay achter
app_proxy en moest de inlog van umbrelOS dus uit, waardoor een statuspagina net zo
onbeschermd zou zijn als de relay zelf. Nu hangt de pagina daar met de inlog aan,
en publiceert de relay zijn eigen poort 3852 waar Zoraxy met TLS naartoe wijst.
Dat is hetzelfde patroon als Electrum Gate met 50022. Niet 4000 op de host, want
dat is een veelgebruikte poort en een botsing merk je pas als de app niet start.
De agent beslist niets: hij leest wat het relay-proces heeft opgeschreven en legt
opdrachten in een postbus die de relay zelf leegmaakt. Twee processen die in
dezelfde allowlist schrijven is een wedloop die je een keer per jaar treft en dan
niet kunt reproduceren. Hij weigert ook een tweede opdracht zolang de vorige er
nog ligt, want overschrijven zou er stil een laten verdwijnen.
De pagina volgt het ontwerpsysteem van Electrum Gate, zonder de Google
Fonts-verwijzing daaruit: een app op een Umbrel hoort niet te wachten op een
lettertype van buiten. Alles is met stringoptelling geschreven en zonder enig
dollarteken, want umbreld haalt elke template door envsubst en zou een
JavaScript-template-literal stilzwijgend leegmaken.
De image is door de gebruiker gebouwd en geduwd; de compose is gepind op tag plus
digest. Manifest naar 0.2.0, met een beschrijving en releaseNotes die kloppen met
wat er nu draait in plaats van met het vorige pakket.
Wat hier NIET mee bewezen is, en dat is meer dan gebruikelijk: de agent is alleen
op syntaxis gecontroleerd, de pagina is nooit gerenderd, en of een opdracht van de
pagina daadwerkelijk bij het relay-proces aankomt is niet gemeten. Dat kan alleen
op het apparaat en staat als taak.
Tests: alle vier groen (32, 54, 39 en 60 goed, 0 fout).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Het bestand is van de gebruiker; hier komt alleen de manifestregel erbij. De
verwijzing wijst naar de rauwe versie in deze repo, dezelfde constructie als bij
Electrum Gate, en hij staat als laatste regel van het manifest zodat hij bij
inlevering in de officiele store in een keer te schrappen is.
Geen versieverhoging: de app is vandaag van de Umbrel gehaald en wordt in fase 5
opnieuw gebouwd, dus er is geen installatie om iets naartoe te rollen. Het nummer
gaat mee omhoog als de compose omgaat.
Tests: test_appstore_vorm 32 goed, 0 fout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tools/evolu-relay/src/ bevat nu een eigen programma dat createRelay uit
@evolu/nodejs aanroept met de twee terugroepfuncties die het bedoelde
uitbreidpunt vormen. De relay zelf komt uit npm en wordt niet nagebouwd of
aangepast; de opstartvolgorde is overgenomen uit apps/relay/src/index.ts van
Evolu zelf.
De opzet is drie bestanden met een harde scheiding, en die scheiding is de reden
dat hier iets te testen valt. policy.js bevat het beleid als pure functies: geen
bestanden, geen netwerk, geen klok. store.js is de enige plek met schijf erin.
index.js doet niets anders dan lezen, doorgeven en opslaan.
Het beleid: de eerste eigenaar die zich meldt wordt geleerd, een schakelaar
bepaalt of er nog nieuwe bij mogen, en een eigenaar is te blokkeren, alsnog toe
te laten of te vergeten. Geweigerde pogingen worden onthouden voor de pagina,
afgekapt op twintig, want elke poging is een id dat de ander zelf verzint. Een
onleesbaar owners.json wordt opzij geschoven en de app gaat dan dicht in plaats
van open: we weten dan niet wie er toegelaten was, en met de leerstand aan zou de
eerstvolgende die verbindt de nieuwe eigenaar worden.
Met test: node tests/test_limiter.mjs, 60 toetsen, en de toetsen gaan over de
guards en niet over het gelukkige pad. De beslissende regel is muteertest gedaan
en de juiste toets viel om: een geblokkeerde eigenaar mag er niet alsnog in
doordat de leerstand aanstaat. Het bestand is .mjs omdat de repo-root geen
package.json heeft en een .js daar als CommonJS gelezen zou worden.
build.sh bouwt niet langer de repo van Trezor maar onze eigen Dockerfile, dus git
is er niet meer voor nodig en de pin zit nu in package.json. De image is
node:24-slim en niet alpine, want better-sqlite3 heeft binaries voor glibc en niet
voor musl. Er is nog geen package-lock.json; het script waarschuwt daarvoor en het
staat als taak.
Onderweg bleek een aanname van vanmiddag fout: de 1 MB uit de gepubliceerde image
geldt per schrijfactie en niet per eigenaar. Er valt dus geen labelgeschiedenis
tegenaan te lopen. Dat is rechtgezet in het plan en in de naslag, en het getal is
overgenomen als bewuste keuze met RELAY_MAX_WRITE_BYTES ernaast.
Wat er niet in zit en ook niet gegokt is: data per eigenaar wissen. Het beleid kan
een eigenaar vergeten, maar zijn berichten staan in de SQLite van de relay, en dat
is andermans schema.
Tests: alle vier groen (32, 54, 39 en 60 goed, 0 fout).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
createRelay uit @evolu/nodejs neemt twee terugroepfuncties, isOwnerAllowed en
isOwnerWithinQuota, en Trezor doet in createEvoluRelay.ts zelf niets anders. Hun
hele quota-manager met Postgres bestaat alleen om de tabel te vullen die die twee
raadplegen. Wij vullen ze met eigen logica en bouwen niets na. Weg 1 uit
Bereikbaarheid 4b is daarmee veel goedkoper dan daar aangenomen, en dat is wat de
keuze van de gebruiker mogelijk maakt.
De logica zoals hij hem formuleerde: de eerste eigenaar die zich meldt wint, een
schakelaar bepaalt of er nog nieuwe bij mogen, en data is per eigenaar te wissen.
Dat laatste doet het relay-proces zelf, aangestuurd met een vlagbestand vanaf de
pagina; geen tweede container die langszij in de SQLite schrijft en geen
Docker-socket.
Twee feiten uit de broncode van Evolu die het ontwerp sturen en die in de naslag
staan met bron. De gepubliceerde image zet isOwnerWithinQuota op 1 MB per eigenaar
en laat isOwnerAllowed weg, dus een kale relay is niet volledig ongelimiteerd,
maar dat plafond geldt ook voor de echte gebruiker. En de relay-URL van de client
bevat een pad dat letterlijk wordt overgenomen, wat een goedkope proxy-controle
mogelijk maakt; die is bewust niet genomen nu de allowlist er komt.
De poorten gaan om: pagina achter app_proxy met de inlog aan, relay op een eigen
gepubliceerde poort waar Zoraxy met TLS naartoe wijst. Dat lost open punt 2 op
zonder het bezwaar dat daar stond, en het volgt het patroon dat Electrum Gate in
deze repo al gebruikt. De pagina volgt hetzelfde ontwerpsysteem, zonder de Google
Fonts-verwijzing eruit.
Open punt 8 en 2 zijn beslist, fase 5 staat als takenlijst. De gebruiker heeft de
oude installatie van de Umbrel gehaald; er wordt niet geupdatet maar opnieuw
gebouwd.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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 en
de tijdstempel verzette. De protocolversie klopt dus, en daarmee is de richting
van 27-08 geen verwachting meer maar een meting. Geen Postgres, geen
quota-manager, geen eigenaarsregistratie, en toch verkeer.
Open punt 6 is daarmee beslist. Het blijft in de lijst staan tot de verbouwing
gedaan is, want het beschrijft de reden waarom het huidige pakket eruit gaat.
Een waarschuwing hoort erbij en staat in het protocol: de relay logt geen enkele
verbinding. Het venster blijft stil terwijl er labels binnenkomen, dus "ik zie
niets gebeuren" is hier geen waarneming maar een eigenschap van de relay. Alleen
het volume vertelt iets, en daarom mag de nulmeting niet overgeslagen worden. Dat
kostte vandaag bijna de verkeerde conclusie.
Twee dingen bleven ongemeten en staan als taak. De leeskant: er is geen tweede
client geweest, dus dat een ander apparaat de labels terugkrijgt is niet gezien.
En iOS maakt geen enkele verbinding, terwijl het veld daar bestaat, valideert op
http(s) en zijn waarde onthoudt. Het vermoeden is TLS, en dat is als open punt 9
opgeschreven met de prijs erbij: een certificaat voor een LAN-adres bestaat niet,
dus de wegen die overblijven lopen via Bereikbaarheid en zijn een eigen
ontwerpvraag. Er is ook een tweede verklaring die even goed past, namelijk dat
het synchroniseren op de telefoon nooit begon, en die is gratis te meten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
