# Publicatie-Relay - masterplan > **App: Evolu Relay.** Er is ook een **Publicatie-Gate**; inleveren bij de officiële store is per app en > de twee plannen delen alleen de eisen, niet het werk. > > Status: nog niet actief, en dit is het plan dat het langst mag wachten. Bij promotie naar > `Plannen/Actief/NNN-Publicatie-Relay/` worden de paragrafen hieronder over de vier bestanden verdeeld; > zie `HomeGit/Docs/Werkproces.md` §1b. > > Afhankelijk van: **Umbrelapp**. De afhankelijkheid "een image die te pinnen valt" is op 08-09-2026 > vervallen: sinds **Eigenimage** draait de hele app op één eigen, gepinde image. Wat aan §4 punt 1 nog > ontbreekt is `linux/arm64`; `build.sh` heeft er een schakelaar voor die nog nooit geprobeerd is. ## 1. Doel De app inleveren in de officiële Umbrel-appstore, zodat er niet eerst een store-URL geplakt hoeft te worden. Dat verandert de maatstaf: niet "hij werkt hier" maar "iemand anders keurt het pakket goed", tegen eisen die niet van ons zijn. Het vooronderzoek noemde dit als keuze tussen een eigen store en de officiële. Die keuze is er niet echt: je begint sowieso met een eigen store, want anders valt er niets te testen. De vraag is alleen of je daarna inlevert. ## 2. Afbakening Alles wat er tussen een werkend pakket in een eigen store en een aanvaarde bijdrage aan `getumbrel/umbrel-apps` zit. Het pakket zelf is het masterplan **Umbrelapp**. ## 3. Niet-doelen - **Geen functionaliteit erbij om de app aantrekkelijker te maken.** Wat er niet in zit omdat we het niet nodig hebben, hoeft er niet in omdat een winkelpagina er beter van wordt. - **Geen afstemming met Trezor**, tenzij een reviewer erom vraagt. Zie open punt 3. ## 4. Ontwerp De eisen staan niet in de README van `umbrel-apps` maar in de skill-documentatie waar die naar verwijst. Ze zijn uitgeschreven, met bron per regel, in [Umbrel-appstore-spec.md](../../Referenties/Umbrel-appstore-spec.md). Wat daarvan hier het zwaarst weegt: 1. **Elke image gepind als `repo:versie@sha256:`, met `linux/amd64` én `linux/arm64`.** Dit is de eis waar dit plan op kan stranden, en het is geen kwestie van uitvoeren: hij vraagt dat de image überhaupt in een registry bestaat, voor beide architecturen. Publiceert Trezor er geen, dan bouw en publiceer je zelf, en dan lever je een pakket in dat naar je eigen image wijst. Dat is een doorlopende verplichting en een reviewer zal ernaar vragen. 2. **Een kaal app-id, dus zonder store-voorvoegsel.** Dat betekent voor de gebruiker één keer opnieuw installeren, want voor umbrelOS is een ander id een andere app. 3. **`icon` weglaten en `gallery` leeg**, en dat kan pas op het moment van inleveren: zolang het een eigen store is, moet het icoon er juist in. Zet `icon` daarom als laatste regel van het manifest, dan is dat één verwijdering. 4. **Drie tot vijf schermafbeeldingen**, 1440 bij 900 in PNG, of gewone schermafbeeldingen waarna het store-team de opmaak doet. 5. **De inlog van umbrelOS aan laten staan.** Dit is voor deze app geen formaliteit maar de kern van het risico; zie §5. ## 5. Het risico dat niet in een checklist staat Electrum Gate heeft er één, een leesmount in de map van een andere app. Dit pakket heeft er ook één, en een andere: **de relay moet bereikbaar zijn voor een cliënt die geen umbrelOS-sessie heeft.** De inlevereisen zeggen dat de inlog aan moet blijven en dat een `PROXY_AUTH_WHITELIST` alleen smal mag zijn, en alleen voor paden die geen cookie kunnen sturen. Of dat hier lukt, hangt volledig af van hoe de relay zelf authenticeert. Doet hij dat niet, dan lever je een pakket in met een open eindpunt, en dan is dit geen presentatiekwestie meer maar een ontwerpkwestie. Dat is de reden dat dit plan achter **Umbrelapp** staat en niet ernaast: het antwoord komt daarvandaan, en zonder dat antwoord is inleveren zinloos. Wat wél in ons voordeel werkt: deze app leest niets buiten zijn eigen map, heeft geen Docker-socket, geen privileged container en geen afhankelijkheid van een andere app. Dat is een schoner pakket dan Electrum Gate. ## 6. Het werk in grote lijnen **Fase 1 - de harde eisen halen.** Images pinnen, app-id kaal maken, manifestvelden in de voorgeschreven volgorde. Uitkomst: een pakket dat op de checklist niets meer rood heeft. **Fase 2 - de presentatie.** Schermafbeeldingen met plaatsvervangende gegevens, en een `description` die zegt waarom dit bestaat en niet wat het technisch is. **Fase 3 - de vraag vóór de PR.** Het punt uit §5 voorleggen als issue in `umbrel-apps`. Een issue kost minder dan een afgewezen PR. **Fase 4 - inleveren en de review doorlopen.** ## 7. Open punten 1. **Willen we dit eigenlijk?** Een eigen store werkt en kost niets. Inleveren betekent een pakket onderhouden voor onbekende gebruikers, en als de image van onszelf is, betekent het ook die onderhouden. Dit is een echte keuze en geen vanzelfsprekend eindpunt. **Moment:** als **Umbrelapp** af is en de app een tijd gedraaid heeft · **Eigenaar:** gebruiker 2. **Als de image zelf gebouwd moet worden, waar komt hij te staan?** En wie verhoogt hem als Trezor een nieuwe versie uitbrengt? **Moment:** valt samen met punt 1 · **Eigenaar:** gebruiker 3. **Afstemmen met Trezor?** Een reviewer kan vragen of Trezor hierachter staat, omdat het hun software is en hun naam op de tegel. **Moment:** fase 3 · **Eigenaar:** gebruiker ## 8. Verificatie Deze is anders dan bij de andere plannen: het bewijs is de aanvaarde PR. Wat er vóór die tijd te controleren valt, is dat elke regel van de checklist in §4 met een commando of een bestand te staven is, en dat de app na het kaal maken van het app-id nog steeds vanaf nul installeert.