quiet

Quiet

Encrypted p2p team chat with no servers, just Tor.
Downloads | How it Works | Features | Threat Model | Mission | FAQ | Developer setup

Quiet is an alternative to team chat apps like Slack, Discord, and Element that does not require trusting a central server or running one's own. In Quiet, all data syncs directly between a team's devices over Tor with no server required.

> NOTE: Quiet is not audited and should not be used when privacy and security are critical. It lacks basic features and probably won't replace your Slack or Discord yet. That said, it works surprisingly well and we use it daily as a Slack replacement. Quiet is for fans of software freedom, decentralization and privacy tech, and for anyone craving a future where humanity can collaborate effectively online without trusting our communities, networks, and data to giant corporations. **Quiet is written (mostly) in TypeScript, with Electron and React Native frontends, and welcomes outside contributions! See: [Contributing to Quiet](#contributing-to-quiet)**

## How it works While apps like Slack, Discord, and Signal use central servers, Quiet syncs messages directly between a team's devices, over Tor, with no server required. Each group of people (Quiet calls them "communities") gets their own insular network, so that data from one community never touches the devices of Quiet users in *other* communities. Not even in encrypted form! Message syncing is taken care of by a project called [OrbitDB](https://orbitdb.org), which works like a mashup of Git, a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol), and [BitTorrent](https://en.wikipedia.org/wiki/BitTorrent); it broadcasts new messages, syncs the latest messages, and fetches files. Syncing means that users typically receive all messages sent while they were offline. Invites, access, and usernames are granted by a community owner, i.e. whoever creates the community. The owner hands out an "invitation code" which invitees use to connect to the owner's device, register a username, and get a standard cryptographic certificate so they can prove to other peers they're part of the community. See our [FAQ](https://github.com/TryQuiet/monorepo/wiki/Quiet-FAQ) for answers to common questions and a comparison of Quiet with similar apps. ## Getting started To try Quiet, download the [latest release](https://tryquiet.org/#Downloads) for your platform (.dmg for macOS, .exe for Windows, etc.) and install it in the normal way. Then create a community and open the community's settings to invite members. If you'd like to help develop Quiet, see [Contributing to Quiet](#contributing-to-quiet). ## Features * **Team Chat** - Create a "community" for your team or organization and invite members. * **End-to-end Encryption** - All data is encrypted end-to-end between member devices. * **Channels** - Organize chats in Slack-like channels. * **Images** - Send and receive images, with copy/paste, drag & drop, and image previews. * **Files** - Send and receive giant files without arbitrary limits. * **Notifications** - Get desktop notifications for new messages, with optional sounds. * **Invite links** - Share invite links, just like in WhatsApp, Signal, or Discord. * **Keyboard Controls** - Navigate channels without using the mouse. * **Desktop Apps** - Desktop apps for Mac, Windows, and Linux. * **Android App** - A fully peer-to-peer Android app with working notifications. * **iOS App** - A fully peer-to-peer iOS app (TestFlight) without notifications. * **No email or phone number required** - Unlike Slack, Discord, WhatsApp, Telegram, and Signal, no email or phone number is required to create or join a community. ## Planned (but still-missing) features * **iOS Notifications** - Receive notifications on iOS, with help from a service Apple requires to be centralized. * **Direct Messages** - Send and receive direct messages that are encrypted to the recipient and unreadable by other community members. * **Mentions** - Send @ mentions that notify other users. * **Removal** - Remove users from your community. * **User Profiles** - Add an avatar or bio. * **Message Deletion** - Delete individual messages and set timed deletion rules ("disappearing messages") for the community. * **Status** - See your own connection status and the online status of other users. * **Reactions** - React with emojis. * **Multiple Communities** - Join multiple communities, as you would in Slack or Discord. * **Account Recovery** - Recover owner accounts from a backup phrase. * **Private channels** - Create private channels with multiple members that are unreadable to the community at large. ## Post-1.0 Features * **Large Communities** - Create a community with 1000 members or more (right now ~30-100 members is the limit.) * **Moderation** - Appoint moderators who can hide messages and silence or remove users. * **Spam and Denial-of-Service Protection** - Settings to automatically remove users who send disruptive messages. * **Search** - Robust message search. * **Threads** - Reply to messages in threads. * **Tor Bridges** - Connect via public or private bridges to avoid Internet censorship. * **Tor Browser Support** - Join communities as a full member with Tor Browser, without downloading an app. * **Browser Support** - Join communities with *any* modern browser via [Arti-in-WASM](https://gitlab.torproject.org/tpo/core/arti/-/issues/103). * **Publishing** - Share files (or entire websites) from your community to the web, via Tor, [OnionBalance](https://github.com/asn-d6/onionbalance), and [Tor2web](https://www.tor2web.org/) + IPFS. ## Technical overview This is a concise technical summary of the main points. 1. **Granting access:** community owners use standard PKI ([PKI.js](https://pkijs.org/)) to grant access, with each community owner serving as the community's [certificate authority](https://en.wikipedia.org/wiki/Certificate_authority); this is handled by Quiet and transparent to users. 2. **Authentication:** a valid signed certificate from the community owner is required to connect to peers, receive connections from peers, and for messages to be visible to other peers. 3. **Networking:** peers connect via [Tor onion services](https://en.wikipedia.org/wiki/Tor_(network)#Onion_services), exclusively with their fellow community members. 4. **Privacy:** Tor encrypts all data in transit, and a Quiet user's device connects only to the devices of their fellow community members, so all messages are encrypted to recipients. 4. **Syncing:** IPFS and [OrbitDB](https://orbitdb.org), an [IPFS](https://ipfs.io/)-based [CRDT](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type), ensure that all data (messages, user data, etc) syncs between peers with [eventual consistency](https://arxiv.org/abs/2012.00472). 5. **Asynchronous messaging:** because messages sync to all members, members can communicate without being contemporaneously online, provided that there is "continuous liveness", a continuous chain of online peers who each sync the latest updates, between the sender and the recipient. 5. **Identity:** a valid certificate from the community owner on account creation establishes a username, which the owner attests is unique; in future versions, Quiet will warn all members if community owners are caught issuing non-unique usernames, to protect against impersonation by malicious or compromised owners. (See: [#119](https://github.com/TryQuiet/monorepo/issues/119)) 6. **Invitation:** to invite new members, community owners provide (via some other secure channel) an onion address that points to a registration API which accepts a certificate signing request, responds with a signed certificate, and provides sufficient peer information to connect to other peers; in future versions this onion address will expire. (See: [#536](https://github.com/TryQuiet/monorepo/issues/536)) 7. **Account recovery:** owners must back up their data (e.g. by copying a folder, or someday with a wallet-style passphrase) and members request new accounts from owners. 8. **User removal:** TBD, but likely a combination of expiring invitation onion addresses, certificate revocation, and message-layer encryption with updated keys. 9. **Multiple device support:** TBD, but most likely based on [local-first-web/auth](https://github.com/local-first-web/auth) 10. **Mobile push notifications:** barring a major victory for consumer rights, iOS notifications require using a centralized push notification service that connects to Apple, but message data can still be encrypted; in proof-of-concept, Quiet works well as an always-on background app on Android, so Android versions will likely not require a push notification server. 11. **Stack:** Our backend is in Node.js (on iOS/Android we use [nodejs-mobile](https://github.com/nodejs-mobile)); we use Electron on desktop and React Native on mobile. ## Our Mission We are building Quiet to sharpen the tools that [open societies](https://en.wikipedia.org/wiki/Open_society) use to hold power accountable. Each year, movements use the Internet to hold power accountable in breathtaking new ways. But the rise of big tech has made the Internet *itself* seem like *yet another* unaccountable power. The medium that brought us *Occupy* Wall Street now looks like regular old Wall Street. We believe this happened because software became too dependent on company-run infrastructure, which undermined the role [free software](https://en.wikipedia.org/wiki/Free_software) has historically played in holding the software industry accountable. Our goal is to fix that. In the 2000s, when key dominant tech products had viable free software competitors that were radically pro-user (products like [Firefox](https://en.wikipedia.org/wiki/Firefox), [BitTorrent](https://en.wikipedia.org/wiki/BitTorrent), [VLC](https://www.videolan.org/), [Handbrake](https://en.wikipedia.org/wiki/HandBrake), or [Linux](https://en.wikipedia.org/wiki/Linux)) there was a limit to how much big tech could abuse users before users fled. But software for communication and collaboration seemed to require servers, whose cost grew with the software's popularity, so the question "who runs the server?" became a dilemma for free software projects. Should the project itself run the server? What about when costs grew too high? Should users run the server? But only a small niche of hobbyists have servers! Should an organization run the server? If so, then that organization now controls the data and relationships that make the product useful, limiting the freedom to [fork](https://en.wikipedia.org/wiki/Fork_(software_development)#Forking_of_free_and_open-source_software) and flee that makes free software so accountable and desirable. Reddit, for example, [was once free software](https://www.reddit.com/r/changelog/comments/6xfyfg/an_update_on_the_state_of_the_redditreddit_and/), but because forking Reddit's *code* would never have resulted in anything more than an empty website (since all the conversations and relationships that make Reddit what it is sit on *company-run servers*) Reddit being free software never gave Reddit's users any real power to hol