-
Notifications
You must be signed in to change notification settings - Fork 131
Quiet FAQ
No, Quiet has not yet been audited, and you should not use it in situations where security or privacy are critical.
No! We don't believe in forcing users to choose between running their own server and trusting someone else's, so we made Quiet fully peer-to-peer.
Quiet uses the Tor network, specifically its guard nodes and relay nodes. (Those are servers in a sense, though not in the typical sense.) Quiet also uses Github to deliver updated versions of Quiet. Other than that, Quiet is fully peer-to-peer.
No, only Tor onion addresses.
Members of a Quiet community (analogous to a Slack organization or a Discord "server") use libp2p/IPFS to connect to each other, over Tor, in an insular network for a specific community.
No. Each community creates its own totally isolated IPFS network, with members connecting over Tor.
If not done carefully, decentralized tools can quickly become less private than centralized alternatives. Tor is essential to achieving a baseline level of privacy in Quiet because it gives us clear guarantees that make reasoning about the privacy properties of the overall system much easier.
IP addresses can reveal a lot of information. They could reveal where you live, where you are now, and your approximate movements throughout the day, as well as your institutional affiliation if you are connecting via an academic or company network. In a centralized messaging app, everyone connects through a central server, so this information is only revealed to the server, which can use it responsibly. They might reveal it to advertisers or government, but not to random users. However, in a peer-to-peer network, an IP address could easily be revealed to many or all random users.
A user of a messaging app would not expect to reveal their approximate location, educator, and/or employer to other random users. Nor would they expect to be sued by a copyright troll over an image posted by someone else. But a decentralized messaging app that exposes user IP addresses could do both of these things.
Without something like Tor (or a VPN) a decentralized messaging app would be less private and worse than its centralized competitor, leaking this sensitive IP address information. As everyone who has ever received a warning letter for using Bittorrent knows, this can be quite an unpleasant surprise. Decentralized apps need Tor (or something like it) not for "dark web" style anonymity—they need it to just maintain parity with the built-in privacy of centralized apps like Slack and Discord.
Tor also makes NAT traversal and peer discovery much simpler and more reliable, because Tor onion addresses travel with users as they move between networks, and because anyone connected to the Tor network can receive incoming connections to their onion address. Typically, peer discovery and NAT traversal approaches in peer-to-peer networks leak metadata to centralized services. Tor lets Quiet avoid this.
No. For now, Quiet depends on Tor. However Tor is very reliable, and Quiet is fairly robust to degradation in the Tor network. See: status.torproject.org
It would be straightforward to alter Quiet to not depend on Tor, but most Quiet communities (especially small ones) would need STUN and TURN servers to work correctly. STUN servers are cheap, but TURN servers must relay all data and can be quite costly to run, presenting a significant point of centralization. There would also be a choice of whether to use centralized or decentralized peer discovery. Centralizing peer discovery would be better for privacy, but creates a single point of failure. Decentralized peer discovery would be more robust and accountable but less private, since peers could leak data in unpredictable ways when searching for other peers. Using Tor lets Quiet avoid this dilemma entirely.
We're still collecting data on Quiet's scaling properties. But, for small communities at least, messaging in Quiet feels snappy.
Not yet, but it probably will someday. For example, users could use Snowflake bridges, and community owners could even include a private bridge in the invitation code they provide to new members.
Not yet, but it will. Users will be able to send private direct messages to other users in their community. Messages will be shared to all users in the community, but they will be encrypted to the recipient’s public key. This increases message availability and lets users send messages to others who are currently offline, at the cost of leaking some metadata to other community members. In the future, we can avoid metadata leaks—at some cost to message availability—by putting DM conversations in their own "community".
No. Quiet uses a CRDT called OrbitDB. CRDTs and blockchains both exist to reach consensus between nodes in a distributed system. But a CRDT doesn’t require money, proof-of-work, or proof-of-stake, and in return for these advantages a CRDT cannot do everything a blockchain can. Specifically, a CRDT cannot decide definitively who did what first. This matters a lot for applications like registering a domain name or sending money, but it does not matter as much for messaging. A CRDT can achieve consensus for data whose order doesn’t strictly matter.
While a CRDT can’t put changes in a single, strict order it can still put changes in a branching, relative order, like a threaded conversation on Reddit. Users can prove that a reply was sent after the message it replies to, so the app can provide some guarantees about the order of messages. And it can ensure that all users eventually see the same ordering of messages. This avoids a misunderstandings based around seeing different messaging orderings, even though it does not avoid misunderstandings resulting from the ordering being incorrect. There are also things we can do to the extent a CRDT is ambiguous about the correct order of messages.
These are some methods we could use in combination:
- Use the sender-provided timestamp, within limits.
- Ask the community owner.
- Trust a majority of members or moderators.
- Automatically prompt users to resend undelivered messages from the distant past.
- Warn individual users when ordering is contradictory, e.g. when receiving a future-dated message.
- Use a centralized timestamp server.
Right now, in the simplest, least-secure way possible: each message includes a timestamp and Quiet trusts that these timestamps are correct. We plan to make this more strict. The challenge will be finding a combination of ordering guarantees that cover most cases and can be clearly communicated to users.
Not yet, but future versions of Quiet will allow deleting messages and configuring global retention limits (disappearing messages.)
Not yet, but it will. We have built a proof-of-concept React Native app for Android and iOS and plan to launch mobile apps this year.
For now, unfortunately, yes. We will provide push notifications on iOS for users who want to enable it. Android users will probably not need to use a push notification server.
- Quiet has end-to-end encryption. Slack and Discord do not use end-to-end encryption, so both companies can undetectably read all of your messages, disclose them to a third party who's trying to hurt you, or lose them in a server breach.
- Quiet is free software and accountable to users. Slack and Discord are vastly less accountable to users, because users and independent experts cannot audit their source code or modify it to suit their needs.
- Quiet is fully forkable. Slack and Discord both have near-complete power to prevent users from exiting to alternative apps while continuing to communicate with users who stay. Quiet has no such power; disgruntled users could make a fork of Quiet that was interoperable with Quiet.
- Signal is mature, audited, highly reliable, and built by leaders in the field. We love Signal. If you need a solution to secure communication right now, you should definitely choose Signal over Quiet.
- Quiet is for teams and communities, not individuals. While Signal is analogous to SMS and WhatsApp, Quiet is analogous to Slack or Discord. Quiet lets users join specific communities or teams, each with its own owner and set of channels.
- Quiet doesn't use central servers. Signal uses central servers, while Quiet does not.
- Quiet's metadata protection is verifiable. Most metadata protection in Signal depends on servers maintained by Signal and their infrastructure provider, Amazon, and cannot be independently verified, because server code can be secretly altered at any time. Quiet's metadata protection depends on Tor, which can be independently verified.
- Quiet doesn't reveal phone numbers. A Signal user who has their device seized and unlocked reveals the identity of their contacts to their attackers, but a Quiet user does not. Users can communicate with Quiet without revealing their phone number or personal information to anyone. Signal has plans to let users make accounts without phone numbers, but because Signal offers a global open network where any user can send a message request to any other user, it may be difficult for Signal to address spam once they give up on phone numbers. Because Quiet offers closed networks for communities, Quiet is much more resistant to spam.
- Quiet is fully forkable. Users unhappy with the Signal app or Signal server can take the code and make their own version (fork). But users who fork Signal's server cannot continue communicating with friends still using Signal. Unsatisfied Quiet users, on the other hand, can fork Quiet (or even Tor) without losing access to their friends who use Quiet. This guaranteed freedom to exit makes Quiet more accountable to users than Signal is.
- Quiet would be harder for the US government to shut down. One can envision a crisis sufficiently large that the US executive branch would want to shut down Signal, and would have the political support to do so. They could use court orders or political threats to pressure Amazon AWS, Signal's infrastructure provider, to stop providing service to Signal. They could freeze Signal's bank accounts and threaten to freeze the bank accounts of its largest supporters. Signal could reconstitute itself outside the US in a few weeks, perhaps faster, but losing AWS access and the funds to pay for a comparable alternative would definitely cause downtime, perhaps at a crucial political moment for the US or the world. Quiet does not depend on central servers—or expensive server bills—to function, so it would be harder for the US government to shut down Quiet. Even if they succeeded, users outside the US could reestablish a fully-functional Quiet fork within minutes or hours. Because Quiet is already based on Tor, Quiet developers have many options for making it hard to block.
- Matrix is fully forkable, while also being polished and mature. Like Quiet, users can fork Matrix and still communicate with all existing Matrix apps and servers. Several such apps exist already. Also, Matrix is vastly more mature than Quiet.
- Quiet does not require maintaining or trusting a server. Matrix requires users to set up, secure, and maintain their own server, or trust someone else's server. Quiet works out of the box without the work—or the security risk―of maintaining a server.
- Quiet protects metadata consistently. Matrix gives a user the option of securing some of their metadata by only using servers they control. But few users take this option, and in practice most users must leak metadata to a third parties who are not members of their community, just to communicate. Worse, thanks to federation, a Matrix channel with users on many different "home servers" could leak metadata to many third parties, i.e. the operators of these home servers. Quiet uses Tor to consistently limit what data leaks to third parties.
- Quiet puts users, not server operators, in control. In Matrix, important settings like file storage limits and disappearing messages are left to the control of server operators, not users. Quiet will put all of these features under the control of the community owner, or individual members.
- Quiet can offer a simpler product. Federation can be difficult for users to reason about. Quiet will be able to offer very simple user experiences for community creation and account creation, even for users for whom metadata privacy is critical.
- P2P Matrix—when complete—will benefit from Matrix's maturity and feature set. Matrix is working on a p2p "backend." When ready, it will benefit from the maturity and feature set of Matrix's desktop and mobile apps.
- Quiet is 100% focused on peer-to-peer. Matrix is building a peer-to-peer version, but making peer-to-peer work well for most Matrix users will be a significant amount of work. Given that all of Matrix's paying users are using the federated version, it seems difficult for Matrix to prioritize the experience of P2P-only users, even once a stable P2P option is officially available. Quiet has the advantage of not needing to maintain any sever or UI/UX code related to federation.
- Quiet can offer clear metadata privacy guarantees. Matrix is not using an established and tested solution for metadata privacy protection, and will have to build its own. This will be difficult and will take a lot of time. In the meantime, P2P users will leak significant and unpredictable amounts of metadata to the Internet at large.
- Session works and people are using it. Session seems to have more users and actual product-market fit than any non-federated, decentralized messaging app.
- Session is also fully forkable. Like Quiet, unsatisfied users who fork Session would be able to interoperate with Session.
- Session has a place to store messages for offline users. Quiet communities rely on community members being online, at continuously overlapping times, to ensure message delivery. This could sometimes mean a delay in receiving an important message. Session's network of cryptocurrency-compensated servers makes message delivery between users who are not online at the same time much more reliable. (However, if there are any flaws in Session's approach to onion routing, users will leak metadata to these servers.)
- Quiet uses Tor, while Session uses its own less-established approach. Session protects metadata using its own protocol. While this gives Session flexibility and advantages, Session's protocol lacks the 20+ years of singular focus, institutional experience, scrutiny by academic security researchers, and real-world battle testing that Tor benefits from. This gives Quiet and other Tor-based apps an important, lasting advantage over Session for users seeking privacy.
- Quiet does not require a blockchain or cryptocurrency. Message delivery in Session relies on a network of servers compensated in Session's own cryptocurrency. Quiet uses Tor, which is offered for free and sustained by a growing community of volunteer-run nodes.
- Briar is audited and well-regarded. If you need a Tor-based messaging app for a situation where security is critical, especially for 1:1 messaging, try Briar.
- Briar is also based on Tor. Quiet and Briar have this in common.
- Briar is also fully forkable. Like Quiet, Briar is fully forkable. A fork of Briar by unsatisfied users could easily interoperate with Briar.
- Briar is more like Signal or WhatsApp than Slack or Discord. While Briar does support group chats, communication is based on 1:1 relationships between users, rather than notions of groups with an owner who invites members. So it feels more like Signal or WhatsApp than Slack or Discord.
- Briar supports offline mode. Unlike Quiet, Briar can send messages over the local network or bluetooth in the case of an Internet outage.
- Briar's design makes it cumbersome to invite many people to a group. In Briar you must create a 1:1 relationship with each user before adding them to a group chat. This is easy in Signal and WhatsApp thanks to their use of phone numbers. But in Briar, where adding a user means exchanging a link or QR code, adding everyone individually is cumbersome. Quiet lets you invite a group of people with a single invite code.
- Briar requires a personal server to receive messages sent while you were offline. Briar's solution to asynchronous messaging—delivering messages between users who are not online at the same time—requires each user to set up a "mailbox" (a kind of personal server, designed to run on an always-on mobile device, such as a spare phone.) Because Quiet deals with communities of members, Quiet can use other member devices to store messages and pass them along. This eliminates the need for personal servers. In Quiet, if one community member wants to keep a device running Quiet 24/7, they don't have to set up additional software, and everyone benefits from that without having to take additional steps.
- Cwtch is built by leaders in the field. If you are looking for a secure communication tool based on Tor for an application where security is critical, you should prefer Cwtch to Quiet.
- Cwtch is also based on Tor. Cwtch and Quiet have this in common.
- Cwtch requires servers for group chat, though Cwtch servers can be untrusted and ephemeral. Unlike Quiet, group chat in Cwtch depends on servers, so you need to run your own always-on server or use someone else's server. However, unlike Signal or Matrix, the server is not trusted with metadata, and groups can change their server at will.
- Cwtch is also fully forkable. Like Quiet, a group of unsatisfied Cwtch users could fork it and interoperate with Cwtch servers and Cwtch.
- Berty works for both 1:1 messaging and group messaging. Users can create 1:1 chats and send invite links.
- Berty has a similar tech stack. Like Quiet, Berty uses IPFS and a CRDT.
- By default, Berty uses central servers for some things. Berty uses its own server for peer discovery and relaying data (TURN). Quiet avoids this need by using Tor. Berty might still work without some of these services, but functionality will be degraded. Users can also provide their own servers.
- Berty leaks metadata. For example, Berty users reveal their IP address and location to people they're speaking with, and the graph of which IP addresses are communicating with each other leaks to Berty's own servers or (possibly) every user on the Berty network.
- Berty plans Tor support. Depending on how far they go with it, this could address the metadata problem.
- Berty supports offline mode. Unlike Quiet, Berty can send messages over the local network or bluetooth in the case of an Internet outage.
- Berty has awesome design and branding. Quiet is no ugly duckling either, but Berty looks great, and it's great to see peer-to-peer apps with excellent design and branding.
- Cabal is functionally very similar to Quiet. It is focused exclusively on team chat, and users are invited with an invite link.
- Cabal uses a different but similar stack. Cabal uses DAT / Hypercore where Quiet uses Tor, IPFS, and OrbitDB. Hypercore and IPFS/OrbitDB are functionally similar.
- Cabal leaks metadata. Cabal doesn't use Tor, so users in a Cabal group leak IP addresses to each other, and peer discovery leaks IP addresses, and possibly group membership, to a global network.
- Some users will have difficulty connecting without using a central server. Some peers will be unable to connect without a TURN server. Unless Cabal or Hypercore provides a central server, small groups could have connection problems.