Building an architecture of restraint: Technical trade-offs in MyOnne

When we started engineering MyOnne, the mandate was simple: build a messaging platform for two. We quickly realized that standard database architectures, built around User records and many-to-many relationship tables, were a liability. We needed an architecture that literally could not understand a social graph.

This engineering note explores the technical decisions behind MyOnne's pair-locked protocol. We will look at our data schema, the cryptographic handshake that replaces traditional user accounts, and why removing public profiles was a technical necessity, not just a design choice.

The Problem with User IDs

Most social platforms use a schema similar to `Users -> Relations -> Users`. Even if message payloads are encrypted, the server still maps who talks to whom. This metadata is highly revealing.

To solve this, we eliminated the `User` object entirely from our backend. Instead, we use a `Pair` object.

The Pair Handshake

If there are no user accounts, how do two devices connect? We use an out-of-band cryptographic handshake. When Device A wants to connect to Device B, it generates a unique, single-use invite link containing a public key fragment.

Once Device B scans the code, the two devices negotiate a shared secret. They then register a new `PairId` with our relay servers. From the server's perspective, a new anonymous pipe just opened. We don't know who is on either end.

The Trade-offs: Why No Public Profiles?

This architecture forces severe constraints. Without individual user IDs, we physically cannot build a 'Public Profile' or a 'Search for User' feature. The data simply doesn't exist.

Furthermore, this makes device synchronization incredibly complex. Since the server doesn't know 'you' exist as an individual, adding an iPad or a desktop client requires a complex multi-device sync protocol entirely mediated by your primary phone, acting as a local server.

We accepted that our backend would be stupid by design. It routes encrypted blobs between anonymous pairs. Nothing more.

Minimizing Metadata in Transit

We also applied restraint to our logging infrastructure. Traditional request logs include IP addresses and user agents. Our ingestion layer strips IPs immediately, keeping only coarse-grained geographic data for load balancing. Our databases are configured to routinely prune `PairIds` that have been inactive, ensuring that stale relationships fade into nothingness.

Building an architecture of restraint isn't just about what you encrypt; it's about fundamentally refusing to collect the data that makes the modern internet profitable. It's harder to build, but it's the only way to guarantee a truly private space.