cd4c7da0d71873904aff4713248469781484cf08
33
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 HarmenandClaude Opus 5
|
cd4c7da0d7 |
Gate 0.0.29 en Relay 0.5.5: de gloed uit, als schakelaar
Op verzoek van de gebruiker, in beide apps. De accentgloed uit Gate 0.0.25 en Relay 0.5.2 gaat uit; de rand, de schaduw, het randlicht en de doorschijnende kleur van de vlakken blijven staan. Het is een schakelaar geworden en geen verwijdering: data-glow="on" op het html-element zet hem terug, en alleen samen met data-depth="deep". Die tweede eis is van de gebruiker en hij is juist: de gloed is de onderste van de vier dieptelagen, dus aanzetten op een vlakke pagina legt een verloop achter vlakken die er dekkend voor staan. De blur hangt nu aan de gloed en niet aan de diepte, want een backdrop-filter op een egale ondergrond levert per definitie niets op. Daarmee verviel het mobiele terugvalblok (Gate 0.0.26, Relay 0.5.3) volledig: dat zette gloed, blur en vlakkleur om, en de eerste twee staan nu al uit. Meegevonden en gerepareerd: een selector met twee attributen wint van de :root in de prefers-reduced-transparency-query, die daardoor de blur niet meer uit kreeg. Die query noemt de gloedselector nu letterlijk. Alle zeven tests groen: 22 + 43 + 39 + 54 + 28 + 115 + 65 goed, 0 fout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
dbec428e62 |
Gate 0.0.28: de blokhoogte was niet van deze app
Op verzoek van de gebruiker. Dit is een TLS-voordeur op een Electrum-server; wat de keten doet staat in elke wallet die hij al heeft. Vier widgets over, alle vier over deze gateway. De leeftijd van de meting stond onder de blokhoogte en was daarmee de laatste plek waar de pagina zei hoe oud zijn gegevens zijn: de voetregel en de badge die hetzelfde zeiden zijn in augustus weggehaald met precies dat argument. Die regel staat nu onder de reactietijd, na de sparkline zodat de vier onderregels op een lijn blijven. De rij is een raster van vier met breekpunten op 1100 en 560 pixels; vier deelt door twee, dus de stap die bepaalde welke widget alleen kwam te staan is vervallen. In de agent is de hoogte uit het antwoord gehaald maar het verzoek niet: daar wordt de reactietijd uit gemeten. Alle tests groen: 22 + 43 + 39 + 54 + 28 + 115 + 65 goed, 0 fout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
5ee21b10e7 |
Gate 0.0.27: de statuskaart loog na elke herstart. Relay 0.5.4: Status naar rechts
De melding van de gebruiker was "Not answering" met [Errno 111] Connection refused, terwijl de gateway van buiten gewoon werkte. Het was een startvolgorde en geen storing: 1. de compose laat `server` ná de agent starten (depends_on: [agent]), want nginx lost http://agent:8000 bij het starten op en breekt af op een onbekende naam; 2. build_status draait meteen bij het opstarten, vóór de eerste WAKE.wait; 3. de branch die de meting uitstelt hing alleen aan `reloaded`, en die is bij een herstart met een ongewijzigd certificaat False, dus er werd gemeten; 4. nginx luisterde toen nog niet op 50022; 5. en het bleef staan, want de volgende meting kwam pas na SELF_CHECK_INTERVAL. Twee reparaties, elk voor een helft. De eerste ronde van een proces meet niet maar zet `pending` (die toestand heeft geen `at`, dus de ronde daarna meet gewoon), en na een mislukking wordt er na GATE_SELF_CHECK_RETRY (60s) opnieuw gemeten in plaats van na 300. Een geslaagde meting blijft op 300, want dat is de waarde die zelden verandert en die het activiteitenlog belast. De fout zat er sinds de zelfcontrole bestaat (27-08-2026) en was alleen binnen vijf minuten na een herstart te zien. Mutatie-getest: de eerste-rondebranch uitschakelen laat twee tests omvallen, de snelle herhaling uitschakelen precies één. Relay: de statuswidget staat nu rechts in de bovenste rij en heet Status in plaats van Relay, gelijk aan Electrum Gate. De twee pagina's zijn één app store en horen op dezelfde manier te lezen, en dit is de widget die als enige begrijpelijk is zonder buur. De id's relay-state en relay-sub blijven. Suite groen: 54 + 28 + 65 + 39 + 43 + 22 + 115. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
63f1557713 |
Gate 0.0.26 en Relay 0.5.3: Running weer accent, gloed uit op mobiel
Twee bijstellingen op de opfrisbeurt van vanochtend, allebei op verzoek van de gebruiker. "Running" staat weer in de accentkleur. In Evolu Relay hing die tekst aan --pos, en die ging van oranje naar groen omdat --pos het accent volgde en dat als merkkleur las in plaats van als betekenis. In Electrum Gate hing hij aan niets en was hij gewoon --text-primary. Beide staan nu op --accent-text, met een eigen .stat-val.ok: "Running" is de eigen toestand van de app en geen positief cijfer, en --pos blijft groen voor "het staat in de plus". In Gate wordt die klasse alleen bij state 'ok' gezet; 'off' en 'pending' zijn niet fout maar ook niet in orde en houden de gewone tekstkleur. Op een telefoon valt de pagina terug op de vlakke stand. De gloed is 58rem breed, ongeveer 928 pixels, dus op een telefoonscherm is het beeld smaller dan de gloed zelf en wordt het een egale waas in plaats van een verloop. De blur gaat in dezelfde stap eruit, en dat is geen extraatje: doorzichtigheid met niets erachter is gewoon grijs, terwijl een backdrop-filter op een telefoon wel per frame rekenwerk kost. Rand, schaduw en randlicht blijven staan. Grens 900 pixels. De selector is html[data-depth] en niet :root, want :root heeft dezelfde specificiteit als de [data-theme]-blokken en zou dan alleen winnen zolang hij er in het bestand onder staat. Alleen de pagina's, dus opnieuw geen nieuwe images. Suite groen: 22 + 43 + 22 + 115 op de geraakte delen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
45dd50fb0b |
De opfrisbeurt uit het designsysteem: Gate 0.0.25, Relay 0.5.2
Beide pagina's volgen nu HomeGit/Docs/website-design-system.html, in dezelfde ronde als AssetApp. Drie dingen, en de volgorde is niet willekeurig: - een accentgloed achter de pagina, uit de linkerbovenhoek. Dit is de VOORWAARDE voor de rest en niet de finishing touch: een backdrop-filter op een egale ondergrond levert per definitie niets op, dus er moet eerst iets achter de vlakken staan; - kaarten doorschijnend, met een randlicht bovenlangs en een schaduw uit een token; - één hoek voor elk buitenste kader. De kaart van --radius-xl naar --radius-lg, gelijk aan het logkader, dat zijn geneste hoek daarvan afleidt. Het volle accentpalet van AssetApp (vijf kleuren, licht en donker) staat erin; beide apps blijven op oranje en krijgen bewust geen knop. Om dezelfde reden staat de diepte hier vast aan, terwijl het in AssetApp een instelling is: dit zijn statuspagina's met licht/donker en verder geen bediening. --pos is groen geworden in plaats van oranje. Hij volgde het accent, en dat las als merkkleur in plaats van als betekenis; zichtbaar gevolg is dat de badge "Running" nu groen is. Meegevonden en meteen gerepareerd: prefers-reduced-motion en prefers-reduced-transparency mogen niet in één media-query. Windows heeft een schakelaar "Animatie-effecten" die bij veel mensen uit staat en die zet reduced-motion op reduce; samen in één query bleef er van de hele opmaak niets over. Ze staan apart, en reduced-motion haalt alleen de overgang weg. Alleen de pagina's, dus geen nieuwe images: VERSION in tools/evolu-relay/build.sh blijft staan en alleen de manifesten gaan omhoog. Suite groen: 22 + 43 + 54 + 22 + 65 + 39 + 115. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
627c8306b1 |
Pinnen komt na een eigen image, niet ervoor
Alleen documentatie. Op aanwijzing van de gebruiker bij het afsluiten: de suite meldt bij elke ronde dat python:3-alpine en nginx:alpine niet gepind zijn, en de verleiding is dat even te doen. Dat is de verkeerde volgorde. Pinnen is een eis van Publicatie, maar daarvoor gaat de app-inhoud eerst een eigen image in, en dan bestaan die twee niet meer als de plek waar onze code draait. De regel staat nu in KNOWLEDGE.md, want vier plannen raken hem en geen van de vier bezit hem: de eis komt uit Publicatie, de oorzaak zit in Eigenimage, en de taak stond in Umbrelapp en Appstore. Met twee grenzen erbij, anders slaat het de andere kant op door: de eigen image pin je wel meteen bij elke verhoging, en de melding in de suite blijft een afdruk en geen toets, zodat de suite niet rood staat tot Eigenimage klaar is. Onderweg bleek Eigenimage PLAN.md 8 achterhaald en misleidend. Daar stond dat het bouwrecept van Evolu Relay misschien zou vervallen zodra de kale relay de weg werd, en dat je er daarom niets aan moest verbeteren. Wij bouwen juist een eigen image, want de twee terugroepfuncties zitten niet in de gepubliceerde. En de paragraaf onderschatte wat er nog te doen is: ook bij die app staan de agent en de pagina nog op vreemde images, alleen de relay zelf is klaar. Herschreven, en de kolom App van dat plan in CONTINUE_HERE staat daarom op "beide" in plaats van op Gate. Verder de taak in Umbrelapp gemarkeerd als wachtend op Eigenimage in plaats van open, een verwijzing bovenaan Images-pinnen.md, en de regel voor Umbrelapp in CONTINUE_HERE ingekort en bijgewerkt naar 0.5.1. Geen tests gedraaid: er is niets buiten Docs/ geraakt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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
|
e4a8747307 |
De leeskant is bewezen, en daarmee is het doel van Umbrelapp gehaald
Getest met een tweede gebruikersaccount op dezelfde Mac, en dat is schoner dan een tweede apparaat: die installatie begint met een lege lokale Evolu-database, dus alles wat daar verschijnt kan alleen van de relay komen. De labels kwamen door, en een wijziging aan die kant komt ook weer terug. Beide richtingen dus, met bewijs. Daarmee staat er wat dit plan beloofde: een tweede app in deze store, geinstalleerd op de Umbrel, met Trezor Suite die erop synchroniseert. Het restwerk is klein en wacht nergens op: een herstart van de app overleven, twee images pinnen, en data per eigenaar kunnen wissen. Prioriteitsherziening die daarbij hoort. Umbrelapp zakt van A naar B. Eigenimage gaat naar A, want dat lag alleen stil omdat de gebruiker eerst Evolu Relay wilde afmaken; het is hernummerd naar 004 zodat de bovenkant van de reeks weer op tier-orde staat. Proefopstelling zakt naar B en is klaar voor het archief: alle vragen die het bezat zijn hier beantwoord, en de rest gaat over een pakket dat niet meer bestaat. De takenlijst is opgeschoond van regels die over het oude pakket gingen: de Postgres-pin, de schemavraag, het adres op 3851 en de twee blokkades. In plaats daarvan staan de twee images die nu nog ongepind zijn. En de controle of deze app Electrum Gate raakt is afgevinkt met wat er werkelijk gebeurde: dat deed hij, via een gedeelde containernaam, en dat is gerepareerd. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
fc5a941de0 |
iOS verklaard: zonder apparaat geen sleutel, en dus geen synchronisatie
De gebruiker merkte op dat hij op de Mac per wallet op de hardware wallet moest goedkeuren, en dat zijn model nog niet aan een iPhone te koppelen is. Dat sluit de keten, en die is in de broncode van Suite na te lezen. De OwnerId wordt op het apparaat afgeleid: createRetrieveSuiteSyncOwner begint met een harde controle op device.connected. selectIsSuiteSyncInitPossible eist connected plus ondersteuning. En selectSuiteSyncInteraction geeft null zodra er geen deviceStaticSessionId is, waarna useTurnOnSuiteSyncGuard in dezelfde tak belandt als 'unsupported' en gewoon ok() teruggeeft. Dat verklaart elke waarneming tegelijk: de schakelaar liet zich aanzetten, want dat is alleen een instelling; er kwam geen foutmelding; er was geen groen bolletje; en onze relay zag nooit een eigenaar. Zonder een Trezor die aan de telefoon kan is er geen eigenaar, en zonder eigenaar valt er niets te synchroniseren, met of zonder relay. Dit is dus geen tekortkoming van dit pakket en er valt niets aan te repareren. Wat het wel betekent voor de app-tekst is dat werken op een telefoon niet beloofd moet worden zolang dat van het model afhangt. Wat erdoor open blijft is de leeskant: dat een tweede apparaat de labels terugkrijgt is nooit gezien, en iOS zou die tweede client zijn geweest. Dat is nu de belangrijkste openstaande controle, en er is een client voor nodig die wel een sleutel kan afleiden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
bf8bedcda9 |
Sessie afgesloten: waar we staan met Evolu Relay
De app draait als 0.3.0 en wordt gebruikt: kale relay met een eigen eigenaars-allowlist, statuspagina achter de umbrelOS-inlog, en TLS via Zoraxy op een eigen subdomein waar de handshake 101 geeft. De desktop synchroniseert eroverheen, met een geleerde eigenaar en een gesloten deur erna. iOS blijft open, en het vermoeden van vanmiddag is weerlegd in plaats van bevestigd: TLS was niet de verklaring. Met een geldig certificaat, een opgeslagen URL en de sync-schakelaar aan komt er nog steeds niets aan, en sinds 0.3.0 is dat hard gemeten in plaats van afgeleid: het relay-proces logt elke eigenaar die zich meldt, ook bekende en geweigerde, en van de telefoon verschijnt niets. Daarmee is de hele app vrijgepleit. De volgende stap staat als eerste taak en kost een minuut: kijken of het verzoek de telefoon uberhaupt verlaat, via het log van Zoraxy. Doordat iOS niet meedoet is de leeskant nooit gemeten. Dat is de tweede taak en hij hangt aan de eerste, want iOS zou die tweede client zijn. Proefopstelling is hiermee volledig ingehaald: beide vragen die dat plan nog bezat zijn beantwoord, en wat er verder in stond gaat over een pakket dat niet meer bestaat. Dat staat als een beslissing in de index, niet als een daad. De reparatie aan Electrum Gate heeft een eigen entry gekregen in het plan Webinterface, want die app ging kapot door de tweede app en dat hoort daar nagelezen te kunnen worden. Tests: alle vier groen (34, 54, 39 en 61 goed, 0 fout). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
6b114475d5 |
De proef is geslaagd: de kale Evolu-relay praat met Suite
Trezor Suite op de desktop stuurde elf labels naar docker.io/evoluhq/relay:latest en die kwamen aan: de database in het volume groeide van 40960 naar 49152 bytes en de tijdstempel verzette. De protocolversie klopt dus, en daarmee is de richting van 27-08 geen verwachting meer maar een meting. Geen Postgres, geen quota-manager, geen eigenaarsregistratie, en toch verkeer. Open punt 6 is daarmee beslist. Het blijft in de lijst staan tot de verbouwing gedaan is, want het beschrijft de reden waarom het huidige pakket eruit gaat. Een waarschuwing hoort erbij en staat in het protocol: de relay logt geen enkele verbinding. Het venster blijft stil terwijl er labels binnenkomen, dus "ik zie niets gebeuren" is hier geen waarneming maar een eigenschap van de relay. Alleen het volume vertelt iets, en daarom mag de nulmeting niet overgeslagen worden. Dat kostte vandaag bijna de verkeerde conclusie. Twee dingen bleven ongemeten en staan als taak. De leeskant: er is geen tweede client geweest, dus dat een ander apparaat de labels terugkrijgt is niet gezien. En iOS maakt geen enkele verbinding, terwijl het veld daar bestaat, valideert op http(s) en zijn waarde onthoudt. Het vermoeden is TLS, en dat is als open punt 9 opgeschreven met de prijs erbij: een certificaat voor een LAN-adres bestaat niet, dus de wegen die overblijven lopen via Bereikbaarheid en zijn een eigen ontwerpvraag. Er is ook een tweede verklaring die even goed past, namelijk dat het synchroniseren op de telefoon nooit begon, en die is gratis te meten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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> |
||
|
HarmenandClaude Opus 5
|
f3f8f5ade6 |
Kaal gaan haalt de enige bescherming weg die er nu is
Richting van de gebruiker: de kale Evolu-relay, met een eigen limiter erop en de statuspagina uit open punt 2. Vastgelegd, niet gebouwd; de app staat uit en er gebeurt vandaag niets meer aan. Het inzicht dat die drie aan elkaar knoopt staat er nu bij. De kale relay heeft geen toegangscontrole, en dat is bij Evolu het ontwerp en geen omissie. Wat vandaag de schade beperkt is juist een applicatiecontrole: Trezor's relay weigert elke eigenaar zonder limietenrij. Kaal gaan haalt precies die weg, dus de limiter is de vervanging ervan en geen extraatje. De statuspagina krijgt er een taak bij: tonen welke eigenaar toegelaten is, met de knop om die keuze te wissen. Twee dingen die makkelijk verkeerd onthouden worden, daarom expliciet. De quota-manager die er nu in zit is niet te hergebruiken: die schrijft in Trezor's limietentabel en die tabel bestaat straks niet meer. En de meest voor de hand liggende limiter breidt de relay uit via createRelay, dus de bouwstap en het eigen register komen dan terug; de gebruiker meldt dat de broncode nog op zijn Umbrel staat, dus dat is geen obstakel. Postgres en het wachtwoord vervallen sowieso. Het blijft een richting en geen besluit: de protocolproef is niet gedaan, en die blijft de eerste taak. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
4ba9973e97 |
"De kale relay proberen" las alsof hij al in het pakket zat
De regel in de index noemde docker.io/evoluhq/relay:latest als volgende stap zonder erbij te zeggen dat die proef los naast het pakket staat. Het pakket gebruikt onze eigen bouw van trezor-suite-sync, gepind op c03a204, in twee services plus een Postgres; de kale Evolu-relay komt daar niet in voor. Nu staat de volgorde er expliciet: eerst een losse docker run om te meten of Suite er uberhaupt mee praat, en pas daarna beslissen of het pakket daarnaartoe verbouwd wordt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
a1c17ceff6 |
Het register beslist, en de aandacht gaat naar Evolu Relay
Open punt 1 van Eigenimage: voor nu Gitea, bij inlevering opnieuw kijken. De twee bezwaren die dat punt opriep, het domein van de gebruiker in een publiek pakket en andermans installaties die aan zijn thuisserver komen te hangen, gelden allebei pas bij inlevering. Daar is hij uitdrukkelijk nog niet aan toe: dit is voorlopig zijn eigen app voor eigen gebruik. Twee dingen zijn bij dat besluit vastgelegd zodat ze niet met het antwoord verdwijnen: bij inlevering moet het register opnieuw beoordeeld worden, samen met het pinnen en het kaal maken van het app-id, en de opmerking dat umbrelOS een eigen register zou toestaan is niet nagetrokken. Dat hoort bij Publicatie-Gate. Daarmee kan fase 1 zo beginnen, maar het plan ligt stil op verzoek van de gebruiker: hij gaat eerst verder met Evolu Relay. Umbrelapp staat nu bovenaan tier A, met twee feiten erbij om mee te starten: die app staat op dit moment uit, en hij is nog nooit met Trezor Suite verbonden geweest. Eigenimage houdt tier A en zijn nummer; er is niets aan gebouwd, dus er ligt ook niets half af. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
940b2582f9 |
Webinterface is af en zakt naar B, Eigenimage neemt het over
De opruimronde eerst. Zes vinkjes stonden open terwijl het werk gedaan was: open punt 5, fase 5, "draaien op de Umbrel", "verifiëren tegen een echte status.json", en het nakijken van de eerste indeling op een breed scherm, een indeling die na fase 6 niet meer bestaat. Elk staat nu afgevinkt met de reden erbij, want een regel wegpoetsen laat de vraag "is dit ooit gebeurd" open. Ook de regel "Niets" onder Geblokkeerd is geen vinkje meer. Een leeg vakje bij het woord niets telt mee zodra iemand de openstaande punten telt, en dat is precies wat die kop moet uitsluiten. Wat er in Webinterface overblijft is niet te plannen of ligt bij de gebruiker: een etmaal wachten op het log, waar Nginx Proxy Manager zijn certificaten neerzet, en of Zoraxy een harde afhankelijkheid wordt. Vandaar tier B. Eigenimage is daarmee gepromoveerd naar Actief met nummer 006 en tier A, zoals op 27-08 afgesproken. Het masterplan is omgezet: de drie open beslissingen zijn naar OPEN.md gegaan, het werk naar TAKEN.md in vier fasen, en PLAN.md houdt het ontwerp. Het origineel blijft nog even staan; dat verhuist pas naar Archief nu deze commit er is. De eerste stap daar is geen bouwtaak maar een vraag: blijft het Gitea-register ook bij publicatie de bron. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
498b0fe695 |
De nieuwe widget vond meteen een fout, en die zat in de widget zelf
De Status-widget meldde "Not answering" met Errno 111 op een gateway die gewoon werkte. Die foutmelding was het bewijs: geweigerd betekent dat de naam oploste, alleen niet naar ons. GATE_TLS_HOST stond op de servicenaam "server", en dat is een naam die meer apps op een Umbrel gebruiken; op een gedeeld netwerk is het dus een gok wie je krijgt. Nu de volledige containernaam, precies de vorm die umbrelOS van APP_HOST verlangt en die twee regels hoger in dezelfde compose al stond. Wat dit zegt over de aanname van gisteren: er stond dat dit "dezelfde weg is die nginx andersom gebruikt". Dat klopte voor de richting maar niet voor de naam, en het was opgeschreven als redenering in plaats van als meting. De rest zijn bijstellingen van de gebruiker na het bekijken van 0.0.17. Het menu is drie kale punten met een accent bij hover in plaats van een knop, de eerste regel heet Settings zonder de certificaatnaam erachter, de dialoog opent in het midden in plaats van linksboven, de widgets zijn hoger met hun waarde langs de onderrand, reactietijd en blokhoogte zijn omgedraaid zodat de reactietijd naast de server staat waar hij over gaat, en het log is half zo hoog. De manifest-toets ving onderweg een echte fout: bij het herschrijven van de release notes was de sleutel releaseNotes zelf weggeknipt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
be91125cce |
De tweede indeling gebouwd, en er ging meer weg dan erbij kwam
Vijf widgets op de bovenste rij, de certificaatkeuze in een dialoog achter een puntjesmenu, het activiteitenlog vol breed, en het instelkader dichtgeklapt met twee kopieerknoppen. Uitgeleverd als 0.0.17. De zelfcontrole uit 0.0.16 heeft daarmee eindelijk een plek om te verschijnen. Wat opvalt is wat er verdween. Twee mechanismen bestonden alleen omdat er kaders naast elkaar stonden: het meerekken van de tegels met de hoogte van hun buur, en het samen groeien en krimpen van log en certificaatkader. Dat tweede was de hele inhoud van 0.0.13. Vijf gelijke widgets en een vol breed log hebben geen buur, dus beide zijn weg, samen met .col-5 en .col-7. De harde eis staat in de code en niet alleen in het plan: de foutmelding "geen certificaat in gebruik" heeft de knop die de dialoog opent. Een verse installatie heeft geen certificaat en de pagina is de enige plek waar je er een kiest; dat achter een menu verstoppen zou de klem van 0.0.3 in een andere vorm zijn. Twee dingen onderweg bijgestuurd. Het menu werd drie punten in plaats van een hamburger, op aanwijzing van de gebruiker, want dat is wat umbrelOS bij zijn eigen apps toont. En het ontwerp beweerde dat de certificaatlijst een lijst was, terwijl die op 20-08 al een dropdown geworden is; dat is rechtgezet in 4a2 en de dropdown is ongewijzigd meeverhuisd. Niet geverifieerd: niets hiervan is in een browser gezien, op geen enkele schermbreedte. Dat staat als taak met de gebruiker als eigenaar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
c8d9765cb3 |
De app kijkt naar zijn eigen voordeur, en meet minder dan het plan beloofde
Open punt 5 van Webinterface, goedgekeurd en gebouwd. De agent verbindt met de eigen TLS-poort, maakt de handdruk af en vergelijkt het getoonde certificaat byte voor byte met het gekozen bestand. Die vergelijking blijkt waardevoller dan de handdruk. Ze vangt een certificaatwissel die nginx nooit heeft toegepast, en dat is precies het geval waar een controle op vertrouwen blind voor is. Er wordt daarom bewust niet tegen de certificaatwinkel van het besturingssysteem geverifieerd: een zelfondertekend certificaat uploaden is een ondersteunde bron en die opstelling zou dan als kapot gemeld worden. Twee dingen liepen anders dan het plan zei en staan nu rechtgezet in PLAN 4a2, OPEN punt 5 en de changelog. De belofte "luisteren, certificaat en doorverbinding in een keer" klopt voor twee van de drie: na de handdruk wordt er niets verstuurd. Een echt verzoek zou de sessie bytes geven, en sessies met bytes worden nooit uit het activiteitenlog gefilterd, want die kunnen een storing zijn. En dat filteren was de tweede verrassing. Elke meting is voor nginx een gewone sessie en levert dus een logregel op; zonder rem ging het log over onszelf in plaats van over wallets. Er zit nu een rem van vijf minuten op, er wordt niet gemeten vlak na een herlading omdat het vorige certificaat er dan nog staat, en de eigen regels worden weggelaten op grond van het moment. Tests: 22 nieuw, met de nadruk op de niet-gelukkige paden en op de rem, want dat is wat het log bruikbaar houdt. Alle vier de beslissende regels mutatie-getest. De changelog kreeg ook de ontbrekende 0.0.15 erbij. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
decf431416 |
De tweede indeling, met de eis die het verstoppen van de keuze zelf oproept
Ontwerp van de gebruiker, na het testen van de eerste indeling: vijf kleine widgets op de bovenste rij, certificaatkeuze en uploaden naar een dialoog achter een menu rechtsboven, activiteitenlog over de volle breedte, en het instelkader dichtgeklapt met twee kopieerknoppen in plaats van een per clientregel. Vastgelegd als PLAN.md 4a2 naast 4a1, want die eerste blijft de verantwoording van wat er staat. Drie dingen staan erbij die uit de brief zelf volgen: De harde eis. Kiezen achter een menu botst met de ergste toestand die deze app kent, een verse installatie zonder certificaat, en dat is letterlijk de klem van 0.0.3. De foutmelding bovenaan blijft dus staan en krijgt de knop die de dialoog opent; de hamburger is de weg terug, niet de enige weg erheen. Twee teruggedraaide besluiten, opgeschreven zodat niemand ze later herstelt met een verwijzing naar de oude reden: de kopieerknop per client verdwijnt, en de afwijzing van een dropdown uit 19-08 verbiedt geen dialoog. Bij de eerste hoort een voorwaarde: de wallets blijven gegroepeerd onder de vorm die ze willen, want anders is er wel een adres maar niet meer bij welke wallet het hoort. Deze indeling haalt bovendien twee koppelingen weg die er alleen waren omdat kaders naast elkaar stonden. Een daarvan was de hele inhoud van 0.0.13. Open punt 5 is goedgekeurd en verhuisd naar Beslist; punt 3 stond nog open terwijl het log al twee versies draait. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
b43eee9d79 |
De volgorde vastgelegd waar hij gelezen wordt, niet waar hij hoort te kloppen
Eigenimage komt na Webinterface, besloten door de gebruiker. De vindplaats is hier het punt: een masterplan zonder tier komt in geen enkele prioriteits- herziening langs, dus een notitie in dat plan alleen zou op het moment dat het ingaat niemand bereiken. Daarom staat de keuze in de prioriteits-header van Webinterface, want dat is wat een sessie bij het starten leest, met de opdracht erbij: promoveren met een nieuw tussennummer en eerst de registervraag beantwoorden. De kolom "afhankelijk van" in de masterplannen-tabel houdt zijn streepje. Die is voor harde afhankelijkheden en dit is er geen; technisch kan het plan morgen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
1f02e51b08 |
Een eigen image is te verdedigen, maar niet met het argument dat voor de hand ligt
Masterplan Eigenimage: van de code die nu uit app-data gemount wordt een image maken, in het eigen Gitea-register. Het plan begint met wat het niet oplost. De vanzelfsprekende motivatie zou zijn dat wijzigingen een bestaande installatie niet bereiken, maar dat is niet meer waar: alle code van deze app staat in een .template en die staan in de update-whitelist. Alleen icon.png valt erbuiten, en dat is te klein om een plan op te bouwen. Wat overblijft weegt nog steeds: de code gaat uit app-data, het shell-blok van honderd regels verlaat de compose en wordt een leesbaar entrypoint, en er is nog een eigen digest in plaats van twee vreemde. De kosten staan er even hard in: een bouwronde per wijziging, precies terwijl Webinterface op tier A itereert. De registervraag is het echte open punt. Gitea werkt en dat is bij Evolu Relay bewezen, maar bij inlevering zou het domein van de gebruiker in het pakket staan en zou zijn thuisserver een afhankelijkheid van andermans installatie worden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
9d53612db8 |
De backendwissel is geen aanname meer: Fulcrum werkt zonder aanpassing
Fulcrum is uitgesynct en de gebruiker heeft omgeschakeld. De app hoefde niets
te weten van de wissel, want hij leest ${APP_ELECTRS_NODE_IP} en Fulcrum aliast
zichzelf naar die naam. Bevestigd langs alle drie de wegen: een wallet van
buiten over TLS op 50022, een wallet binnen het netwerk, en het dashboard met
een antwoordende server.
Daarmee is hoofdstuk 4 van de appstore-spec waargenomen gedrag in plaats van
een afleiding uit andermans broncode, en is de poortbotsing op 50002 ook in de
praktijk weg. Fase 3 van Appstore is af.
Gratis meegekomen: umbrelOS herstartte de app zelf bij de wissel en hij kwam
terug met dezelfde certificaatkeuze. Dat is de vervangende start/stop-controle,
maar nadrukkelijk geen antwoord op de volgordevraag, want Zoraxy draaide al.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
HarmenandClaude Opus 5
|
c80d587100 |
Wat een relay ziet, en waarom het risico niet vertrouwelijkheid is
De gebruiker vroeg of iemand met kennis van de API zijn labels kan opvragen zodra de relay op een domein staat. Nee, en de reden is scherper dan "het is versleuteld". Uit een OwnerSecret worden met SLIP-21 drie onafhankelijke waarden afgeleid: een publieke OwnerId, een encryptiesleutel en een rotatable write key. Alleen de eerste gaat naar de relay. Het aardige is dat de OwnerId expres niet geheim is. De beveiliging leunt er niet op dat je adres onbekend blijft, en dat is het tegenovergestelde van een systeem waar een onraadbare URL de grens vormt. Daarom kan deze relay bij een onbekende partij staan. Twee dingen expres niet gladgestreken. Of iemand die een OwnerId kent de versleutelde blobs kan ophalen staat nergens gedocumenteerd; kan het, dan lekt dat bestaan, activiteit en bij benadering omvang, niet inhoud. En onraadbaarheid van de OwnerId beschermt tegen het aflopen van een relay, niet tegen lezen. Dat verschuift waar Bereikbaarheid over gaat. Het risico van een open eindpunt is misbruik als gratis versleutelde opslag: een kale relay kent geen accounts en kan per definitie niet weten van wie de data is. Dat is met terugwerkende kracht de tweede functie van Trezor's quota-manager, naast facturering, en die haalden wij eruit. Het voorstel van de gebruiker voor een eigen quota-manager met een allowlist van OwnerId's staat erin, met drie uitvoeringen en hun prijs. De netste is createRelay uit @evolu/nodejs, dat auth expliciet als reden noemt om die API te gebruiken, maar dan bouw je weer een eigen image en verlies je de winst van de gepubliceerde. Met een detail dat het lastiger maakt dan het klinkt: je moet je eigen OwnerId kennen om hem te vlaggen, en Suite toont die waarschijnlijk nergens. Uitweg is niet laten typen maar laten leren: de eerste eigenaar die verbindt wordt toegelaten. Meegenomen uit de vorige bevinding: open punt 2 is beantwoord, Suite eist geen TLS. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
dc0bb9f0dc |
De client zegt het zelf: bij een eigen relay wordt de quota-manager genegeerd
De gebruiker wees erop dat de broncode van Trezor Suite lokaal staat, in het project Trezor onder Repos/trezor-suite. Dat beantwoordde in een half uur wat uit de serverkant alleen niet te halen was, en het draait de vraag van vanavond om. Uit een commentaarregel van Trezor zelf, in suite-common/suite-sync-quota-manager/src/createSuiteSyncQuotaManagerCompositionRoot.ts: "We only want to use QM for our own relay servers. In case custom URL has been set, QM is ignored, unless enforceQuotaManager is set (used for e2e tests)." Die vlag staat standaard op false. Daarmee is het pakket dat nu draait niet alleen zwaar maar waarschijnlijk kapot bij ontwerp. Met een eigen relay-URL registreert de cliënt geen eigenaar, en de relay van Trezor weigert iedereen zonder rij in de limietentabel. Die rij komt er dus nooit: het enige dat hem zou maken wordt door de cliënt overgeslagen. Niet de kale Evolu-relay was de gok, maar deze. Twee dingen die er gratis bij kwamen en die vragen van eerder beantwoorden. Suite neemt http:// (de e2e-test gebruikt http://10.0.2.2:4000 en :4001), dus TLS is geen eis en dat raakt het masterplan Bereikbaarheid. En de instellingen staan onder dev-utils, met twee losse velden voor relay en quota-manager, plus een bevestiging op het apparaat bij het aanzetten. Wat er nog echt open is, is geen redenering maar een proef: Suite gebruikt @evolu/web@3.0.0-next.1 met een eigen patch in .yarn/patches, en de gepubliceerde relay-image hoeft daar niet bij te passen. Dat is met docker run in minuten te weerleggen en staat als eerste taak. De vindplaats zelf is als naslag opgeschreven, met de vijf bestanden die iets opleverden en twee waarschuwingen: het meeste komt uit suite-native, dus de mobiele app, en het is een kloon op een moment in de tijd. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
836bc58bd6 |
Er zijn twee relays, en we pakketteerden de zware
De gebruiker droeg evolu.dev/docs/relay aan met de vraag of dat de server is waarop deze app gebaseerd is. Niet dezelfde, wel de bovenstroom, en dat verschil is groot genoeg om het pakket ter discussie te stellen. trezor/trezor-suite-sync is niet Evolu maar Trezor's inzet ervan, met een Postgres en een quota-manager voor hun gehoste dienst. Het project eronder, evoluhq/evolu, heeft een eigen relay: een container, een gepubliceerde image docker.io/evoluhq/relay:latest, een datavolume in plaats van een database, en niets gedocumenteerd over toegangscontrole. De documentatie noemt die relay stateless en geschikt voor serverless. Praat Trezor Suite daarmee, dan vervalt vrijwel alles wat dit pakket ingewikkeld maakt: 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 een. Niet aangenomen en niet gemeten, dus het staat als open punt 6 met de proef erbij: docker run, Suite ernaartoe wijzen, label maken. Dat kost minuten en het antwoord bepaalt of er nog iets aan de huidige vorm verbeterd moet worden. Daarom staat het ook als eerste in "Volgende stap", vóór het nakijken van het databaseschema: dat laatste is weggegooid werk als de kale relay volstaat. Dat het huidige pakket deze laag heeft, is geen fout maar het gevolg van de volgorde waarin het gevonden is. Dat staat er ook zo bij, want anders leest dit over een maand als een verkeerde beslissing in plaats van als een ontdekking. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
60183871f3 |
Prioriteitsherziening: Proefopstelling is ingehaald door zijn eigen uitkomst
Bij het afsluiten van de sessie, zoals het protocol vraagt na een afgerond onderdeel. De installatie van Evolu Relay is geslaagd, en daarmee klopt de aanname onder Proefopstelling niet meer. Dat plan bestond om vragen te beantwoorden voordat er gepakketteerd werd. Fase 1 deed dat en leverde de feiten waar het pakket op rust. Fase 2 en 3 gingen ervan uit dat er nog geen pakket was: lokaal klonen, lokaal draaien, tussen twee apparaten synchroniseren. Dat pakket draait nu op de Umbrel, dus een tweede opstelling ernaast meet minder en kost meer. Wat er overeind blijft zijn twee vragen, en die staan al als blokkade in Umbrelapp: accepteert Trezor Suite een eigen sync-server, en hoe registreer je een eigenaar. Ze staan dus op twee plekken, en dat is precies wat uit elkaar loopt. Niet zelf beslist, want dit gaat over de indeling van het werk en niet over een feit. Het staat als eerste taak in de header van dat plan en in de indexregel, met de twee richtingen erbij: de vragen hierheen halen en Umbrelapp laten wachten, of dit plan opheffen en ze daar beleggen. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
c1ed04db84 |
Evolu Relay draait op de Umbrel
Drie containers omhoog, db gezond, de app-proxy op 3851. De lokale images waren vooraf weggehaald, dus de pull uit het eigen register is echt gedaan en het hele pad is bewezen: broncode van Trezor, bouwrecept, eigen register, gepinde digest, installatie. Open punt 1 is beslist en niet zoals het geformuleerd stond. Daar stond dat lokaal bouwen de eerste stap was en dat een register beslist zou worden "zodra lokaal niet meer volstaat". Lokaal volstaat nooit: umbreld haalt elke image via de Docker Engine API op. Dus geen keuze maar een voorwaarde, en de uitkomst is het Gitea-register op dezelfde server als de store. Nieuw open punt 5, als keerzijde daarvan: de store is publiek en de image staat op een privéserver. Voegt een vreemde deze store toe, dan haalt zijn Umbrel images van de server van de gebruiker, en diens uptime bepaalt of die installatie slaagt. Electrum Gate heeft dat niet, want die draait op images uit Docker Hub. Drie richtingen genoteerd, waaronder disabled: true in het manifest. In PROGRESS staat de fout die twee rondes kostte, met de reden dat hij overtuigend was: app-script noemt een compose pull bij install, en dat leest als het antwoord. Het is de legacy-compat-laag en niet het pad dat umbrelOS 1.x loopt. De les is breder dan deze app en daarom staat hij er. Ook opgeschreven omdat het bij elke herbouw terugkomt: de gebruiker umbrel zit hier niet in de groep docker, dus bouwen vraagt sudo. De kopstructuur van OPEN.md stond na het bijwerken door de war (een tweede kop "Nog te beslissen"); die is weer conform het sjabloon. Tests: niet gedraaid, dit raakt alleen documentatie. 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> |
||
|
HarmenandClaude Opus 5
|
1a87a45685 |
De bovenstroomse repo gelezen, en twee aannames sneuvelden
De gebruiker wil de Evolu Relay-app meteen pakketteren. Daarvoor moest fase 1 van Proefopstelling eerst af, want een compose schrijven op aannames is precies wat dat plan moet voorkomen. Upstream-evolu-relay.md gaat daarmee van vooronderzoek naar nagetrokken, met een bron-URL per feit. De quota-manager is in de praktijk verplicht, en om een andere reden dan gedacht. Niet omdat de relay hem aanroept: er is geen HTTP-koppeling en geen URL in de configuratie, ze delen alleen de Postgres. Maar isOwnerAllowed() eist een rij in de limietentabel en de quota-manager maakt die rijen. Zonder hem is de relay dus niet open maar dicht voor iedereen. Dat maakt de tweede weg interessant, want een rij is ook met de hand te zetten; de prijs daarvan is schrijven in andermans schema. Er is geen publieke image. Trezor bouwt er wel een maar duwt hem naar een eigen Amazon ECR, en op Docker Hub staat niets. Zelf bouwen en publiceren, of geen app, en dat is een doorlopende verplichting. Bijvangst die een risico wegneemt: datzelfde werkproces bouwt amd64 en arm64, dus de Dockerfile is bovenstrooms bewezen op een Pi. Nieuw risico dat ervoor terugkomt: LICENSE.md is door GitHub geclassificeerd als "other", en zodra je een image publiceert distribueer je hun software. Twee kleinere correcties. De compose van Trezor draait de relay niet, er staan alleen Postgres en Prometheus in; het is een ontwikkelopstelling en wat zij uitrollen staat in .k8s/. En alle processen komen uit één image met per service een ander command, dus het worden geen drie images. Eén tegenspraak blijft staan en is expres niet weggeschreven als feit: .env.sample zegt dat SERVER_ENV=prod authenticatie aanzet, maar in de code die ik las bepaalt die vlag alleen het logniveau en staan de controles onvoorwaardelijk aan. Eén van de twee is achterhaald. Dat is met één keer starten te meten en het staat als taak in fase 2. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
f736787c39 |
Een store-URL wisselen is een herinstallatie, geen update
Open punt 8 stond sinds 19-08 als "niet uitgezocht, en niet aannemen dat het meevalt". Beantwoord, en het antwoord is nee: een geïnstalleerde app overleeft een wisseling van store-URL niet. Wat het verraderlijk maakt is de vorm waarin het misging. umbrelOS tóónde de update naar 0.0.15 gewoon, en voerde hem daarna niet uit, zonder foutmelding. "De update wordt gezien" leest als "de koppeling ligt er" en dat is precies wat het niet betekent: tonen en ophalen gaan niet langs dezelfde weg, en de herkomst van een geïnstalleerde app blijft de store waaruit hij kwam. Een gelijk app-id in een andere store maakt daar geen dezelfde app van. Deïnstalleren plus opnieuw installeren loste het op en de app draait weer. De prijs is app-data, dus de certificaatkeuze moest opnieuw gemaakt worden; wie een certificaat had geüpload in plaats van uit Zoraxy te kiezen, moet data/certs/ vooraf wegkopiëren. Dat staat er nu bij, want dit komt bij het masterplan Publicatie-Gate nog een keer langs: daar verandert het app-id. Gratis meegenomen bewijs: de app komt nog steeds omhoog op een installatie waar nooit een certificaat gekozen is. Dat was de fout die 0.0.3 velde. Verder de Fulcrum-omschakeltest voorzien van de reden dat hij stilligt: de eerste sync van Fulcrum stond op 72%. Omschakelen naar een backend die nog niet klaar is meet de sync en niet de app. Daarmee wacht alles wat in dit plan nog openstaat op iets dat vanzelf komt of ligt het bij de gebruiker; dat staat nu in de header, zodat een volgende sessie niet gaat zoeken naar werk dat er niet is. Tests: niet gedraaid, dit raakt alleen documentatie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
67ed9b603b |
Eén app store, twee apps
umbrelOS leest per store één repo, dus twee apps in twee repo's kan niet. Deze repo is de store en bevat vanaf nu Electrum Gate en het werk aan Evolu Relay. Opgezet als verse repo op verzoek van de gebruiker: de historie van ElectrumTLS en van EvoluRelay komt niet mee. Dat heeft één gevolg dat verder gaat dan opruimen. In de historie van ElectrumTLS staat het domein van de gebruiker en het certificaatpad, van vóór de opschoning van 19-08. Die komt hier niet in. Zolang die repo op de Git-server blijft staan verandert dat niets, dus het weghalen ervan is het laatste stuk van open punt 3 van het plan Appstore, en geen bijzaak. De store zelf hoefde niet te veranderen: store-id whatsnext, en dus blijft het app-id whatsnext-electrum-gate. Dat hangt aan het store-id en niet aan de URL, dus voor umbrelOS is dit dezelfde app in een andere store. Dat de store op 19-08 naar de maker genoemd werd in plaats van naar deze ene app, betaalt zich hier uit. Wat de documentatie betreft is dit één wortel voor beide apps, en dat was de reden om samen te voegen en niet de prijs ervan: de appstore-spec, het pinnen van images en de werkwijze golden al voor allebei en stonden in twee repo's naast elkaar. De kruisverwijzing die daarvoor nodig was (Referenties/Umbrel-appstore.md in de oude EvoluRelay-repo) is verdwenen; wat daarin stond over de plekken waar de relay een ander geval is, staat nu als ontwerp in het masterplan Umbrelapp §4. Botsende namen kregen een achtervoegsel met de app, en alleen die: Publicatie werd Publicatie-Gate en Publicatie-Relay, CHANGELOG.md werd CHANGELOG-electrum-gate.md. Proefopstelling kreeg 007, tussen de twee bestaande nummers, zodat de bovenkant van de reeks op tier-orde blijft staan. CONTINUE_HERE.md heeft een kolom App, maar de tiers lopen over beide apps heen: er is één volgorde van werken. Electrum Gate gaat naar 0.0.15, want website, repo, support, submission en icon wijzen nu naar UmbrelApps en zonder versieverhoging rolt dat niet uit. De release notes leggen aan de gebruiker uit dat hij de store opnieuw moet toevoegen. Of een geïnstalleerde app een wisseling van store-URL overleeft is nog steeds niet uitgezocht; dat blijkt bij het omzetten. Twee dingen in de plannen van Electrum Gate waren door deze verhuizing niet meer waar en zijn bijgewerkt: de taak "de repo hernoemen" in fase 7 is afgevinkt, en de repo-vorm in PLAN.md §4a toonde nog de store-id electrumtls, die al sinds fase 7 achterhaald was. Tests: 39 goed 0 fout en 54 goed 0 fout, niets overgeslagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |