Commit Graph
13 Commits
Author SHA1 Message Date
HarmenandClaude Opus 5 3f7da42388 Testclient: gedeelde afhankelijkheden, en zicht op de WebSocket
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>
2026-09-09 14:15:09 +02:00
HarmenandClaude Opus 5 f0809a80c2 Testclient fase 2, 3 en 5: opdrachtregel, bedieningsvlak en toetsen
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>
2026-09-09 13:39:47 +02:00
HarmenandClaude Opus 5 de955b607d Testclient fase 1: er is geen Evolu-client voor Node, dus die stellen we samen
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>
2026-09-09 12:59:55 +02:00
HarmenandClaude Fable 5.1 a694a9cbd1 Relay 0.6.0: alles in een image, de app-map is leeg
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>
2026-09-08 16:36:30 +02:00
HarmenandClaude Fable 5.1 973b24a23f Gate 0.1.0: eigen image, het command-blok is een script, de app-map is leeg
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>
2026-09-07 20:20:42 +02:00
HarmenandClaude Opus 5 5ee21b10e7 Gate 0.0.27: de statuskaart loog na elke herstart. Relay 0.5.4: Status naar rechts
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>
2026-08-31 12:14:37 +02:00
HarmenandClaude Opus 5 b3b1881af2 De pagina van Evolu Relay op de lijst van de gebruiker
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>
2026-08-30 12:26:56 +02:00
HarmenandClaude Opus 5 c57197637f Wat de eerste echte gebruiksdag opleverde: logging, geschiedenis, uitlijning
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>
2026-08-28 12:08:19 +02:00
HarmenandClaude Opus 5 2b17f79181 De korte containernaam 'agent' wees naar de verkeerde app
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>
2026-08-28 11:41:58 +02:00
HarmenandClaude Opus 5 89aa06639b Het relay-programma: de relay van Evolu met onze eigen allowlist
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>
2026-08-28 11:12:41 +02:00
HarmenandClaude Opus 5 c8d9765cb3 De app kijkt naar zijn eigen voordeur, en meet minder dan het plan beloofde
Open punt 5 van Webinterface, goedgekeurd en gebouwd. De agent verbindt met de
eigen TLS-poort, maakt de handdruk af en vergelijkt het getoonde certificaat
byte voor byte met het gekozen bestand.

Die vergelijking blijkt waardevoller dan de handdruk. Ze vangt een
certificaatwissel die nginx nooit heeft toegepast, en dat is precies het geval
waar een controle op vertrouwen blind voor is. Er wordt daarom bewust niet tegen
de certificaatwinkel van het besturingssysteem geverifieerd: een zelfondertekend
certificaat uploaden is een ondersteunde bron en die opstelling zou dan als kapot
gemeld worden.

Twee dingen liepen anders dan het plan zei en staan nu rechtgezet in PLAN 4a2,
OPEN punt 5 en de changelog. De belofte "luisteren, certificaat en doorverbinding
in een keer" klopt voor twee van de drie: na de handdruk wordt er niets
verstuurd. Een echt verzoek zou de sessie bytes geven, en sessies met bytes
worden nooit uit het activiteitenlog gefilterd, want die kunnen een storing zijn.

En dat filteren was de tweede verrassing. Elke meting is voor nginx een gewone
sessie en levert dus een logregel op; zonder rem ging het log over onszelf in
plaats van over wallets. Er zit nu een rem van vijf minuten op, er wordt niet
gemeten vlak na een herlading omdat het vorige certificaat er dan nog staat, en
de eigen regels worden weggelaten op grond van het moment.

Tests: 22 nieuw, met de nadruk op de niet-gelukkige paden en op de rem, want dat
is wat het log bruikbaar houdt. Alle vier de beslissende regels mutatie-getest.
De changelog kreeg ook de ontbrekende 0.0.15 erbij.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:24:24 +02:00
HarmenandClaude Opus 5 b2e9c8fc7a Evolu Relay als tweede app in de store, plus het bouwrecept
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>
2026-08-25 17:18:22 +02:00
HarmenandClaude Opus 5 67ed9b603b Eén app store, twee apps
umbrelOS leest per store één repo, dus twee apps in twee repo's kan niet. Deze
repo is de store en bevat vanaf nu Electrum Gate en het werk aan Evolu Relay.
Opgezet als verse repo op verzoek van de gebruiker: de historie van ElectrumTLS
en van EvoluRelay komt niet mee.

Dat heeft één gevolg dat verder gaat dan opruimen. In de historie van
ElectrumTLS staat het domein van de gebruiker en het certificaatpad, van vóór de
opschoning van 19-08. Die komt hier niet in. Zolang die repo op de Git-server
blijft staan verandert dat niets, dus het weghalen ervan is het laatste stuk van
open punt 3 van het plan Appstore, en geen bijzaak.

De store zelf hoefde niet te veranderen: store-id whatsnext, en dus blijft het
app-id whatsnext-electrum-gate. Dat hangt aan het store-id en niet aan de URL,
dus voor umbrelOS is dit dezelfde app in een andere store. Dat de store op 19-08
naar de maker genoemd werd in plaats van naar deze ene app, betaalt zich hier
uit.

Wat de documentatie betreft is dit één wortel voor beide apps, en dat was de
reden om samen te voegen en niet de prijs ervan: de appstore-spec, het pinnen
van images en de werkwijze golden al voor allebei en stonden in twee repo's naast
elkaar. De kruisverwijzing die daarvoor nodig was (Referenties/Umbrel-appstore.md
in de oude EvoluRelay-repo) is verdwenen; wat daarin stond over de plekken waar
de relay een ander geval is, staat nu als ontwerp in het masterplan Umbrelapp §4.

Botsende namen kregen een achtervoegsel met de app, en alleen die: Publicatie
werd Publicatie-Gate en Publicatie-Relay, CHANGELOG.md werd
CHANGELOG-electrum-gate.md. Proefopstelling kreeg 007, tussen de twee bestaande
nummers, zodat de bovenkant van de reeks op tier-orde blijft staan.
CONTINUE_HERE.md heeft een kolom App, maar de tiers lopen over beide apps heen:
er is één volgorde van werken.

Electrum Gate gaat naar 0.0.15, want website, repo, support, submission en icon
wijzen nu naar UmbrelApps en zonder versieverhoging rolt dat niet uit. De release
notes leggen aan de gebruiker uit dat hij de store opnieuw moet toevoegen. Of een
geïnstalleerde app een wisseling van store-URL overleeft is nog steeds niet
uitgezocht; dat blijkt bij het omzetten.

Twee dingen in de plannen van Electrum Gate waren door deze verhuizing niet meer
waar en zijn bijgewerkt: de taak "de repo hernoemen" in fase 7 is afgevinkt, en
de repo-vorm in PLAN.md §4a toonde nog de store-id electrumtls, die al sinds
fase 7 achterhaald was.

Tests: 39 goed 0 fout en 54 goed 0 fout, niets overgeslagen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 16:27:57 +02:00