# Open punten - Umbrelapp

> Beslissingen die nog een **eigenaar** of een **moment** nodig hebben. Staat een punt hier zonder allebei,
> dan is dat de eerste fout om op te lossen. Wordt een punt een taak, dan verhuist het naar
> [TAKEN.md](TAKEN.md).
>
> **Nummers blijven staan**, ook als een punt beslist is: er kan elders naar verwezen worden, ook vanuit
> codecommentaar. Beslissen betekent verplaatsen naar de kop hieronder, niet hernummeren.

## Nog te beslissen

6. **Pakketteren we wel de juiste relay?** - **de zwaarste vraag die dit plan heeft**, en hij kwam pas op
   25-08-2026 aan het eind van de dag boven, nadat de gebruiker de documentatie van Evolu zelf aandroeg.

   `trezor/trezor-suite-sync` is niet Evolu maar Trezor's inzet ervan, met een Postgres en een
   quota-manager voor hún gehoste dienst. Het project eronder, `evoluhq/evolu`, heeft een eigen relay: één
   container, een **gepubliceerde** image `docker.io/evoluhq/relay:latest`, een datavolume in plaats van een
   database, en niets gedocumenteerd over toegangscontrole. Zie
   [Upstream-evolu-relay.md](../../../Referenties/Upstream-evolu-relay.md) §0.

   Werkt Trezor Suite daarmee, dan vervalt zowat alles waar dit pakket moeilijk van doet: de bouwstap, het
   eigen register, de onderhoudsplicht op een image, de Postgres met zijn wachtwoord, en de
   eigenaarsregistratie die nu de blokkade is. Drie containers worden er één.

   **Nog diezelfde avond grotendeels beantwoord uit de cliëntkant**, nadat de gebruiker erop wees dat de
   broncode van Trezor Suite lokaal staat in een ander project. Uit een commentaarregel van Trezor zelf:
   *"We only want to use QM for our own relay servers. In case custom URL has been set, QM is ignored."*

   Daarmee draait de vraag om. **Met een eigen relay-URL registreert Suite geen eigenaar**, en Trezor's relay
   weigert iedereen zonder limietenrij. Die rij komt er dus nooit. Niet de kale Evolu-relay is de gok, maar
   het pakket dat er nu staat: **Trezor's relay is als zelf-gehoste relay in de kern onbruikbaar** tenzij je
   die rij met de hand zet.

   Wat er nog écht open is, is één ding en dat is geen redenering maar een proef: **klopt de
   protocolversie?** Suite gebruikt `@evolu/web@3.0.0-next.1` met een eigen patch in `.yarn/patches/`, en
   `docker.io/evoluhq/relay:latest` hoeft daar niet bij te passen.

   **Meten en niet redeneren:** `docker run --rm -p 4000:4000 docker.io/evoluhq/relay:latest`, Suite
   ernaartoe wijzen, label maken. De instellingen staan onder **dev-utils** en `http://` volstaat; zie
   [Upstream-evolu-relay.md](../../../Referenties/Upstream-evolu-relay.md) §0 en §7.
   **Moment:** eerste taak van de volgende sessie, vóór er nog iets aan het huidige pakket verbeterd wordt ·
   **Eigenaar:** gebruiker

5. **Is de app bruikbaar voor iemand anders die deze store toevoegt?**
   Nieuw op 25-08-2026, en het is de keerzijde van punt 1. De store is publiek, dus een vreemde kan hem
   toevoegen en Evolu Relay installeren. Zijn Umbrel haalt de image dan uit
   `sc.kamenier-hamer.nl` van de gebruiker. Dat gaat vandaag waarschijnlijk gewoon werken, en dat is
   precies wat het een keuze maakt in plaats van een detail: je serveert dan images van je eigen server aan
   onbekenden, en jouw uptime bepaalt of hun app installeert. Electrum Gate heeft dit niet, want die draait
   op images uit Docker Hub.

   Drie richtingen: laten zoals het is; `disabled: true` in het manifest zolang de image niet op een neutrale
   plek staat (dat veld bestaat in het schema); of de image naar Docker Hub duwen en het probleem weghalen.
   **Moment:** als fase 4 helemaal af is, dus als bewezen is dat er iets te delen valt · **Eigenaar:**
   gebruiker

2. **Komt er een statuspagina?**
   Electrum Gate heeft er een en die bleek in de praktijk het nuttigste deel van die app. Hier zou dat
   kunnen: draait de relay, hoe groot is de database, wanneer was de laatste synchronisatie, en is er een
   eigenaar geregistreerd. Dat laatste is meer dan gemak, want het is precies waar het stil kan misgaan.

   Ertegen: het is een eigen container en een eigen onderhoudslast, en het is geen voorwaarde om te kunnen
   synchroniseren. Ervoor, en dat is nieuw sinds de samenvoeging van de repo's: de pagina en de agent van
   Electrum Gate staan in dezelfde repo en zijn grotendeels over te nemen.

   Let op één ding als het ervan komt: de app-proxy staat op `PROXY_AUTH_ADD: "false"`, dus een pagina zou
   net zo onbeschermd zijn als de relay. Bij Electrum Gate zit de pagina juist wél achter de inlog. Dat
   vraagt dan een tweede poort of een smalle whitelist.

   **En dat weegt zwaarder dan het leek, want er zijn twee wegen naar binnen en de tweede is onzichtbaar
   in de compose** (vastgesteld op 25-08-2026, nadat de gebruiker vroeg of deze app kwaad kon):

   - **het thuisnetwerk.** De app-proxy publiceert `0.0.0.0:3851`, dus alle interfaces en niet alleen
     localhost. Alles op het LAN kan bij de relay, zonder aanmelding;
   - **Tor.** umbrelOS maakt per app een hidden service, en die stond bij de eerste installatie gewoon aan.
     Zonder inlog betekent dat **bereikbaar vanaf het internet**, alleen beschermd doordat het
     `.onion`-adres onraadbaar is. Te zien aan `~/umbrel/tor/data/app-<app-id>/hostname` en uit te zetten
     in umbrelOS. De gebruiker zet hem uit.

   Wat de schade in beide gevallen beperkt is een applicatiecontrole en geen netwerkgrens: de relay weigert
   elke eigenaar zonder limietenrij. Dat is precies waarom een statuspagina hier een andere afweging is dan
   bij Electrum Gate: die zou achter geen van beide grenzen liggen, en een statuspagina vertelt per definitie
   iets over de machine waarop hij draait.
   **Moment:** pas overwegen als fase 4 geslaagd is · **Eigenaar:** gebruiker

