Why Messages Travel Like Files
A natural question to ask is why SecurityNet treats chat messages almost like files.
The answer is surprisingly simple.
I never designed two communication systems.
I designed one.
From the beginning, SecurityNet was built around the idea of moving encrypted information directly between authorised computers.
Whether that information happened to be a document, a spreadsheet, a photograph or a short text message didn't really matter.
They were all simply different kinds of information.
Once encrypted, they all became objects travelling through exactly the same secure communication path.
That may sound like a small design decision.
In reality, it simplified almost everything.
There wasn't one architecture for file transfer and another for messaging.
There wasn't one security model for documents and another for chat.
There was just one communication model.
Build it well once.
Then use it consistently.
I've found that's usually simpler than building several specialised systems that gradually evolve in different directions.
As a result, standard chat messages inside SecurityNet are transmitted using exactly the same mechanism as any other encrypted file.
The message is created.
Encrypted.
Transferred.
Received.
Displayed.
From the application's point of view, the only real difference is what happens at the end.
A document is saved.
A message is displayed.
That consistency also had another advantage.
Whenever I improved the communication engine, everything benefited.
File transfers.
Messages.
Future features.
They were all standing on the same foundation.
I wasn't maintaining separate communication systems that could slowly drift apart over time.
Of course, there is one exception.
Group Chat.
Unlike direct one-to-one communication, Group Chat supports near-instant conversations between multiple participants.
To achieve that, it uses a different communication model.
That's why it has its own privacy explanation and why users must explicitly enable it before using it.
Whenever the architecture changes, I believe the explanation should change as well.
This article isn't really about chat messages.
It's about simplicity.
Engineers sometimes assume that adding another subsystem is the easiest way to add another feature.
I've often found the opposite.
The fewer different systems you build, the easier they are to understand, maintain and trust.
That idea has followed me throughout my career.
Whenever I found myself designing two different ways of solving the same problem, I usually stopped and asked another question.
Do I really need two systems?
More often than not...
The answer was no.
