I started Halonyx with a question that felt complete: how do I build a secure messaging system?
The answer looked like a checklist. End-to-end encryption. Authenticated key exchange. Decentralised transport. Hard problems, but well-defined ones.
Two things broke that framing.
The first was a talk on the engineering of chat applications - how small interface decisions like read receipts, presence indicators, or what the Enter key does quietly change how people behave. The second was an interview with Meredith Whittaker on surveillance, AI, and the power of data-driven systems. It moved my attention from whether someone can read a message to what happens when communication becomes data, data becomes a profile, and a profile becomes an input to someone else's decision.
Both gave me questions. Neither gave me an architecture.
So I rewrote the one I had.
The wrong frame: privacy as secrecy
The usual defence of privacy is a defence of secrets, which is why "I have nothing to hide" feels like a reasonable reply. It's the wrong reply to the wrong argument.
I can have nothing illegal to hide and still want a private conversation. I can float an unfinished idea without it entering a permanent record. I can vent when I'm frustrated and change my mind the next day. I can discuss a personal problem with one colleague without my manager, my organisation, or some future classifier interpreting it.
Privacy is the ability to think, experiment, make mistakes, and revise without every step becoming permanently observable. It preserves context and autonomy.
That is a much higher standard than "messages are encrypted."
Interfaces are behavioural decisions
Communication software doesn't just carry messages. It shapes the conversation.
A read receipt is technically trivial and socially loaded. Once I can see that you read my message at 10:42 PM, your silence becomes a signal I'll interpret. Between friends that's an annoyance. Between a manager and an employee it's pressure. The same feature produces different consequences depending on who holds power in the conversation.
The same logic runs across the feature list:
- Read receipts create an expectation of reply
- Presence creates an expectation of availability and leaks working schedules
- Persistence makes people more guarded about what they say
- Search turns a conversation people would naturally forget into one that can be retrieved on demand Every feature in Halonyx now gets two questions. Not only can I implement this? but what behaviour will it encourage, and is the exposure worth it?
That translates into defaults, not slogans: read receipts off by default, configurable per conversation, and symmetric - hiding yours also hides theirs. Presence is coarse and opt-in, with no "last seen" timestamps. No administrator can override either setting.
Encryption is the floor, not the ceiling
Halonyx uses the Signal Protocol - X3DH for key agreement, Double Ratchet for per-message keys. That protects content, and I treat it as non-negotiable. But it answers only one question: who can read the message.
The system still knows things. It helps to separate them into three tiers:
| Tier | Example | Origin |
|---|---|---|
| Provided | "I'm working on Project X." | The user said it |
| Derived | "I message frequently about Project X." | Computed from activity |
| Inferred | "I may be under unusual work pressure." | A conclusion the user never stated |
The third tier is the dangerous one. I never said it - yet a system can generate it, store it, and hand it to someone with authority over me.
It gets worse when fields combine. Timestamps, presence, group membership, and message frequency each look harmless. Together they describe who works with whom, which projects are heating up, when someone's routine changed, and which relationships exist. None of it requires reading a single message.
There's a second trap: treating data as reality. If a system records that I sent 500 messages this month, that's a fact about activity, not about me. I may have been coordinating a launch. Someone who sent 50 may have been doing deep, uninterrupted work. Turning message count into a productivity score quietly swaps a signal for a person.
What the server knows - and what it shouldn't
Principles are cheap, so here's what they mean in architecture. These are Halonyx's design targets, each with the limit I'm honest about hitting:
| What leaks | Design response | Honest residual |
|---|---|---|
| Who is talking to whom | Sealed-sender-style delivery - server routes without knowing sender | Server still sees recipient and timing |
| Presence | Ephemeral, scoped to peers who need it, never written to storage | Peers observe activity while connected |
| Search | Local encrypted index on each device, queries never leave it | No server-side history search; multi-device sync costs more |
| Message storage | Encrypted blobs held until delivery, then deleted | Devices and backups may retain more |
| File transfer | WebTorrent P2P - server never sees file content | WebRTC exposes IP addresses via STUN |
The right-hand column is on purpose. A privacy claim that doesn't state its limits is marketing.
Decentralisation in particular does not equal privacy. A federated network can leak membership, identity, and network information to more parties, not fewer. It reduces dependence on one authority. It does not remove the need for the other protections.
There is also a security argument hiding here. Every piece of data a system stores has to be encrypted, synchronised, backed up, audited, retained, and eventually deleted. Data that was never collected can't be breached, subpoenaed, or repurposed.
The safest information is the information the system never possessed.
AI and minimum necessary context
AI changes the economics of old data. A human cannot read millions of messages, but a model can summarise, classify, correlate, and search them. Data that is harmless today becomes more revealing every time capabilities improve.
"Storage is cheap, so keep everything" is a bet that nothing you keep will ever become dangerous. I don't want to make that bet for other people.
The common pattern looks like this:
Collect everything → Give it all to the AI → Let the AI decide what matters
Halonyx inverts it:
Define the need → Select minimum context → Process → Discard what was temporary
In practice that means:
- Local first. If summarisation or filtering can run on the device, it runs on the device.
- Scoped by request. A summary of one conversation sees one conversation.
- User-initiated and ephemeral. When something has to leave the device, the user triggers it and nothing is retained.
- No "for AI later." Capability never justifies collection. Some features will be worse as a result. That is the price, and I accept it.
Workplace communication is a power relationship
Halonyx is meant for teams, and that changes the stakes. Information shared between two colleagues becomes a different thing once someone with authority over one of them can see it.
So every capability gets a harder question: who gains power from having it?
| Security administration (legitimate) | Behavioural surveillance (out of bounds) |
|---|---|
| Authentication and authorisation | Productivity scoring |
| Account protection | Emotional or sentiment monitoring |
| Abuse and malware detection | Personality profiling |
| Incident response | Hidden relationship mapping |
| System integrity | Blanket analysis of private conversations |
The left column keeps the system running and safe. The right column turns a communication tool into an authority on the people using it. A profile generated from communication data is an interpretation, not the person - and it can be incomplete, or simply wrong.
Where the principles collide
A philosophy that never meets a conflict hasn't been tested.
Compliance vs. limited retention. Some organisations are legally required to keep records. Halonyx's answer: retention is a declared property of a space, not a hidden database default. A project channel can be designated a records space. Direct messages are outside the archive by default. Retention rules are visible in the space itself, and any change is announced to members.
Administrator control vs. user agency. Administrators set policy. They can configure retention, remove members, and revoke devices. They cannot silently read content. Control over the system is not the same as access to the conversations.
Disappearing messages vs. reality. Screenshots and device backups exist. Disappearing messages change the default from "permanent unless deleted" to "gone unless there's a reason to keep it" - which is valuable, but not a guarantee. The interface should say so.
What Halonyx will never do
Most product documents list what a product can do. I want Halonyx to publish what it refuses to do, because a boundary that is written down is harder to erode.
- It will not compute productivity, sentiment, or personality scores from message data.
- It will not give administrators silent access to private conversations.
- It will not collect data on the grounds that it might be useful for AI later.
- It will not expose last-seen times or read status by default.
- It will not build relationship graphs for third parties.
- It will not change any of the above without a public, visible announcement.
Less trust required
The strongest form of privacy is not a promise. If the server can decrypt messages, users must trust it not to read them. If it stores rich metadata, they must trust everyone who can reach that store. If an AI service receives whole conversations, they must trust it too.
The goal of Halonyx's architecture is to reduce what has to be trusted. Instead of "trust us," the claim becomes: the system is built so that there is less for us to access in the first place.
I don't think privacy means a system should know nothing. A working platform needs some information, and organisations have real security obligations. What matters is that those needs are named, limited, and technically constrained - rather than left open because collecting more was easy.
The goal is not to build the communication platform that knows the most about its users.
It is to build the one that stays useful without needing to.
Halonyx is open source under AGPL-3.0.
GitHub: github.com/ABHIRAM-CREATOR06/Halonyx
Previous writeup on the technical implementation: I Built a Signal Protocol Messenger from Scratch
Top comments (0)