Why One-to-One Chat Doesn't Use the Same Architecture as Group Chat
After explaining how Group Chat works, it would be reasonable to ask an obvious question.
"If the server can temporarily store encrypted Group Chat messages, why not use exactly the same approach for ordinary one-to-one conversations?"
At first sight, that sounds perfectly reasonable.
In fact, I considered it myself.
However, the two problems were actually very different.
A private conversation involves only two people.
If one person isn't online, there is no need for a central message store.
The encrypted message can simply remain safely on the sender's own computer until the other person becomes available.
Nothing needs to exist anywhere else.
That approach also fits the wider philosophy behind SecurityNet.
Where practical, information should remain under the control of the people who own it.
Introducing central storage for every private conversation would have created another place where information existed.
Even if those messages were encrypted, I wasn't convinced that was necessary.
Originally, I experimented with archiving one-to-one chat messages.
The idea sounded sensible.
Until I started thinking about recovery.
How would users restore an individual conversation?
Where should archived messages live?
How would they know which files belonged where?
The more I explored those questions, the less convinced I became.
Eventually I removed the feature altogether.
That decision taught me something interesting.
Recovering deleted conversations sounds like an obvious convenience.
But every recovery feature comes at a cost.
If you want to recover a deleted message, the message must still exist somewhere.
Perhaps on your own device.
Perhaps in a backup.
Perhaps on a server.
Recovery implies retention.
For one-to-one conversations, I chose a different balance.
If a user deletes a chat, it is gone.
That may occasionally be less convenient, but it also means SecurityNet doesn't need to retain copies simply so they can be recovered later.
Like many decisions in SecurityNet, it came down to choosing where I wanted the balance to lie.
I kept asking myself the same question throughout the development of SecurityNet.
Not:
"What else could I add?"
But:
"What new consequences would this feature create?"
Quite often, the second question produced the better design.
Perhaps that's another principle I've discovered over the years.
Every feature solves one problem.
Sometimes it quietly creates another.
Good software design isn't about adding every possible feature.
It's about deciding which trade-offs are worth making.
Building SecurityNet taught me something I hadn't expected.
I didn't create it by predicting every future requirement from the beginning.
Instead, I created it by listening carefully to the problems I was trying to solve.
