UmbrelApps/Docs/Plannen/Actief/008-Umbrelapp/OPEN.md

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.

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 §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 §0 en §7.

   Richting gekozen door de gebruiker op 27-08-2026: we gaan voor de kale relay, met een eigen limiter erop en de statuspagina uit punt 2. Zijn woorden: "dat wordt beter."

   Dat is een richting en nog geen besluit, want de proef hierboven is niet gedaan. Klopt de protocolversie niet, dan valt de hele richting weg en blijft alleen de weg over waarin de limietenrij met de hand gezet wordt. De proef blijft dus de eerste taak, en er wordt niets verbouwd voordat hij geslaagd is.

   Wat de richting wél nu al vastlegt, zodat het niet opnieuw uitgezocht hoeft te worden:

   • de drie dingen horen bij elkaar en zijn geen wensenlijstje. De kale relay heeft géén toegangscontrole, en dat is bij Evolu geen omissie maar het ontwerp. Vandaag is het enige dat de schade beperkt juist een applicatiecontrole: Trezor's relay weigert elke eigenaar zonder limietenrij (zie punt 2). Gaan we kaal, dan verdwijnt precies die bescherming, en wordt de limiter van "leuk" naar "voorwaarde". Het instinct om ze in één adem te noemen klopt dus;
   • de statuspagina krijgt er een taak bij. Hij toont niet alleen of het werkt, hij is ook de plek waar je ziet wélke eigenaar is toegelaten en waar de knop zit om die keuze te wissen. Zie punt 8;
   • een eigen image is geen blokkade. 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. Dat is relevant omdat de limiter dat waarschijnlijk vraagt; zie punt 8.

   Moment: de proef is de eerste taak van de volgende sessie, vóór er iets verbouwd wordt · Eigenaar: gebruiker

7. Welke limiter komt er op de kale relay? Nieuw op 27-08-2026, uit de richting in punt 6. Dit is de vraag die met "kaal gaan" meekomt en die je niet kunt uitstellen tot na de verbouwing, want hij bepaalt of er een eigen image nodig blijft.

   Wat het níet kan zijn: de quota-manager die er nu in zit. Die schrijft rijen in de limietentabel van Trezor's schema, en de kale relay heeft dat schema niet, geen Postgres, en geen begrip van eigenaars. Wat er komt is dus nieuw werk en geen hergebruik.

   De drie wegen staan in het masterplan Bereikbaarheid §4b en verschillen sterk in prijs:

   1. de relay uitbreiden via createRelay uit @evolu/nodejs. Dat is het bedoelde uitbreidpunt en vrijwel zeker wat Trezor gedaan heeft. Prijs: een eigen kleine dienst schrijven en onderhouden, en weer een eigen image bouwen;
   2. terug naar Trezor's relay met een eigen interface die de limietenrij zet. Schrijven in andermans schema, dus breekbaar bovenstrooms, plus de Postgres terug;
   3. geen allowlist maar het netwerk: Tailscale of een IP-beperking. Kost geen regel code, maar beperkt wie er mag verbinden en niet welke eigenaar mag schrijven.

   De spanning die hierbij hoort, eerlijk opgeschreven: weg 1 haalt een deel van de winst van kaal gaan weer weg, want de bouwstap en het eigen register komen terug. Wat er dan nog steeds overblijft is aanzienlijk: geen Postgres, geen wachtwoord, geen onderhoud aan andermans schema, en een relay die bovenstrooms gewoon meebeweegt. De gebruiker heeft dat op 27-08-2026 al ondervangen: de broncode staat nog op zijn Umbrel, dus opnieuw bouwen en naar het eigen register duwen is geen nieuw obstakel.

   Eén detail dat weg 1 en 2 lastiger maakt dan ze klinken, en de uitweg erbij: je moet je eigen OwnerId kennen om hem te kunnen toelaten, en Suite toont die waarschijnlijk nergens. De uitweg uit §4b is de allowlist niet te laten typen maar te laten leren: de eerste eigenaar die verbindt wordt toegelaten, de rest geweigerd, met een knop om die keuze te wissen. Dat vraagt geen interface om een id in te tikken, en het is precies genoeg voor één huishouden. Die knop hoort dan op de statuspagina uit punt 2, en dat is meteen het argument dat die pagina meer is dan gemak. Moment: zodra de proef uit punt 6 geslaagd is · Eigenaar: gebruiker beslist, met een voorstel vanuit de sessie

8. 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

9. 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.

   De gebruiker wil hem, gezegd op 27-08-2026 in één adem met de kale relay en de limiter. Twee dingen die dat verandert. De pagina krijgt een taak die verder gaat dan status: hij toont welke eigenaar toegelaten is en draagt de knop om die keuze te wissen (punt 8). En de afweging hierboven wordt scherper, niet milder: de zin "wat de schade beperkt is een applicatiecontrole" gaat niet meer op zodra de relay kaal is, want die controle is dan juist weg. Een pagina zonder inlog is dan het enige wat er nog bij staat. De tweede poort of de smalle whitelist is daarmee geen detail maar onderdeel van het ontwerp. Moment: samen met de limiter uit punt 8, dus nadat de proef uit punt 6 geslaagd is · Eigenaar: gebruiker

10. 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 §4b weer actueel: de rij met de hand in de database zetten. Moment: zodra Proefopstelling de registratievraag beantwoordt · Eigenaar: volgt uit dat plan

11. 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 §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.

   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