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>

Docs/Plannen/Masterplannen/Bereikbaarheid.PLAN.md

@@ -32,6 +32,61 @@ buiten het netwerk niets kan synchroniseren, moet dat binnen het netwerk nog wel
 
 ## 4. Ontwerp
 
+### 4a. Waar het risico wél en niet zit
+
+**Bijgewerkt 25-08-2026**, nadat de gebruiker vroeg of iedereen met kennis van de API zijn labels kan
+opvragen zodra de relay op een domein staat. Dat antwoord is nee, en het verandert waar dit plan over gaat.
+
+**Vertrouwelijkheid is geen probleem, ook niet op een open eindpunt.** Uit één `OwnerSecret` worden met
+SLIP-21 drie onafhankelijke waarden afgeleid: een publieke `OwnerId`, een `OwnerEncryptionKey` die
+ontsleutelt en een `OwnerWriteKey` die schrijven autoriseert. Alleen de eerste gaat naar de relay. De
+beveiliging leunt er dus niet op dat je adres onbekend blijft. Uitgeschreven met bron in
+[Upstream-evolu-relay.md](../../Referenties/Upstream-evolu-relay.md) §1b.
+
+**Het echte risico is misbruik als opslag.** Een kale Evolu-relay kent geen accounts en geen
+toegangscontrole. Wie hem kan bereiken, kan een eigen owner aanmaken en hem als gratis versleutelde opslag
+gebruiken, en je kunt niet zien van wie het is: dat is het ontwerp en geen tekortkoming. Je schijf groeit
+en er is geen knop.
+
+**Dat is met terugwerkende kracht de tweede functie van Trezor's quota-manager**, naast facturering. Wij
+haalden hem eruit omdat hij bij betaalde hosting hoort. Dat klopt, maar dan neem je de misbruikbeheersing
+mee weg.
+
+Gevolg voor dit plan: **de keuze tussen Tailscale en een reverse proxy gaat niet meer over gemak maar over
+of er überhaupt een open eindpunt komt.** Zolang alleen jouw eigen apparaten erbij moeten, is een netwerk
+dat vreemden buiten houdt de simpelste en beste oplossing, en is een publiek domein een risico dat niets
+oplevert.
+
+### 4b. Wil je tóch een open eindpunt, dan is er een eigenaars-allowlist nodig
+
+Voorstel van de gebruiker op 25-08-2026: een eigen quota-manager, met een interface waarin je `OwnerId`'s
+kunt vlaggen en alleen die van jezelf mag schrijven. Dat is de juiste gedachte, en er zijn drie manieren om
+het te doen die sterk in prijs verschillen.
+
+1. **De relay uitbreiden via `createRelay`.** De README van Evolu noemt de Node-bibliotheek
+   `@evolu/nodejs` met een `createRelay`-API, en noemt expliciet "custom logging, **auth**, or tight server
+   integration" als reden om die te gebruiken in plaats van de kant-en-klare image. Dat is het bedoelde
+   uitbreidpunt en vrijwel zeker wat Trezor gedaan heeft. Prijs: je schrijft en onderhoudt een eigen kleine
+   dienst, en je bouwt weer een eigen image. Dan verlies je precies de winst uit open punt 6 van
+   **Umbrelapp**.
+2. **Terug naar de relay van Trezor**, met een eigen interface die rijen in de limietentabel zet in plaats
+   van hun quota-manager. De handhaving bestaat daar al (`isOwnerAllowed`). Prijs: schrijven in andermans
+   schema, dus breekbaar bij elke bovenstroomse wijziging, plus de Postgres en de eigen image terug.
+3. **Geen allowlist, maar het netwerk.** Tailscale of een IP-beperking op de reverse proxy. Grover, want
+   het beperkt wie er mag verbinden en niet welke eigenaar mag schrijven. Voor één huishouden is dat
+   praktisch hetzelfde, en het kost geen regel code.
+
+**Een detail dat optie 1 en 2 lastiger maakt dan ze klinken: je moet je eigen `OwnerId` kennen om hem te
+kunnen vlaggen.** Trezor Suite toont die waarschijnlijk nergens. De uitweg is de allowlist niet te laten
+typen maar te laten leren: **de eerste eigenaar die verbindt wordt toegelaten, de rest geweigerd**, met een
+knop om die keuze te wissen. Dat is dezelfde gedachte als een sleutel die je bij de eerste verbinding
+vastlegt, het vraagt geen interface om een id in te tikken, en het is precies genoeg voor het doel.
+
+**Voorstel: doe optie 3 eerst.** Hij is gratis, hij lost het echte risico op, en hij houdt de deur open
+voor optie 1 als er ooit iemand anders bij moet.
+
+### 4c. De twee wegen naar buiten
+
 Twee wegen, en ze sluiten elkaar niet uit.
 
 **Tailscale.** umbrelOS heeft er een officiële app voor, en het is de weg van de minste weerstand: geen
@@ -65,8 +120,14 @@ daarna controleren dat het thuis nog steeds werkt.
 1. **Welke apparaten moeten buitenshuis kunnen synchroniseren?** Alleen een laptop is iets anders dan een
    telefoon, en het bepaalt of Tailscale volstaat.
    **Moment:** fase 1 · **Eigenaar:** gebruiker
-2. **Eist Trezor Suite TLS?** Zie hierboven.
-   **Moment:** komt uit Proefopstelling · **Eigenaar:** volgt uit dat plan
+2. **Eist Trezor Suite TLS?** - **nee, `http://` volstaat** (25-08-2026). Afgelezen uit de e2e-test van de
+   mobiele app in de broncode van Suite, die `http://10.0.2.2:4000` invult. Daarmee blijft de kale
+   Tailscale-route open en is een certificaat geen voorwaarde. Nog niet met de hand nagedaan, en het is
+   alleen gecontroleerd voor `suite-native`; de desktopversie is niet nagekeken.
+3. **Komt er een eigenaars-allowlist, en zo ja welke van de drie uit §4b?**
+   Alleen aan de orde als er een open eindpunt komt. Bij Tailscale of een IP-beperking is de vraag niet
+   nodig, en dat is meteen het argument om daarmee te beginnen.
+   **Moment:** pas als fase 1 uitwijst dat een apparaat geen Tailscale kan draaien · **Eigenaar:** gebruiker
 
 ## 7. Verificatie