Files

T

HarmenandClaude Opus 5 fafea732f9 De relay was al die tijd in orde, de client belde nooit

Het testprotocol voor de kale Evolu-relay staat nu uitgeschreven in PLAN.md §6a,
met de stappen, hoe je een geslaagde van een mislukte uitslag onderscheidt, en de
valkuil dat een label in Suite niets bewijst omdat Evolu eerst lokaal schrijft.

De hoofdvraag is niet beantwoord: er is geen enkele client tot een verbinding
gekomen, dus over de protocolversie weten we nog niets. Wat de serverkant betreft
is er niets te repareren. De relay haalt, start, maakt zijn eigen SQLite-database
aan, en de WebSocket-handshake slaagt zowel op de Umbrel zelf als vanaf een Mac
elders op het netwerk.

Drie meetinstrumenten gaven een vals negatief en zijn onderweg gecorrigeerd, want
alle drie wezen ze een probleem aan dat er niet was. docker diff kijkt niet in een
volume, en /app/data is er een. Een browser of gewone curl krijgt van deze
WS-server niets terug, want hij negeert een verzoek zonder upgrade-headers; dat
ziet er identiek uit aan een dode poort. En healthy komt uit een healthcheck die
alleen een TCP-verbinding opent, dus die zegt niets over werking. Dat laatste is
opgeschreven als eis voor de compose als deze image in het pakket komt.

iOS is voor deze proef afgevallen. Het veld voor de relay-URL bestaat daar, het
valideert op http(s) en onthoudt zijn waarde na een geforceerde afsluiting, maar
de app doet geen enkele verbindingspoging. Of dat aan het platform ligt of aan de
bevestiging op het apparaat is van buitenaf niet te scheiden, dus het wordt een
eigen vraag: anders sluiten we twee onbekenden tegelijk uit. De proef verhuist
naar de desktop-Suite op de Mac.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-28 10:38:33 +02:00

9.0 KiB

Raw Blame History

Taken - Umbrelapp

App: Evolu Relay. Prioriteit: A | Afhankelijk van: –

Actief sinds 25-08-2026. Gepromoveerd uit Masterplannen/ omdat de gebruiker besloot het pakket meteen te maken. De afhankelijkheid op Proefopstelling is daarmee geen blokkade meer maar een parallelle bron: fase 1 daarvan is af en leverde de feiten waarop dit pakket rust. Wat er nog uit moet komen zijn twee vragen die pas bij het installeren pijn doen, en die staan hieronder als eigen taak.

Dit is de focus vanaf 27-08-2026, op verzoek van de gebruiker. Het werk aan Electrum Gate is die dag afgerond tot en met de tweede indeling; het plan Eigenimage staat klaar maar ligt bewust stil. Twee feiten om mee te beginnen: de app staat op dit moment uit op de Umbrel, en hij is nog nooit met Trezor Suite verbonden geweest. "Gebouwd" is hier dus nog verder van "werkend" dan bij Gate.

Volgende stap

De kále Evolu-relay proberen, en waarschijnlijk daarnaartoe verbouwen. Zie OPEN.md punt 6: uit de broncode van Suite blijkt dat de cliënt bij een eigen relay-URL géén eigenaar registreert, terwijl Trezor's relay iedereen zonder limietenrij weigert. Het pakket dat er nu staat kan dus in de kern niet werken. Wat nog te meten is, is of de protocolversie klopt. Het testprotocol staat uitgeschreven in PLAN.md §6a, inclusief hoe je een geslaagde van een mislukte uitslag onderscheidt en welke valkuil daarbij hoort. Eigenaar: gebruiker
```
Stand op 28-08-2026: **de relay is in orde en de cliënt kwam nooit aan.** Image gehaald
(`sha256:dbbe0ca1…`), draait, maakt zijn database zelf aan, en de handshake slaagt vanaf de Umbrel én
vanaf een Mac op het netwerk. Op iOS gebeurt er niets: het veld bestaat en onthoudt zijn waarde, maar
de app belt niet. **Volgende poging: desktop-Suite op de Mac**, die aantoonbaar bij de relay kan. Zie
PLAN.md §6a, "Wat er op 28-08-2026 gemeten is"
```

Pas daarna beslissen wat er met het huidige pakket gebeurt. Werkt de kale relay, dan wordt dit één container op een gepubliceerde image en vervallen de Postgres en het wachtwoord. Werkt hij niet, dan is de limietenrij met de hand zetten de enige weg vooruit

**De richting is al gekozen op 27-08-2026: kaal, met een eigen limiter erop en de statuspagina
erbij.** Zie [OPEN.md](OPEN.md) punt 6, 8 en 2. Wat daarbij vastligt en makkelijk verkeerd onthouden
wordt: de kale relay heeft géén toegangscontrole, dus de limiter is geen extraatje maar de vervanging
van de enige bescherming die er vandaag is. En de quota-manager die er nu in zit is daarvoor niet te
hergebruiken: die schrijft in Trezor's limietentabel, en die tabel bestaat straks niet meer

**Een eigen image blijft daardoor waarschijnlijk nodig**, want de meest voor de hand liggende limiter
breidt de relay uit via `createRelay`. Dat is geen obstakel: de gebruiker meldde op 27-08-2026 dat de
broncode nog op zijn Umbrel staat, dus opnieuw bouwen en naar het eigen Gitea-register duwen kan
gewoon. De bouwstap en het register vervallen dus mogelijk tóch niet; de Postgres en het wachtwoord
wel

De limiter kiezen uit de drie wegen van Bereikbaarheid §4b, met de leer-variant erbij: de eerste eigenaar die verbindt wordt toegelaten, de rest geweigerd, met een wisknop op de statuspagina. Zie OPEN.md punt 8. Pas nadat de proef geslaagd is
In de logs van de relay kijken of het databaseschema zichzelf aanmaakt. Alleen nog nuttig als het huidige pakket blijft: sudo docker logs whatsnext-evolu-relay_relay_1

