Technology

The cryptographic core of our messenger is written in Rust and kept completely separate from the application. iOS, Android, Windows, macOS and Linux all use the same implementation, behaving identically on every device. A security review therefore covers one place rather than five.

For key exchange and session management we use Messaging Layer Security to RFC 9420, through OpenMLS. The standard detects tampering and guarantees forward secrecy: a key compromised later does not give up earlier messages.

Private keys are created in the operating system's keystore and never leave it. The server handles ciphertext only, so a compromised server does not mean read content.

The recommendation feed on our social media platform ranks in stages. An HNSW vector index on pgvector first narrows the field to the semantically nearest candidates; only then does the more expensive scoring from interest profile, recency, popularity and diversity come into play. Compute time therefore stays near constant, however large the overall corpus becomes.

We lay out data structures so that millions of posts can be held and the relevant ones found without scanning the whole database.

Anything that does not have to finish immediately goes through a queue: media processing, analysis, delivery. A spike then lengthens a queue rather than degrading response times.

Every upload on our platform passes through a multi-stage analysis. CLIP ViT-L/14 turns the image into a 768-dimensional embedding, a captioning model produces text and keywords, and a classifier flags sensitive content.

For object detection we work with YOLO11 and Faster R-CNN, for anomaly detection with PatchCore. Which method is used is decided by measurements on the real data, not by the model's reputation.

Training runs locally on our own hardware with CUDA. Checkpoints are kept so a run resumes rather than restarts, and every change is measured against the same test set, so the numbers stay comparable across weeks.

Scheduled work runs through Cloud Tasks. Every planned operation gets its own task with an exact firing time, up to 30 days ahead. The task name is derived deterministically, which makes creation itself idempotent: two triggers produce the same task, not two.

Queues deliver at least once by design. Without a further safeguard that turns into double execution, so every operation additionally releases the work exactly once.

Files sit content-addressed in S3-compatible object storage and are delivered through a content delivery network. Where data must not leave the house, the same thing runs on our own servers.

We work with both Flutter and React Native. Each has strengths that decide it depending on the project: close binding to existing native code, demands on how it has to look, and the knowledge already present in the client's team.

Large lists are rendered virtualised and prefetched ahead of the scroll. Only what is actually needed goes over the wire, so even very large collections stay fluid on a phone.

Release to the App Store and Google Play is part of it: certificates and signing, the review requirements, and updates and crash reporting after launch.

Our own servers make sense where regulation or a contract demands it, where the volume of data makes the cloud expensive, or where a computation that runs continuously is cheaper on owned hardware than on rented. Training our models is exactly that case.

We run both and mix them where it fits: compute-heavy work and sensitive data in the house, worldwide delivery through a content delivery network. What runs where is decided per project, not as a matter of principle.