Why private peer-to-peer messaging is the right shape for team comms.
There is a pattern in how every mainstream team chat tool gets built: the first unit is a room. You create a workspace, you create a channel, you invite people into it, and every conversation becomes a message posted somewhere. The contact — the one person on the other end — is always derived. You message them by opening a DM panel that is itself a kind of miniature, hidden room.
This made sense ten years ago when the reference model was IRC. It stopped making sense the moment most real work moved to a handful of senior collaborators who talk to each other every day and treat rooms as a cost rather than a home. If you watch how a tight team actually communicates, the 1:1 channel is the primary surface. Rooms are where announcements go to be searchable later.
The model we kept reaching for
When we started Vector, we wrote down the shape we wanted on a whiteboard and it came out in two sentences. A contact is a person you can reach privately, peer-to-peer, without a server in the middle holding the conversation. A room is a separate flow: multi-party, with its own permissions, its own audit surface, and its own retention story.
Splitting these two concepts — instead of making one a degenerate case of the other — turned out to simplify almost every downstream decision. The product shape stops fighting the mental model. Security review stops needing to explain why your DMs traverse the same storage as your announcements. And the failure modes get cleaner: a compromised room does not leak a 1:1 thread, because the 1:1 thread never lived on the room's substrate.
What changes when contacts are real
- Identity is pairwise. Two people who added each other have a shared key and a conversation history that is theirs. No workspace admin can read it, because there is no workspace in the path.
- Offboarding is a per-room operation, not a per-person one. When someone leaves a room, nothing happens to the 1:1 threads they built on the way — those belong to the two parties, not to the employer.
- Compliance scopes itself. Rooms can be retained, audited, and discovered on the terms of the organization that owns them. 1:1 contacts are not the organization's to retain in the first place.
- Abuse surfaces shrink. If you cannot spam a room you were not invited to, and you cannot DM a contact who has not accepted you, the attack graph gets smaller by construction.
A contact is not a one-member room. It is a different object, with different guarantees. Treat it that way and the platform gets simpler.
The honest tradeoff
The argument against this shape is the argument for it, inverted. If your organization wants every conversation to be corporate property by default, private peer-to-peer contacts are friction. You have to educate people on which surface they are in, you have to ship two flows instead of one, and you lose the tidy story where search returns everything.
We think that tradeoff is worth taking. The alternative — rooms everywhere, with pretend-private DMs layered on top — produces a product that lies about what it is. People intuit that their 1:1 messages are not really private, adjust their behavior accordingly, and the candor that makes a team worth working in quietly drains out. You end up with a searchable archive of messages nobody wanted to send in the first place.
Where this lands in the roadmap
In Vector, the contact and the room are separate screens, separate data flows, and separate encryption stories. We did not ship it that way to make a point. We shipped it that way because every time we tried to collapse the two, something in the product started feeling dishonest. When a design keeps resisting you, that is usually the design telling you something.
If you are building team communications — yours, or your customer's — the question we would ask before anything else is which of the two flows your product is actually about. The rest follows from there.