5ee21b10e7feba027199dd6438b05e2685711c25
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 HarmenandClaude Opus 5
|
d24e26dfa5 |
Evolu Relay 0.5.0 gepind op de geduwde digest
De image is op de Umbrel gebouwd en naar het eigen register geduwd, dus de tag bestaat nu en de digest kan erbij: sha256:1e4dafdc...acea49a. Bewaard voor de volgende verhoging, want dit is twee keer bijna misgegaan: - laat de digest er even van af zolang de image niet bestaat. Staan er een tag en een digest, dan bepaalt de digest wat er gehaald wordt, dus een oude digest onder een nieuwe tag levert stilzwijgend de oude image. Ongepind faalt hard en zichtbaar, en dat is hier het gedrag dat je wil; - doe beide repo-pushes voordat de app in umbrelOS geupdatet wordt. Anders is het toevoegen van de digest een tweede compose-wijziging en kost het een extra versienummer, want umbrelOS rolt alleen uit bij een hoger version. buildx imagetools meldt MediaType manifest.v2+json en dus een enkele architectuur, geen multi-arch index. Bij bouwen op het apparaat zelf klopt dat per constructie met de host; arm64 hoort erbij voor de officiele store en staat bij Publicatie-Relay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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> |
||
|
HarmenandClaude Opus 5
|
f223da1007 |
De image van 0.3.0 gepind op zijn digest
De tag stond er al, de digest kon pas toen de image geduwd was. Zonder digest draait er iets anders dan hier staat zodra dezelfde tag opnieuw geduwd wordt. Tests: test_appstore_vorm 34 goed, 0 fout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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> |
||
|
HarmenandClaude Opus 5
|
d5bbc3fc0b |
De app losgetrokken van een enkele client
Op verzoek van de gebruiker is dit geen app meer over de labels van een bepaalde wallet, maar wat het technisch al was: een relay voor apps die op Evolu gebouwd zijn. De tagline, de beschrijving, de releaseNotes en de statuspagina noemen geen enkele client meer, en category gaat van bitcoin naar files, waar de officiele store ook synchronisatie tussen apparaten onderbrengt. De tekst leunt op wat Evolu zelf schrijft en niet op een verzinsel: local-first, end-to-end versleuteld voordat het je apparaat verlaat, en een relay die alleen een owner id, tijdstempels en gevulde blobs ziet. Daar staat expliciet bij wat zelf hosten wel en niet verandert, want geheimer wordt de data er niet van; wie de versleutelde kopie bewaart en wie kan zien dat je synchroniseert wel. De tegenwerping is niet weerlegd maar geaccepteerd, en dat staat als zodanig in open punt 7: "Evolu Relay" zegt een Umbrel-gebruiker niets, terwijl de labels van een bekende wallet een concrete reden zijn om te installeren. Vindbaarheid inleveren is hier een keuze. Blijkt het te knellen, dan is daar terug te lezen waarom. In het Nederlandse codecommentaar blijft de historische toelichting staan, want die legt uit waarom de relay van Trezor eruit is gegaan. Alleen de regels die de app beschrijven zijn generiek gemaakt. Tests: test_appstore_vorm 34 goed, 0 fout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
576acd20dd |
Het pakket omgebouwd: kale relay, statuspagina, poorten omgedraaid
De app-map is niet langer de relay van Trezor met een Postgres en een quota-manager ernaast, maar de relay van Evolu met onze eigen allowlist eromheen. Drie containers werden relay, agent en nginx; het wachtwoord en de database zijn verdwenen. De poorten zijn omgedraaid en dat is de kern. Tot 0.0.2 hing de relay achter app_proxy en moest de inlog van umbrelOS dus uit, waardoor een statuspagina net zo onbeschermd zou zijn als de relay zelf. Nu hangt de pagina daar met de inlog aan, en publiceert de relay zijn eigen poort 3852 waar Zoraxy met TLS naartoe wijst. Dat is hetzelfde patroon als Electrum Gate met 50022. Niet 4000 op de host, want dat is een veelgebruikte poort en een botsing merk je pas als de app niet start. De agent beslist niets: hij leest wat het relay-proces heeft opgeschreven en legt opdrachten in een postbus die de relay zelf leegmaakt. Twee processen die in dezelfde allowlist schrijven is een wedloop die je een keer per jaar treft en dan niet kunt reproduceren. Hij weigert ook een tweede opdracht zolang de vorige er nog ligt, want overschrijven zou er stil een laten verdwijnen. De pagina volgt het ontwerpsysteem van Electrum Gate, zonder de Google Fonts-verwijzing daaruit: een app op een Umbrel hoort niet te wachten op een lettertype van buiten. Alles is met stringoptelling geschreven en zonder enig dollarteken, want umbreld haalt elke template door envsubst en zou een JavaScript-template-literal stilzwijgend leegmaken. De image is door de gebruiker gebouwd en geduwd; de compose is gepind op tag plus digest. Manifest naar 0.2.0, met een beschrijving en releaseNotes die kloppen met wat er nu draait in plaats van met het vorige pakket. Wat hier NIET mee bewezen is, en dat is meer dan gebruikelijk: de agent is alleen op syntaxis gecontroleerd, de pagina is nooit gerenderd, en of een opdracht van de pagina daadwerkelijk bij het relay-proces aankomt is niet gemeten. Dat kan alleen op het apparaat en staat als taak. Tests: alle vier groen (32, 54, 39 en 60 goed, 0 fout). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
fd62f48309 |
De Tor hidden service is de tweede weg naar binnen, en die staat nergens
De gebruiker vroeg of Evolu Relay kwaad kan op zijn Umbrel. Het eerlijke antwoord was nee met twee kanttekeningen, en de tweede stond in geen enkel bestand: umbrelOS maakt per app een Tor hidden service en die stond gewoon aan. Samen met PROXY_AUTH_ADD: "false" betekent dat de relay bereikbaar vanaf het internet, alleen beschermd doordat het .onion-adres onraadbaar is. De gebruiker zet hem uit. Wat dit lastig maakt om te zien: het staat niet in de compose van de app. Je kunt dat bestand volledig lezen en concluderen dat alleen je LAN erbij kan. Vandaar dat het nu op drie plekken staat: in de compose bij de instelling waar de afweging gemaakt wordt, in het plan bij de statuspagina-vraag, en in de naslag. De naslag is de belangrijkste van die drie, want het mechanisme is een eigenschap van umbrelOS en geldt voor elke app. Het gevolg niet: bij Electrum Gate legt dezelfde hidden service alleen de inlogpagina bloot, want daar staat de proxy-inlog aan en loopt de TLS-poort niet via de proxy. Die vergelijking staat er als tabel bij, want de instelling alleen zegt niets; het is de combinatie. Opgemerkt door de gebruiker dat het ook voor Electrum Gate zou gelden. Deels terecht, en dat is precies waarom het in de gedeelde naslag hoort en niet in het plan van één app. Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
730621d850 |
De image in het eigen register, gepind op digest
umbreld haalt elke image via de Docker Engine API op, dus een lokaal gebouwde tag is voor hem onbereikbaar. De image staat nu in het Gitea-register op dezelfde server als deze store, en anoniem halen werkt daar: dat is dezelfde voorwaarde als voor het klonen van de store zelf, en de eigenaar sysop staat publiek. Beide services krijgen tag plus digest. De digest hoort erbij en niet alleen de tag, want een tag kan opnieuw geduwd worden en dan draait er iets anders dan er in de repo staat. De toets in tests/test_appstore_vorm.py drukt de pinstatus af en beide regels staan nu op "gepind"; van Electrum Gate nog geen. Wat er expres bij staat in commentaar: dit is de digest van één architectuur. Er is alleen amd64 geduwd, want deze Umbrel is amd64. Voor de officiele store moet het een multi-arch index-digest zijn met arm64 erin, en dat is buildx met QEMU. Zonder die notitie leest een gepinde digest als "eis gehaald". build.sh wijst nu ook naar het register, anders levert een volgende bouw weer een tag op waar de compose niet naar kijkt. De slotregels van het script zijn geen suggestie meer maar de resterende stappen: push, digest overnemen, version verhogen, en anoniem controleren met een uitgelogde pull in dezelfde context als de login. Manifest naar 0.0.2, met release notes die zeggen waarom: 0.0.1 was niet te installeren. Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
96565085a5 |
umbreld pullt buiten compose om, dus pull_policy kon nooit werken
De installatie faalde, en de foutmelding was voorspelbaar maar de oorzaak niet:
pull access denied for whatsnext/evolu-relay
at /opt/umbreld/node_modules/docker-modem/lib/modem.js:382:17
Die stacktrace is het punt. De pull komt uit docker-modem, de Docker-client van
umbreld zelf, dus rechtstreeks op de Docker Engine API. Compose komt er niet aan
te pas en de compose wordt alleen gelezen om te zien welke images erin staan.
pull_policy is een sleutel van de Compose-specificatie en wordt dus nooit
bekeken. Mijn reparatie van de vorige commit kon per definitie niet werken; hij
is eruit, want een sleutel die niets doet met een commentaar dat beweert van wel
is erger dan geen sleutel.
Waar die fout vandaan kwam: ik las in app-script dat install een
`compose "${app}" pull` doet en nam aan dat dat het pad was. Dat bestand is de
legacy-compat-laag en niet wat umbrelOS 1.x loopt bij een installatie vanuit de
interface. Dat staat nu als waarschuwing in de naslag, want het is precies het
soort bron dat overtuigend leest en het verkeerde antwoord geeft.
De echte regel, nu op het apparaat vastgesteld in plaats van uit code afgeleid:
elke image in de compose van een app moet anoniem uit een register te halen zijn.
Een lokaal gebouwde tag werkt niet, hoe goed docker compose up er ook mee overweg
zou kunnen.
Het image-veld staat er nog en wijst nog steeds naar de lokale tag. Dat is
bewust: het commentaar erboven zegt nu dat het zo niet werkt en wat er moet
komen. Weghalen zou de app-map stiller maar niet beter maken, en de keuze voor
een register is aan de gebruiker.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
HarmenandClaude Opus 5
|
8004acfae9 |
pull_policy: never, anders faalt de installatie op een image die nergens staat
De image is gebouwd op de Umbrel en staat alleen in de lokale Docker-opslag: er
is geen register. Dat leek te werken omdat `docker compose up` niets ophaalt zolang
de image lokaal bestaat. Bij het nakijken van app-script in umbreld bleek dat niet
het pad dat een installatie loopt.
umbreld draait `compose "${app}" pull` bij install, bij update en bij
post-patch-update. Die zou whatsnext/evolu-relay:c03a204 op Docker Hub zoeken,
waar hij niet bestaat, en dan faalt de installatie voordat er iets gestart is. Met
pull_policy: never slaat compose die twee services over bij het ophalen. Postgres
houdt de standaard, want die komt wél uit een register.
Bijkomend voordeel dat het houdt zodra er ooit een register is: ontbreekt de image,
dan is de fout "niet gevonden" en die wijst naar de overgeslagen bouwstap, in plaats
van een mislukte netwerkpoging die naar het register wijst.
Uit hetzelfde bestand meegenomen naar de naslag: starten gaat met
`up --detach --build`, dus umbreld zou een build:-blok wél uitvoeren. Toch blijft
bouwen-in-de-app een slecht idee, en nu met een tweede reden naast de whitelist: de
installatie hangt dan tijdens het bouwen. Op deze machine duurde dat 50 seconden.
Geen versieverhoging: deze app is nog nooit geïnstalleerd, dus er is geen manifest
op een apparaat om tegen te vergelijken.
Tests: 32 goed 0 fout, 54 goed 0 fout en 39 goed 0 fout, niets overgeslagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
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> |