Why Group Chat Is Different
One of the advantages of building software over a long period of time is that features rarely appear overnight.
They evolve.
One idea leads naturally to another.
Sometimes those ideas fit perfectly into the existing architecture.
Sometimes they don't.
Group Chat turned out to be one of those exceptions.
Long before Group Chat existed, SecurityNet already allowed users to send files to multiple people at the same time.
That capability grew naturally from the original communication model.
Sending one encrypted file to several authorised users simply meant repeating the same secure process for each recipient.
The architecture didn't need to change.
It was still direct communication between authorised computers.
The next step seemed equally straightforward.
Instead of selecting several individual contacts every time, why not allow users to create Groups?
A Group was really nothing more than a collection of authorised users.
When a file was sent to the Group, every member received exactly the same encrypted copy.
Each member also had their own local Group folder, allowing everyone to work with the same shared files without introducing a permanent cloud repository.
Again, the original architecture remained intact.
It was simply an extension of the same idea.
At that point, I naturally tried the same approach with chat messages.
The software could send the same message to multiple recipients.
Technically, it worked perfectly.
But the more I used it, the less I liked it.
The problem wasn't the software.
The problem was the conversation.
As soon as people started replying, the message trail immediately fragmented.
John replied.
Mary didn't.
Someone else responded the following day.
Instead of one conversation, I had several unrelated conversations that all happened to begin with the same message.
I realised I hadn't created Group Chat at all.
I'd simply broadcast the same message to several individuals.
In the end, I removed the feature.
Not because it failed technically.
Because it failed conceptually.
That distinction became one of the most important lessons of the entire project.
Sometimes software works exactly as designed while still solving the wrong problem.
Only then did I begin thinking about what Group Chat really was.
It wasn't another version of direct messaging.
It was a completely different way for people to communicate.
People expected to share a single conversation.
They expected everyone to see the same discussion as it evolved.
That required a different communication model.
For the first time since starting SecurityNet, I accepted that the original architecture was no longer enough.
Introducing that new communication model also brought a new responsibility.
I didn't want to pretend that Group Chat behaved exactly like SecurityNet's standard peer-to-peer communication.
It didn't.
So I made that difference explicit.
Group Chat is disabled by default.
Every participant decides individually whether to enable it.
Simply joining a Group does not automatically enable Group Chat.
Each member makes that decision for themselves in their own password-protected settings.
Only then does the feature become available.
The documentation explains exactly how the privacy model differs from standard one-to-one communication.
Nothing is hidden.
The trade-off is part of the design.
Interestingly, a Group doesn't have to consist of dozens of people.
It can contain only two.
Those two people may simply prefer the immediacy of a shared conversation rather than exchanging individual messages.
Neither communication model is better.
They're solving different problems.
The important thing is that users understand which model they're choosing.
The user interface quietly reflects those architectural decisions.
When sending files, SecurityNet allows you to choose either individual Contacts or Groups because both operations use the same underlying communication model.
Chat is different.
A direct chat is always between two authorised users.
Group Chat is a shared conversation for every participating member.
The menus don't hide those differences.
They reflect them.
To me, good software should make the underlying behaviour easier to understand rather than disguising it.
I don't think Group Chat weakened the philosophy behind SecurityNet.
Quite the opposite.
It reinforced it.
The easy option would have been to hide the architectural difference and hope nobody noticed.
Instead, I accepted that this feature genuinely required a different solution, documented the difference, and gave every user the choice of whether to use it.
That felt like the more honest approach.
Sometimes good engineering isn't about avoiding exceptions.
It's about recognising them.
More importantly...
It's about explaining them.
