Lewati ke konten utama
Life Security

Cari di situs

Temukan halaman dan bagian.

Types of communication networks

Terakhir diperbarui:

Every messaging app moves your words through some arrangement of computers. Who runs those computers, and how they connect, decides who can see that you messaged someone, when, and how often, even when the message itself is encrypted. This is the network’s design, and it matters as much as the app’s encryption.

There are four common designs: centralized, federated, peer-to-peer, and relay networks built to avoid user accounts. Each one hands trust to a different party and fails in a different way. After reading this you’ll know what each design exposes, why “decentralized” doesn’t mean “private”, and how to pick one for the threat you actually face.

We don’t recommend specific apps here. The ones we name are examples, taken from their own documentation, to show how a design works. We don’t cover how end-to-end encryption itself works or how to compare messengers feature by feature.

What a communication network is, in plain terms

Say Amira wants to message Daniel. Her phone has to find his phone and hand over the message. Even in a simple chat, three questions get answered somewhere: where is Daniel right now, how does the message get there if he’s offline, and who gets to know that the conversation happened?

The IETF’s analysis of centralization, RFC 9518, points out that rendezvous between two parties often needs a third party, which is one reason central points appear in the first place. The four designs below answer those questions differently.

The four designs

Centralized

One organization runs the servers, the software and the rules. Signal is the usual example. Its founder explained the choice in 2016: he argued that federated protocols are hard to change, that he no longer believed a competitive federated messenger could be built, and that protecting metadata would need new protocols “only likely to be possible in centralized environments with more control.” He added that open source infrastructure lets users run their own alternative if the provider makes bad changes (Signal, 2016). That’s one side of a real disagreement, from the person who made the call.

The upside is that the operator can fix problems fast and keep the design consistent. The downside is that one organization, and anyone who can compel it, sees the traffic. What the operator holds depends on what it collects. In a 2021 response to a US search warrant, Signal said it could provide only the time each account was created and the date it last connected (Signal, 2021). Its “sealed sender” feature hides the sender’s identity from the service, but the post says the service still needs to know the recipient, and that timing and IP addresses remain areas of ongoing work (Signal, 2018). Signal still asks for a phone number to register. Usernames are optional and let people reach you without learning your number (Signal Support).

Federated

Many independent servers, run by different people, talk to each other under a shared standard. You pick one server to hold your account, and it exchanges messages with the others. Email is the oldest example: SMTP lets a server accept a message and then act as a client to the next server along the way (RFC 5321, 2008). Matrix works similarly for chat. Each user’s account lives on a homeserver, and a room is replicated across every homeserver that has members in it (Matrix). ActivityPub, a W3C standard since January 2018, does it for social networks, with servers posting activities to each other’s inboxes (W3C).

The upside is choice: you can pick, or run, your own server, and no one company owns the network. The downside is that your server’s operator sees your account activity, and so do the operators of the servers your contacts use. Matrix says this openly. It states that it currently exposes the metadata of who’s talking in which rooms to the admins of the servers involved (Matrix, 2025). The ActivityPub specification, for its part, says that no authentication mechanism was agreed upon at standardization, and we found nothing in it about encrypting direct messages.

Email shows a second limit. The standard for protecting your mail app’s connection to its server, RFC 8314, says it doesn’t address how servers relay mail to each other. And an IETF draft notes that PGP/MIME encryption alone doesn’t protect message headers (IETF draft, 2019, expired and never adopted).

Peer-to-peer

There’s no server in the middle. Devices exchange messages directly with each other. Briar’s project site describes this: it doesn’t rely on a central server, messages sync directly between users’ devices, and contact lists are encrypted and stored on each device. When the internet is up, it syncs over Tor, which the project says keeps eavesdroppers from seeing which users communicate. When it’s down, data can move over Bluetooth, Wi-Fi or memory cards. For people who aren’t online at the same time, a separate Briar Mailbox can relay messages (Briar).

The upside is resilience and censorship resistance: there’s no central server to take down or compel. The downsides are practical. Without a server to hold messages, delivery depends on devices being reachable, and the design leans on extra tools such as Tor and a mailbox to hide who talks to whom. Briar’s own threat model also assumes that a user who can’t keep their device secure is controlled by the attacker.

Relay networks without user accounts

A newer design avoids user identifiers entirely. SimpleX describes itself this way: users have no phone numbers, usernames or public keys assigned to them. Messages move through relay servers using one-way queue addresses, a separate address for each contact, and the servers hold messages only temporarily. The project says servers can’t easily tell who is talking to whom, and that traffic correlation attacks are known (SimpleX). Its comparisons with other designs come from the project itself, and we haven’t verified them independently. You also can’t be contacted without sharing an invitation link or a temporary address.

Tor is a related but different kind of network. It routes traffic through several relays so that no single relay knows both who you are and where you’re going. Our Tor overview explains it.

What each design shows to whom

Design Who carries messages Who can learn who talks to whom Main weakness
Centralized One operator The operator, plus anyone who can compel or breach it One point of control and failure
Federated Many independent servers Each server involved, for its own users and rooms Your privacy depends on servers you don’t pick
Peer-to-peer Users’ own devices Observers of the connections, unless Tor or similar hides them Delivery and metadata protection need extra pieces
Relay, no accounts Relay servers Not easy for a relay to tell, per the project, but correlation attacks are possible Newer, and documented mainly by its own project

What the design can’t do

  • It can’t make a bad endpoint safe. If someone has access to your phone or your contact’s, no network design helps.
  • It can’t remove the need to trust someone. RFC 9518 recommends that standards let users switch providers and limit the power any one party holds, not that they pretend to remove the need for trust.
  • It can’t stop people from joining who you didn’t invite. Open federated networks have to deal with spam, which Matrix names as a known failure mode.
  • It can’t guarantee that “decentralized” turns into decentralized in practice. RFC 9518 says decentralized technology alone does not guarantee decentralized outcomes, because network effects, cost and switching costs can still concentrate users on a few large servers.

Common myths

“Decentralized means private.” It means control is spread out. Each operator in a federated network can see the metadata of its own users, as Matrix says about itself.

“Centralized means insecure.” A central operator is a single point of trust, not a guarantee of weakness. What matters is what it collects and what it can be made to hand over. Signal’s published warrant response shows a very small set of data held.

“End-to-end encryption hides who I talk to.” It protects the content. Delivery still needs an address, and Signal’s own post says the service has to know the recipient.

What to do

These are ordered by how much they help for the least effort.

  1. Decide who you’re hiding from first. A curious stranger, a network operator, a company or a government need different designs. Start with threat modeling.
  2. Pick on what the operator can see, not on the word “decentralized.” Ask what account details and metadata the operator holds, and what its published responses to legal requests show.
  3. If you use a federated service, choose the server on purpose. Your server’s operator sees your activity. Read who runs it and where. Running your own moves the trust to yourself and adds upkeep.
  4. Use a phone-number-free option if your number is the sensitive part. Signal’s usernames and accountless designs like SimpleX address this in different ways, with different trade-offs.
  5. Plan for the day your usual network is blocked. Peer-to-peer tools like Briar and bridge-capable tools like Tor exist for this, but install and test them before you need them.
  6. Use the network your contacts will actually use. A private tool nobody replies on doesn’t protect anyone. Switching costs are part of the security picture.

Sources

Pertanyaan yang sering diajukan