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>
