-
Notifications
You must be signed in to change notification settings - Fork 85
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.
We just haven't implemented that yet. It will soon!
No. Users create a separate account for each community. Each community uses its own separate peer-to-peer network.
Being a member of a Quiet community requires a set of key pairs and a signed cryptographic certificate from the community owner (this includes the account username).
To connect to the community a Quiet user also needs to be able to connect with some other community members. It needs the onion address of a member device that is online or will be online, or it needs its own onion address to be known to another member who is online or will be online. This is not part of the Quiet account per se, but it is necessary to access a community. Whenever Quiet is online it syncs the latest updates to the list of users, and the community owner's onion address is always available as a last resort, so users should not have to worry about peer onion addresses.
Right now you have to make a secure backup of your Quiet folder.
Either by restoring a backup or asking the community owner to invite you (in this case you will have to use a new username.)
When people join a community, Quiet attempts to register their username with the community owner. The community owner's Quiet app, if functioning correctly, will refuse to issue the same username twice. This provides some assurance that usernames are unique, just as they would be in Discord, Telegram, or Instagram.
(A malicious or compromised community owner can let two people register the same username, but any community member who sees this will issue an unmissable, full-screen warning.)
If the community owner is offline, registration will not happen until they return online, so users can remain in an unregistered state. If two unregistered users request the same username (for example, if two people choose the same username before becoming aware of the other's choice) Quiet will show a "duplicate" badge next to the name.
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, educational institution, 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.
- When the community owner Alice sends Bob an invite code, she’s sending him a Tor onion address that points to an onboarding API she’s running.
- When Bob pastes it in and chooses his username, Bob sends Alice a certificate signing request to join the community.
- In response to the request, Alice returns her public key, a signed certificate, and her “real” onion address, which points to the actual closed network.
- Bob will use this certificate to prove to other members that his username is in fact “bob”, and that he is authorized to connect to the network.
- And Bob will use Alice’s “real” onion address to connect to the actual closed network.
- Once Bob connects, he syncs all app state. This means not just messages, but also the list of members, their public keys, and their onion addresses, which he can now use to connect to other members.
- Meanwhile, Alice has added Bob’s information, including his onion address, to the user list, so all other members will sync that, and will be able to connect to Bob in the future.
- At this point, Alice and all other members see a nice message in Quiet that Bob has joined. Onboarding is complete.
- Alice, Bob, and all of our online community members are happily connected over Tor and able to sync state using OrbitDB, the CRDT we use for syncing.
First of all, in current versions of Quiet the community owner must be online for you to join a community, because the invite code is just a Tor onion address that connects to the community owner's device. Future versions of Quiet will be more flexible in this regard, but for now this is how it works.
Second, there's a known issue in Tor where connecting to an onion address is taking much longer than it should. This bug is part of the problem. Tor will probably not fix this until after the transition to Tor's Rust implementation Arti is complete, so it could be a while.
When onboarding is complete we have a closed network of users, all of whom are members of some team or community, who know each others’ onion addresses and public keys, who can all connect to each other, each with a signed certificate from the owner with their username and public key.
To sync state between members we use a CRDT called OrbitDB, which is built on a peer-to-peer data protocol called IPFS, which we force to use Tor, and only connect to the onion addresses of other community members in our closed network. CRDT stands for “Conflict-free Replicated Data Type”. CRDTs can merge state changes between a network of nodes with “eventual consistency,” meaning no matter what changes any node makes, they will all eventually have the same state. OrbitDB is fairly unusual among CRDTs in that it includes all the necessary peer-to-peer plumbing to sync changes.
When someone sends a message, OrbitDB:
- Adds that message to its local state
- Calculates a hash of its new state and
- Broadcasts this hash to other members, using a Gossip Protocol that’s part of IPFS.
A Gossip Protocol is sometimes called an Epidemic Protocol, because it spreads data from one peer, to its neighbors, to their neighbors and so on, until everyone receives it. On the receiving side, whenever OrbitDB sees "gossip" of a hash that it has not yet seen, it knows that there is data it has not yet synced. So it uses this hash like a link to retrieve any new data, any data it links to, and so on, until it has synced everything there is to sync. All of this happens quite fast, despite it being a complex process.
Quiet uses IPFS to send files. IPFS splits files up into blocks and fetches blocks from peers that have them, like BitTorrent. When a user sends a file, IPFS generates a hash of this file, and Quiet adds this hash to a message, like any normal link. When Quiet receives a message with a link to a file in it, Quiet will download the file automatically, or, if the file is over a certain size, let the user initiate the download manually.
Of course, if Quiet does not introduce some limit on the number of messages and especially files, a group's state will grow and grow until it is too big for any user's device.
One great way to limit state is to make messages disappear by default after some number of weeks or months, with the option to save them. So that is what we plan to do. Timed deletion is a feature, not a bug, because it limits harm if a device is seized or compromised!
- 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. Like Quiet, users can fork Matrix and still communicate with all existing Matrix apps and servers. Several such apps exist already.
- Matrix is polished, mature, and has a large user base. Many large teams and organizations use Matrix.
- Matrix supports end-to-end encryption of messages. Like Quiet, Matrix encrypts message data end-to-end, though this can be deactivated (it cannot in 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 built by leaders in the field. 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 lets you join a group with someone without ever letting them connect to you directly. This difference contains really interesting privacy and usability tradeoffs! On advantage is that it gives users more granular control over who they disclose their online status to, which limits the number of people who could link their separate identities or guess their approximate location by observing when they go on and offline. One disadvantage is that group message delivery can become very asynchronous.
- Quiet makes inviting group members much easier. 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.
- Quiet does not require a personal server to receive messages while 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 be run on an always-on mobile device such as a spare phone. Because Quiet deals exclusively with closed communities of members, Quiet can typically rely on other member devices to store messages and pass them along, minimizing the need for personal servers. Also, in Quiet, if one community member does want to keep a device running Quiet 24/7, there is no need to set up any additional software, and everyone benefits from that without having to take additional steps to configure a "mailbox", as they would in Briar.
- Quiet has usernames. Briar uses pet names, not usernames. This contributes to the difficulty of inviting large groups in Briar, as you need to enter a name for each user. Quiet lets new members register a username with the community owner and all online members.
- 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 is also fully forkable. Like Quiet, a group of unsatisfied Cwtch users could fork it and interoperate with Cwtch servers and Cwtch.
- Quiet does not require servers for group chat. 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, a Cwtch server is accessed via Tor and not trusted with metadata, and groups can change their server at will.
- Quiet has usernames. Cwtch uses pet names, not unique usernames. Quiet lets new members register a username with the community owner and all online members.
- Quiet plans to support iOS. At the time of writing, Cwtch says they do not plan to support iOS. Quiet has built a working prototype for iOS and plans to support iOS. For many teams and communities, the absence of iOS support will be a blocker to adopting Cwtch, since only it takes only one committed iOS user to block adoption.
- 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.
- Berty works for both 1:1 messaging and group messaging. Users can create 1:1 chats and send invite links.
- Berty also uses IPFS and a CRDT. Like Quiet, Berty uses IPFS and a CRDT.
- Berty supports offline mode. Unlike Quiet, Berty can send messages over the local network or Bluetooth in the case of an Internet outage.
- Berty plans Tor support. Depending on how far they go with it, this could address the metadata problem, but it is unclear what Berty will use Tor for, and whether Tor support will be the default.
- Quiet protects metadata. Berty users reveal their IP address and location to people they're speaking with. Metadata about who is communicating with who leaks to Berty's own servers or the Internet at large via the peer discovery process.
- Quiet never uses central servers. By default, Berty uses its own server for peer discovery and relaying data (TURN). Quiet avoids this need by using Tor. Berty may still work without these central servers, but functionality will be degraded. Users can also provide their own servers, but few will.
- Cabal's user experience is very similar to Quiet. It is focused exclusively on team chat, and users are invited with an invite link.
- Cabal uses a different but analogous tech stack. Cabal uses DAT / Hypercore where Quiet uses Tor, IPFS, and OrbitDB. Hypercore and IPFS/OrbitDB are functionally similar.
- Quiet protects metadata. Cabal does not 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.
- Quiet can be reliable without central servers. In Cabal, peers will be unable to connect without a TURN server. Unless Cabal or Hypercore provides a central server, small groups could have connection problems. If Cabal does provide a TURN server, that's another place where metadata will leak.
- Quiet has usernames. Cabal uses self-chosen usernames, not unique usernames. Quiet lets new members register a username with the community owner and all online members.
- Ricochet inspired Quiet. The original Ricochet inspired the design of Quiet. We think Ricochet is awesome.
- Ricochet Refresh also uses Tor to protect metadata. Like Quiet, Ricochet uses Tor to protect metadata and encrypt messages.
- Ricochet Refresh is built by leaders in the field. Its team overlaps with the Tor team, so they have deep expertise in building secure software and in metadata protection.*
- Quiet supports group messaging. At this time Ricochet Refresh only supports 1:1 messaging.
- Quiet will support mobile. Quiet plans to support Android and iOS, and has working prototypes for both platforms.