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>
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>
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>
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>
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>
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 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>
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>
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>
De gebruiker vroeg of Evolu Relay kwaad kan op zijn Umbrel. Het eerlijke antwoord
was nee met twee kanttekeningen, en de tweede stond in geen enkel bestand:
umbrelOS maakt per app een Tor hidden service en die stond gewoon aan. Samen 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.
Wat dit lastig maakt om te zien: het staat niet in de compose van de app. Je kunt
dat bestand volledig lezen en concluderen dat alleen je LAN erbij kan. Vandaar dat
het nu op drie plekken staat: in de compose bij de instelling waar de afweging
gemaakt wordt, in het plan bij de statuspagina-vraag, en in de naslag.
De naslag is de belangrijkste van die drie, want het mechanisme is een eigenschap
van umbrelOS en geldt voor elke app. Het gevolg niet: bij Electrum Gate legt
dezelfde hidden service alleen de inlogpagina bloot, want daar staat de
proxy-inlog aan en loopt de TLS-poort niet via de proxy. Die vergelijking staat er
als tabel bij, want de instelling alleen zegt niets; het is de combinatie.
Opgemerkt door de gebruiker dat het ook voor Electrum Gate zou gelden. Deels
terecht, en dat is precies waarom het in de gedeelde naslag hoort en niet in het
plan van één app.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
umbreld haalt elke image via de Docker Engine API op, dus een lokaal gebouwde tag
is voor hem onbereikbaar. De image staat nu in het Gitea-register op dezelfde
server als deze store, en anoniem halen werkt daar: dat is dezelfde voorwaarde
als voor het klonen van de store zelf, en de eigenaar sysop staat publiek.
Beide services krijgen tag plus digest. De digest hoort erbij en niet alleen de
tag, want een tag kan opnieuw geduwd worden en dan draait er iets anders dan er
in de repo staat. De toets in tests/test_appstore_vorm.py drukt de pinstatus af
en beide regels staan nu op "gepind"; van Electrum Gate nog geen.
Wat er expres bij staat in commentaar: dit is de digest van één architectuur.
Er is alleen amd64 geduwd, want deze Umbrel is amd64. Voor de officiele store
moet het een multi-arch index-digest zijn met arm64 erin, en dat is buildx met
QEMU. Zonder die notitie leest een gepinde digest als "eis gehaald".
build.sh wijst nu ook naar het register, anders levert een volgende bouw weer een
tag op waar de compose niet naar kijkt. De slotregels van het script zijn geen
suggestie meer maar de resterende stappen: push, digest overnemen, version
verhogen, en anoniem controleren met een uitgelogde pull in dezelfde context als
de login.
Manifest naar 0.0.2, met release notes die zeggen waarom: 0.0.1 was niet te
installeren.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De installatie faalde, en de foutmelding was voorspelbaar maar de oorzaak niet:
pull access denied for whatsnext/evolu-relay
at /opt/umbreld/node_modules/docker-modem/lib/modem.js:382:17
Die stacktrace is het punt. De pull komt uit docker-modem, de Docker-client van
umbreld zelf, dus rechtstreeks op de Docker Engine API. Compose komt er niet aan
te pas en de compose wordt alleen gelezen om te zien welke images erin staan.
pull_policy is een sleutel van de Compose-specificatie en wordt dus nooit
bekeken. Mijn reparatie van de vorige commit kon per definitie niet werken; hij
is eruit, want een sleutel die niets doet met een commentaar dat beweert van wel
is erger dan geen sleutel.
Waar die fout vandaan kwam: ik las in app-script dat install een
`compose "${app}" pull` doet en nam aan dat dat het pad was. Dat bestand is de
legacy-compat-laag en niet wat umbrelOS 1.x loopt bij een installatie vanuit de
interface. Dat staat nu als waarschuwing in de naslag, want het is precies het
soort bron dat overtuigend leest en het verkeerde antwoord geeft.
De echte regel, nu op het apparaat vastgesteld in plaats van uit code afgeleid:
elke image in de compose van een app moet anoniem uit een register te halen zijn.
Een lokaal gebouwde tag werkt niet, hoe goed docker compose up er ook mee overweg
zou kunnen.
Het image-veld staat er nog en wijst nog steeds naar de lokale tag. Dat is
bewust: het commentaar erboven zegt nu dat het zo niet werkt en wat er moet
komen. Weghalen zou de app-map stiller maar niet beter maken, en de keuze voor
een register is aan de gebruiker.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De image is gebouwd op de Umbrel en staat alleen in de lokale Docker-opslag: er
is geen register. Dat leek te werken omdat `docker compose up` niets ophaalt zolang
de image lokaal bestaat. Bij het nakijken van app-script in umbreld bleek dat niet
het pad dat een installatie loopt.
umbreld draait `compose "${app}" pull` bij install, bij update en bij
post-patch-update. Die zou whatsnext/evolu-relay:c03a204 op Docker Hub zoeken,
waar hij niet bestaat, en dan faalt de installatie voordat er iets gestart is. Met
pull_policy: never slaat compose die twee services over bij het ophalen. Postgres
houdt de standaard, want die komt wél uit een register.
Bijkomend voordeel dat het houdt zodra er ooit een register is: ontbreekt de image,
dan is de fout "niet gevonden" en die wijst naar de overgeslagen bouwstap, in plaats
van een mislukte netwerkpoging die naar het register wijst.
Uit hetzelfde bestand meegenomen naar de naslag: starten gaat met
`up --detach --build`, dus umbreld zou een build:-blok wél uitvoeren. Toch blijft
bouwen-in-de-app een slecht idee, en nu met een tweede reden naast de whitelist: de
installatie hangt dan tijdens het bouwen. Op deze machine duurde dat 50 seconden.
Geen versieverhoging: deze app is nog nooit geïnstalleerd, dus er is geen manifest
op een apparaat om tegen te vergelijken.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
De gebruiker koos ervoor het pakket meteen te maken en een installatie te
proberen, met de image lokaal gebouwd en het recept in de repo. Dit is dat
pakket. Er is nog niets gebouwd en niets geinstalleerd; "gebouwd" is hier
nadrukkelijk niet "werkend".
De zwaarste ontwerpvraag is met een precedent beslecht en niet met een gok.
Trezor Suite is geen browser met een sessiecookie en kan dus niet achter de inlog
van umbrelOS; het was onduidelijk of PROXY_AUTH_ADD "false" dan verantwoord is of
een omweg. De eigen nostr-relay-app van Umbrel doet exact hetzelfde, om precies
dezelfde reden, en heeft ook geen eigen ports:. De prijs staat in de compose en in
het plan: wie die poort bereikt, bereikt de relay. Wat de schade beperkt is dat de
relay elke eigenaar zonder limietenrij weigert.
Daarom gaat de quota-manager mee, en dat is geen restje van Trezor's betaalde
hosting: hij is wat die rijen aanmaakt. Relay en quota-manager komen uit dezelfde
image met een ander command, want bovenstrooms is het een codebase met meerdere
startscripts. Het command staat expliciet en leunt niet op de CMD van de
Dockerfile, waar yarn start staat met bovenstrooms zelf een twijfel erbij.
Het bouwrecept staat in tools/ en niet in de app-map. Dat is geen netheid: een
Dockerfile staat niet in de update-whitelist, dus bouwen-in-de-app zou elke
nieuwe versie een deinstallatie plus herinstallatie kosten. Onder tools/ en niet
onder build/, want dat laatste staat in .gitignore als bouwselmap en het recept
zou stilzwijgend buiten de repo zijn gebleven. Dat kwam pas bij git status aan het
licht.
De poort is 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.
Nieuw testbestand test_appstore_vorm.py, en het gaat over de store en niet over
een 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, en git diff was daarna leeg.
Umbrelapp is gepromoveerd naar Actief als 008, tussen Proefopstelling en
Appstore, en het masterplan is naar het archief. Wat er in de plannen als open
blijft staan is niet klein: of Trezor Suite dit adres accepteert, of het
databaseschema zichzelf aanmaakt, en hoe je een eigenaar registreert.
Tests: 32 goed 0 fout, 39 goed 0 fout en 54 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
