There is no web view in the message pipeline
The single constraint that shaped kvidr more than any other, and the three things it bought once it was non-negotiable.
Most of the design decisions in kvidr trace back to one line written early and never softened: no remote HTML and no remote JavaScript, anywhere in the message pipeline. No WKWebView renders chat content.
It reads like a security rule, and it is one. But its real effect was on everything else.
You cannot borrow the web app’s rendering
The cheap way to build a Talk client is to let the server’s own web UI draw the transcript and wrap it. Rule out the web view and that door closes. Markdown, mentions, links, code, quotes, files and rich objects all have to be rendered as native text.
Which is more work, and then it is better. Native text has real selection, real find, real accessibility and real performance characteristics. One incoming message re-renders one row.
A message has nothing to execute in
Chat content arrives from other people. If it is never HTML in a browser engine, then the whole category of "someone sent a message that ran something" stops applying. Not mitigated — absent.
It forces the layering to stay honest
With no web view doing the heavy lifting, the non-UI half of the app has to stand on its own. It is a Swift package that builds and tests on Linux, with no SwiftUI anywhere in it. The moment something leaks across that boundary, the Linux build says so.
The constraint turned out to be an architecture in disguise. Most of the good ones are.