Thanks for your feedback — a couple of your points land and a couple I’d push back on.
On the “good operators vs rogue operators” framing. It collapses three adversaries into two in a way that loses the useful distinction. The rogue operator (actively pushing malicious JS) is one adversary and, as I conceded, the architecture cannot stop them. But there are two others the client-side crypto genuinely does protect against, and neither requires the operator to be rogue:
- Passive compromise — the operator is behaving honestly; the DB just gets dumped in a breach, a backup leaks, or an opportunistic intruder runs
pg_dump. The operator is not the attacker; their data just went somewhere it shouldn’t. This is the most common class of real-world incident. - Future operator — the domain is sold, the business is acquired, I die, the project is handed off, I fall under legal pressure. The current operator’s good behaviour doesn’t bind the next one, but the ciphertext does.
So the irony isn’t quite what it looks like — the defence is against good operators, in the sense that their present-tense good behaviour doesn’t retroactively protect data once a key they never possessed becomes moot to the future state of the system.
“Do you need to persist anything at all?” — you’re right that server-side utility is low. Still: yes, but the minimum.
roomsexists so two users with the same shared phone number can find the same pigeonhole without exchanging a session ID over a side channel. The passcode-test UX (“type a number from your contacts”) requires a durable lookup target.room_accessexists because the 10-attempt lockout onaccess_hashhas to be server-enforced — a client can’t rate-limit itself.messages(single row) exists as a dead-drop: one user writes, the other reads asynchronously. Pure peer-to-peer would require both users online simultaneously, which breaks the medium.
N=1 + encryption means the DB is effectively “a pigeonhole with a rate-limiter.” Every row is as small as I can make it and is hard-deleted on reply or TTL expiry. Zero is the wrong answer; minimum is the design.
Firefox on Windows. Good that the restart helped. The “general feeling of slowness” is probably one of two things:
- PBKDF2 600k iterations at login — ~1.5–2.5s on the main thread, shown behind a loader, happens once per session. Intentional cost per OWASP 2023.
- Glassmorphism
backdrop-filter: blur()— Firefox on Windows has a known perf gap vs Chromium here, especially on older GPUs. No background JS (no service worker, no polling, no web workers), but compositing is more expensive than a flat UI would be.
If you can, a DevTools → Performance recording during a session would pin which one. Happy to dig in if you share the profile (or file an issue).
File sharing / multimedia. Yes, users will ask for it (it’s the most common extension beyond text), and yes, files at rest would make the client-side crypto case more obviously compelling than text alone does.
The blocker isn’t architectural (files encrypt and store fine in the same ciphertext-only model), it’s operator-risk. Once media flows through the service — even encrypted — the operator inherits compliance obligations that a text-only service sidesteps, most critically around CSAM reporting mandates and, indirectly, payment-processor categorisation (image-hosting platforms tend to be treated more strictly regardless of whether the operator can see the content). None of that is insurmountable, but it requires legal backing and content-moderation infrastructure that a solo operation does not yet have.
So: text-only for now because operator-risk doesn’t support multimedia; revisit when that changes.
I tried to visit 