Why Group Chat Uses Temporary Server Storage
By the time I came to design Group Chat, I had already made one principle clear in my own mind.
I didn't want SecurityNet to depend on cloud storage.
That philosophy had shaped almost every feature in the software.
Files travelled directly between authorised users.
Group Folders were synchronised across members' own computers.
Very little information needed to exist anywhere else.
Then I reached Group Chat.
Suddenly, the problem was different.
Unlike a file, a conversation doesn't exist as a single document.
People join at different times.
Some are online.
Others are away from their computers.
Messages arrive in sequence.
The order matters.
A group conversation needs continuity.
I spent quite some time thinking about how to solve that problem without compromising the principles behind SecurityNet.
Eventually I accepted something important.
For Group Chat, temporary central storage wasn't a compromise. It was the right tool for the job.
The server stores only encrypted Group Chat data. Regular one-to-one messages and file transfers are never stored there.
Every Group Chat message is encrypted before it is stored.
The server cannot read the conversation.
It simply holds the encrypted message until every authorised member has received it, or until it is automatically deleted after 30 days.
Just as importantly, Group Chat is entirely optional.
Creating a Group doesn't automatically enrol every member into Group Chat.
Each person chooses whether they wish to participate.
That distinction mattered to me.
Privacy should include the freedom to decide how you communicate.
Again, I realised this was another lesson in software design.
Principles are important.
Dogma is dangerous.
If I had insisted that absolutely nothing could ever be stored centrally, Group Chat would probably never have existed.
Instead, I asked a different question.
"What architecture best solves this particular problem?"
The answer happened to be different from file transfer.
Perhaps that's one of the reasons I enjoyed building SecurityNet.
Every feature forced me to think again.
Sometimes the answer confirmed an earlier decision.
Sometimes it challenged it.
Either way, the software became stronger because every design choice had to justify itself.
There's another important distinction.
Group Chat is the exception.
Not the rule.
Most of SecurityNet is built around direct communication between authorised users.
Group Chat exists because conversations shared by several people have different requirements from sending a file from one person to another.
Recognising that difference allowed me to design each feature for the problem it was solving, rather than forcing every feature into the same architectural pattern.
Perhaps that's the real lesson.
Good software isn't built by applying the same solution everywhere.
It's built by understanding the problem first.
Only then do you choose the architecture.
Some readers may now be wondering why I didn't use exactly the same architecture for ordinary one-to-one chat.
The answer is surprisingly simple—and it reveals another deliberate design decision.