3. **Wat doen we met de quota-manager als blijkt dat hij iets extern nodig heeft?**
   Hij is meegepakketteerd omdat de relay zonder limietenrij niemand toelaat. Als het registreren van een
   eigenaar een betaalprovider of een Notion-sleutel vraagt, klopt die keuze niet meer en wordt de tweede
   weg uit [PLAN.md](PLAN.md) §4b weer actueel: de rij met de hand in de database zetten.
   **Moment:** zodra **Proefopstelling** de registratievraag beantwoordt · **Eigenaar:** volgt uit dat plan

7. **Hoe positioneren we de app als het de generieke Evolu-relay wordt?**
   Opgemerkt door de gebruiker op 25-08-2026, meteen na punt 6: verpakken we niet langer iets van Trezor maar
   een relay van Evolu, dan hoeft de app-tekst niet meer over Trezor te gaan.

   **Meevaller die dat goedkoop maakt:** de identiteit is al generiek. `id: whatsnext-evolu-relay` en
   `name: Evolu Relay` kunnen blijven staan, en dat is niet niks, want een id-wijziging is voor umbrelOS een
   andere app en dus een herinstallatie. Wat Trezor-specifiek is, is alleen de framing: `tagline`,
   `description` en `category: bitcoin`.

   Wat er verder mee vervalt: de licentievraag uit
   [Upstream-evolu-relay.md](../../../Referenties/Upstream-evolu-relay.md) §4. Bij een gepubliceerde image
   distribueren we niets van Trezor en bouwen we niets; er is geen `LICENSE.md` meer om je zorgen over te
   maken. En **Publicatie-Relay** wordt een stuk plausibeler: een gepubliceerde upstream-image die je pint,
   in plaats van een eigen image die je moet onderhouden.

   **De tegenwerping hoort er wel bij, want breder is niet vanzelf beter.** "Evolu Relay" zegt een
   Umbrel-gebruiker niets; "synchroniseer je Trezor Suite-labels via je eigen machine" is een reden om te
   installeren. Wie hiernaar zoekt, zoekt op Trezor. Het voorstel is dus niet Trezor weglaten maar de
   volgorde omdraaien: de concrete reden voorop, en erachter dat elke Evolu-app hem kan gebruiken. Dan
   verlies je de vindbaarheid niet en beweer je ook niet dat dit een Trezor-product is.

   Blijft over: `category`. `bitcoin` klopt bij de Trezor-lezing en niet bij de generieke. Voor de
   vindbaarheid pleit `bitcoin` alsnog, want daar kijkt het publiek dat hier iets aan heeft.
   **Moment:** zodra punt 6 gemeten is, en pas dan; bij een negatieve uitslag blijft de huidige tekst juist ·
   **Eigenaar:** gebruiker

## Beslist

1. **Waar komt de image te staan?** - **het ingebouwde containerregister van de eigen Gitea**
   (25-08-2026), als `sc.kamenier-hamer.nl/sysop/evolu-relay`.

   Hier stond dat lokaal bouwen de eerste stap was en dat dit beslist zou worden "zodra lokaal niet meer
   volstaat". Dat moment kwam dezelfde dag, en niet uit vrije keuze: **lokaal volstaat nooit.** umbreld haalt
   élke image via de Docker Engine API op en niet via compose, dus een lokaal gebouwde tag is onbereikbaar en
   de installatie faalt met `pull access denied` voordat er iets start. Met bron in
   [Umbrel-appstore-spec.md](../../../Referenties/Umbrel-appstore-spec.md).

   Waarom Gitea en niet Docker Hub: zelfde host als de store, geldig certificaat, geen nieuw account, en de
   eigenaar `sysop` staat publiek zodat anoniem halen werkt. Dat laatste is gecontroleerd met een uitgelogde
   pull, en daarna bewezen door de installatie zelf met de lokale images vooraf weggehaald.

   Wat hiermee **niet** beslist is: Docker Hub blijft nodig zodra het de officiële store in gaat, en dan moet
   er ook arm64 bij. Zie **Publicatie-Relay**. En lees dan eerst `LICENSE.md` van Trezor, dat door GitHub als
   "other" geclassificeerd staat.

## Bewust uitgesteld

4. **`SERVER_ENV` op `prod` of `dev`?** - `prod`, tot het tegendeel gemeten is (25-08-2026).
   `.env.sample` zegt dat prod authenticatie aanzet; in de code die gelezen is bepaalt die vlag alleen het
   logniveau en staan de autorisatiecontroles onvoorwaardelijk aan. Eén van de twee is achterhaald.

   `prod` is de veilige kant van die onduidelijkheid: als het iets aanzet, willen we dat het aanstaat. Maar
   het is een gok tot het gemeten is, en het is met één keer starten te meten. Staat als taak in
   **Proefopstelling** fase 2.
   **Moment:** bij de eerste geslaagde start · **Eigenaar:** volgt uit Proefopstelling