fa0aa6c8d83c0569d6b53723035cd418ac7d3976
19
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 HarmenandClaude Fable 5.1
|
7b3804df89 |
Relay 0.5.6: de eigenaars op volgorde van laatst gezien
Meest recent bovenaan, in beide kaders en over de groepen heen. De rijen stonden in de volgorde van het bestand, dus van binnenkomst. De volgorde schuift mee zonder herladen: de ronde van vijf seconden bouwt de lijsten toch al opnieuw op. Alleen de pagina, dus geen nieuwe image. Erbij gevonden en als open taak genoteerd: lastSeen wordt alleen bij de verbinding gezet, niet bij een sync erover. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
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
|
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
|
329b4ab947 |
Evolu Relay 0.5.1: de melding bovenaan ging nooit weg
Gemeld door de gebruiker binnen een uur na 0.5.0, op de pagina op zijn eigen Umbrel. "Sent. The relay applies changes within a few seconds." bleef staan tot je de pagina herlaadde, dus ook lang nadat hij niet meer waar was. Een ontbrekende tak: de ronde die elke vijf seconden loopt zette de melding wel aan maar nooit uit. De regel die daaruit volgt en die in het commentaar staat: de melding hoort van de RONDE te zijn en niet van de klik, want alleen de ronde weet of hij nog waar is. Hij verdwijnt nu zodra het relay-proces de opdracht heeft opgepakt, en blijft staan zolang de opdracht in de postbus ligt. Dat is het geval waarin er iets te melden valt, want normaal duurt dat twee seconden. Een weigering is de uitzondering en blijft staan tot de volgende opdracht: het is de enige uitleg die je krijgt van wat er misging, en die mag niet binnen vijf seconden verdwijnen. Met een vlag en niet door naar de klasse van het element te kijken, zoals de vorige versie van deze pagina deed; dan hangt gedrag aan een naam die er ook om opmaakredenen kan staan. Bijvangst: die weigering stond in de neutrale stijl en is nu rood. Een geweigerde opdracht in de neutrale stijl leest als een mededeling. Alleen index.html.template geraakt, dus geen nieuwe image: build.sh blijft op 0.5.0 en het manifest gaat naar 0.5.1. De changelog beweerde sinds diezelfde ochtend dat die twee nummers gelijk gehouden worden; de regel is dat een hogere VERSION een hoger manifest vraagt en niet andersom. Rechtgezet. Beide gedragingen zijn in een browser nagegaan tegen de voorbeeldweergave: de bevestiging is na zeven seconden verborgen, de weigering staat er dan nog. 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
|
0acd315877 |
Het relay-programma is op het apparaat gemeten en werkt
Losgedraaid uit het register, buiten de app om. Het log meldde "learned a new owner", en in /app/data stonden daarna evolu-relay.db van 49152 bytes en owners.json van 241 bytes. Die eerste omvang is exact die van de proef van vanochtend, dus dezelfde elf labels zijn geland. Daarmee is de hele keten gemeten in plaats van aangenomen: isOwnerAllowed wordt aangeroepen met iets wat ons beleid als eigenaar herkent, de leerstand doet wat hij moet doen, en de allowlist gaat naar schijf en overleeft dus een herstart. Dat was het onzekerste deel van het pakket. Onze image declareert geen VOLUME waar die van Evolu dat wel doet. Dat is een bewuste keuze, want de compose bind-mount de map zelf en een gedeclareerd volume levert dan zwerfvolumes op. Gevolg bij een losse proef zonder -v: docker inspect toont geen mounts, en docker diff werkt hier juist wel. Terzijde, want het leek een storing: Suite meldt bij een nieuwe migratie "0 labels migrated successfully, 11 skipped". Uit hun eigen teksten blijkt dat alleen ontbrekende labels worden gekopieerd, dus skipped betekent "stond er al". Nog ongetest: de pagina en de agent. 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
|
89aa06639b |
Het relay-programma: de relay van Evolu met onze eigen allowlist
tools/evolu-relay/src/ bevat nu een eigen programma dat createRelay uit @evolu/nodejs aanroept met de twee terugroepfuncties die het bedoelde uitbreidpunt vormen. De relay zelf komt uit npm en wordt niet nagebouwd of aangepast; de opstartvolgorde is overgenomen uit apps/relay/src/index.ts van Evolu zelf. De opzet is drie bestanden met een harde scheiding, en die scheiding is de reden dat hier iets te testen valt. policy.js bevat het beleid als pure functies: geen bestanden, geen netwerk, geen klok. store.js is de enige plek met schijf erin. index.js doet niets anders dan lezen, doorgeven en opslaan. Het beleid: de eerste eigenaar die zich meldt wordt geleerd, een schakelaar bepaalt of er nog nieuwe bij mogen, en een eigenaar is te blokkeren, alsnog toe te laten of te vergeten. Geweigerde pogingen worden onthouden voor de pagina, afgekapt op twintig, want elke poging is een id dat de ander zelf verzint. Een onleesbaar owners.json wordt opzij geschoven en de app gaat dan dicht in plaats van open: we weten dan niet wie er toegelaten was, en met de leerstand aan zou de eerstvolgende die verbindt de nieuwe eigenaar worden. Met test: node tests/test_limiter.mjs, 60 toetsen, en de toetsen gaan over de guards en niet over het gelukkige pad. De beslissende regel is muteertest gedaan en de juiste toets viel om: een geblokkeerde eigenaar mag er niet alsnog in doordat de leerstand aanstaat. Het bestand is .mjs omdat de repo-root geen package.json heeft en een .js daar als CommonJS gelezen zou worden. build.sh bouwt niet langer de repo van Trezor maar onze eigen Dockerfile, dus git is er niet meer voor nodig en de pin zit nu in package.json. De image is node:24-slim en niet alpine, want better-sqlite3 heeft binaries voor glibc en niet voor musl. Er is nog geen package-lock.json; het script waarschuwt daarvoor en het staat als taak. Onderweg bleek een aanname van vanmiddag fout: de 1 MB uit de gepubliceerde image geldt per schrijfactie en niet per eigenaar. Er valt dus geen labelgeschiedenis tegenaan te lopen. Dat is rechtgezet in het plan en in de naslag, en het getal is overgenomen als bewuste keuze met RELAY_MAX_WRITE_BYTES ernaast. Wat er niet in zit en ook niet gegokt is: data per eigenaar wissen. Het beleid kan een eigenaar vergeten, maar zijn berichten staan in de SQLite van de relay, en dat is andermans schema. Tests: alle vier groen (32, 54, 39 en 60 goed, 0 fout). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
HarmenandClaude Opus 5
|
edb91c4749 |
Het ontwerp van de limiter en de pagina, en de limiter is klein
createRelay uit @evolu/nodejs neemt twee terugroepfuncties, isOwnerAllowed en isOwnerWithinQuota, en Trezor doet in createEvoluRelay.ts zelf niets anders. Hun hele quota-manager met Postgres bestaat alleen om de tabel te vullen die die twee raadplegen. Wij vullen ze met eigen logica en bouwen niets na. Weg 1 uit Bereikbaarheid 4b is daarmee veel goedkoper dan daar aangenomen, en dat is wat de keuze van de gebruiker mogelijk maakt. De logica zoals hij hem formuleerde: de eerste eigenaar die zich meldt wint, een schakelaar bepaalt of er nog nieuwe bij mogen, en data is per eigenaar te wissen. Dat laatste doet het relay-proces zelf, aangestuurd met een vlagbestand vanaf de pagina; geen tweede container die langszij in de SQLite schrijft en geen Docker-socket. Twee feiten uit de broncode van Evolu die het ontwerp sturen en die in de naslag staan met bron. De gepubliceerde image zet isOwnerWithinQuota op 1 MB per eigenaar en laat isOwnerAllowed weg, dus een kale relay is niet volledig ongelimiteerd, maar dat plafond geldt ook voor de echte gebruiker. En de relay-URL van de client bevat een pad dat letterlijk wordt overgenomen, wat een goedkope proxy-controle mogelijk maakt; die is bewust niet genomen nu de allowlist er komt. De poorten gaan om: pagina achter app_proxy met de inlog aan, relay op een eigen gepubliceerde poort waar Zoraxy met TLS naartoe wijst. Dat lost open punt 2 op zonder het bezwaar dat daar stond, en het volgt het patroon dat Electrum Gate in deze repo al gebruikt. De pagina volgt hetzelfde ontwerpsysteem, zonder de Google Fonts-verwijzing eruit. Open punt 8 en 2 zijn beslist, fase 5 staat als takenlijst. De gebruiker heeft de oude installatie van de Umbrel gehaald; er wordt niet geupdatet maar opnieuw gebouwd. 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
|
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
|
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> |