Fase 1 - De app-map

whatsnext-evolu-relay/ aangemaakt met umbrel-app.yml en docker-compose.yml (25-08-2026). Mapnaam gelijk aan het id, met het store-voorvoegsel whatsnext-, en de manifestvelden in de voorgeschreven volgorde
data/postgres/.gitkeep erin, zodat de mount bij de eerste start niet als root wordt aangemaakt
dependencies weggelaten en niet leeg gezet. Deze app hangt van geen enkele andere app af; een leeg veld zou suggereren dat er iets te kiezen valt
Een eigen icoon. Er staat nu géén icon in het manifest, dus de tegel blijft naamloos in de store. Bewust leeg: een geleend of verkeerd icoon is erger dan geen. Eigenaar: gebruiker

Fase 2 - De compose

app_proxy met PROXY_AUTH_ADD: "false", en geen eigen ports:. Trezor Suite is geen browser met een sessiecookie. Dit is het patroon van de eigen nostr-relay-app van Umbrel, dus een precedent en geen omweg; zie PLAN.md §4c
Relay en quota-manager uit één image met een ander command. Expliciet en niet leunend op de CMD van de Dockerfile, want daar staat yarn start met bovenstrooms zelf een twijfel erbij
De quota-manager gaat mee. Niet omdat de relay hem aanroept, maar omdat de relay elke eigenaar zonder limietenrij weigert en dit is wat die rijen maakt
Postgres onder ${APP_DATA_DIR}/data/postgres, wachtwoord uit ${APP_PASSWORD}, PGDATA op een submap, en postgres:17-alpine in plaats van postgres kaal
Healthcheck op de eigen database en gebruiker, niet op -d postgres zoals bovenstrooms: die database bestaat hier niet, en dan is de controle groen op het verkeerde antwoord
De eigen image gepind op tag plus digest (25-08-2026). sc.kamenier-hamer.nl/sysop/evolu-relay:c03a204@sha256:2fe1e9e9…, op beide services. Dat moest wel: zie fase 4. Let op dat dit één architectuur is (amd64), want er is alleen amd64 geduwd. Voor de officiele store hoort er een multi-arch index-digest met arm64 in; dat staat bij Publicatie-Relay
postgres:17-alpine pinnen op de multi-arch index-digest. Kan meteen, met docker buildx imagetools inspect, en het is het laatste ongepinde in deze app. Staat als TODO in de compose

Fase 3 - Het bouwrecept

tools/evolu-relay/build.sh (25-08-2026). Haalt de broncode op een vastgezette commit en bouwt de Dockerfile van Trezor. Niet hun bouwstappen nabouwen; wat wij toevoegen is de pin
Niet in de app-map gezet, en dat is geen netheid. Een Dockerfile staat niet in de update-whitelist, dus bouwen-in-de-app zou elke nieuwe versie een herinstallatie kosten. Zie PLAN.md §4f
Onder tools/ en niet onder build/: dat laatste staat in .gitignore als bouwselmap, dus het recept zou stilzwijgend buiten de repo blijven. Gevonden bij het stagen, niet bij het schrijven
Het script controleert na het ophalen dat de commit is wat hij verwachtte, en faalt hard als dat niet zo is. Zonder die regel bouwt het stil de verkeerde toestand

Fase 4 - Installeren en verifiëren op de Umbrel

Niets hiervan is op een laptop te doen. Eigenaar van deze hele fase: gebruiker.

De image gebouwd op de Umbrel (25-08-2026), in 50 seconden. Twee dingen die het opleverde: de gebruiker umbrel zit hier níet in de groep docker, dus het moet met sudo; en de Dockerfile van Trezor bouwt zonder aanpassing
In een register gezet, want anders kan umbreld er niet bij (25-08-2026). Dit was de grote verrassing van de dag en het staat met bron in Umbrel-appstore-spec.md: umbreld haalt élke image via de Docker Engine API op, niet via compose. Een lokaal gebouwde tag is dus onbereikbaar en pull_policy: never doet niets, want de compose wordt niet gelezen om te pullen. Het Gitea-register op dezelfde server als de store bleek de kortste weg, en anoniem halen werkt daar
De app geïnstalleerd en alle drie de containers blijven draaien (25-08-2026). relay, quota-manager en db, met db op healthy en de app-proxy op 3851. De lokale images waren vooraf weggehaald, dus de pull uit het register is echt gedaan en het hele pad is bewezen: broncode → bouwrecept → register → gepinde digest → installatie
Gecontroleerd of het databaseschema zichzelf aanmaakt. Niet uitgezocht, en dit is de eerste plek waar het misgaat als het antwoord nee is. Kijk in de logs van de relay-container
Trezor Suite naar <umbrel>:3851 laten wijzen en een label synchroniseren. Dit is de enige controle die telt, en hij kan mislukken op de eigenaarsregistratie zonder dat er iets mis is met het pakket
De app gestopt en gestart, en de database heeft het overleefd
Gecontroleerd dat het toevoegen van deze app Electrum Gate niet raakt

Geblokkeerd / wacht op

Hoe registreer je een eigenaar bij de quota-manager? Zonder antwoord kan er niet gesynchroniseerd worden, ook al draait alles. Wacht op Proefopstelling fase 1; begin bij bruno-collection/ in de bovenstroomse repo
Accepteert Trezor Suite dit adres, en in welke vorm? Wacht op Proefopstelling, "Volgende stap". Als het antwoord nee is, is dit pakket zonder waarde

9.0 KiB Raw Blame History Unescape Escape