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/Referenties/Upstream-evolu-relay.md

@@ -84,6 +84,53 @@ doorgeefluik voor versleutelde wijzigingen. Volgens Trezor is de data client-sid
 dus de relay ziet niets leesbaars. **Zelf hosten haalt Trezor uit de vergelijking, het verandert de
 privacygaranties niet.**
 
+## 1b. Wat een relay is, wat hij ziet, en waarom hij niets hoeft te vertrouwen
+
+Uitgezocht op 25-08-2026 op de vraag van de gebruiker of iemand met kennis van de API de labels kan
+opvragen als de relay op een domein staat. Bronnen: [evolu.dev/docs/privacy](https://www.evolu.dev/docs/privacy),
+[Owner](https://www.evolu.dev/docs/api-reference/common/local-first/Owner) en
+[Protocol](https://www.evolu.dev/docs/api-reference/common/local-first/Protocol).
+
+**Het is geen key-value-store.** De cliënt houdt zijn eigen SQLite bij; de relay bewaart versleutelde
+CRDT-berichten per eigenaar en helpt twee kanten met range-based set reconciliation uitzoeken wat ze
+allebei al hebben. Dichter bij een append-only berichtenlog dan bij een sleutel-waardetabel.
+
+**Wat de relay ziet:** een `OwnerId`, tijdstempels, IP-adressen, en versleutelde blobs die gevuld zijn om
+hun omvang te verhullen. Meer niet.
+
+**Drie waarden, met SLIP-21 afgeleid uit één `OwnerSecret`:**
+
+| Waarde | Wat het doet |
+|-|-|
+| `OwnerId` | de **publieke** identificatie |
+| `OwnerEncryptionKey` | ontsleutelt de data |
+| `OwnerWriteKey` | rotatable token dat schrijven autoriseert; zonder is een cliënt `ReadonlyOwner` |
+
+**Het antwoord op de vraag is dus nee**, en de reden is scherper dan "het is versleuteld". De `OwnerId` is
+expres niet geheim: hij gaat onversleuteld naar de relay en de beheerder ziet hem. De beveiliging leunt er
+niet op dat niemand hem kent. Dat is het tegenovergestelde van een systeem waar een onraadbare URL de grens
+is, en het is precies waarom je deze relay bij een onbekende partij kunt neerzetten.
+
+Dat de drie waarden **onafhankelijk** zijn, is wat dat mogelijk maakt: je geeft de relay je identiteit
+zonder iets over je sleutel prijs te geven, en je kunt de write key roteren zonder je identiteit te
+verliezen. De protocol-documentatie zegt dat de write key gecontroleerd wordt **vóór** het verwerken van
+berichten.
+
+**Twee dingen die hier níet uit volgen, en die je niet moet gladstrijken:**
+
+1. **Of iemand die een `OwnerId` kent de versleutelde blobs kan ophálen, staat nergens.** De
+   protocolpagina zwijgt erover. Kan het, dan leert zo iemand dat die eigenaar bestaat, wanneer hij actief
+   is en bij benadering hoeveel data er is. Niet de inhoud.
+2. **Onraadbaarheid van de `OwnerId` beschermt tegen aflopen van de relay, niet tegen lezen.** Het is
+   verkeersbescherming en geen vertrouwelijkheid.
+
+**En het echte risico van een publieke relay is een ander dan vertrouwelijkheid: misbruik als opslag.** Een
+kale Evolu-relay kent geen accounts en geen toegangscontrole, dus iedereen kan een eigen owner aanmaken en
+hem als gratis versleutelde opslag gebruiken. Je schijf groeit en je kunt niet zien van wie het is, want
+dat is nu juist het ontwerp. Dit verklaart met terugwerkende kracht waarom Trezor een quota-manager heeft:
+die is niet alleen voor facturering maar ook hun misbruikbeheersing. Wie hem eruit haalt, haalt die tweede
+functie mee weg. Zie het masterplan **Bereikbaarheid**.
+
 ## 2. Eén codebase, vier processen, en een compose die de app niet draait
 
 **Correctie op het vooronderzoek.** Daar stond dat er een `Dockerfile` en een `docker-compose.yaml` in de