Hi everyone,
My collaborators and I have been working for the past couple years on building a Tor-based team chat app which we're calling Quiet*, and I'm curious if anyone here would like to try it out!
If you would, please reply! :) I am especially interested in feedback from Tor project participants and people who are sometimes in the position of advising organizations on their security needs, but everyone on this list is welcome! What I'll try to do is find a time that would work for all of us so we can try it together in a true test of its team chat possibilities, though if that doesn't work I'm happy to do one on one meetings too.
Quiet is still lacking pretty much every feature imaginable except adding team members and sending and receiving messages. And mobile apps aren't ready yet. And it hasn't been audited so it shouldn't be used for anything important at all. And so on. But if you've tried any attempts at p2p group chat before, this one will strike you as surprisingly reliable thanks in no small part to the reliability of Tor. So it's pretty cool to see it in action and it's a fun new way to use Tor. Again, I'm not looking for any real end users at this stage—we're just not ready for that yet. But we've invested a lot in usability and reliability and we're making a really serious go of it. This isn't vaporware and I think it'll be worth your time to check it out! :)
Perhaps the coolest part about our approach is that its usefulness goes way beyond chat apps. The approach we've taken is adequate for building private, F/OSS alternatives to a large class of crucial applications that currently lack strong privacy and security properties, such as Trello, Asana, Basecamp, Google Docs and Sheets, Figma, Discourse, Airtable, team password managers, and more. Specifically, you can use it to build any application where a bounded group of people share some common workspace, as long as the data would fit on a typical consumer device. And perhaps from that foothold we can figure out ways to extend the model to be adequate for building large unbounded networks like Signal, Twitter, and Facebook in a decentralized way, though that's a much harder class of problem.
(I gave this talk https://archive.org/details/hopeconf2020/20200802_1600_Zbay%2C_Fighting_FAANG%2C_and_P2P_Messaging.mp4 a couple years back at HOPE 2020 about these ideas which is a pretty good overview of the motivations behind the project, and and I'll be speaking again at HOPE 2022 this summer about where we're at now, so it would be great to meet up there if anyone else will be there!)
I've included some more notes below on how it works for those who are curious. But if you're curious please write me back so I can give you a demo :)
Holmes
# How it works
Quiet is like a combination of Slack and Ricochet. Ricochet did not depend on any servers except for the Tor network itself, and sent messages directly over onion services, but it was only for 1:1 messaging. Like Ricochet, Quiet doesn't require any servers except for the Tor network itself, but it uses some p2p libraries that have emerged over the past few years to enable group chat where—like Slack and Discord—all clients tend to display the same message history, even clients that were offline when messages were sent.
Specifically, Quiet uses OrbitDB, a CRDT. CRDTs are sort of like Git, where they enable syncing between decentralized peers such that all peers eventually converge on the same state. OrbitDB is built on IPFS, so unlike a lot of CRDTs (like Automerge) it comes with some built-in ability to move data around between peers. IPFS is pretty flexible and we set it up so that each team has its own totally isolated IPFS network, and all the IPFS clients connect to each other over Tor. There's no big, global, leaky p2p network, and no blockchain or anything like that. You have a group of friends, and you just talk to each others onions. That's it.
To invite a new user, an authorized user shares an onion service link to a "registrar" onion service running on their machine, and they add that new user's key information to a user table, and give the user a certificate they can use to connect to other peers. A single community owner uses certificates to grant unique usernames.
Mobile apps use the same approach, though we'll need a centralized service for notifications on iOS until someone changes the way Apple Apples, and we haven't built that yet. There are a lot of other important pieces of the design we haven't tackled yet too, such as timed message deletion, removing users, use of onion auth for incoming connections, optimizations for very large communities, and so on. But it's all fairly tractable, if a bit slow going.
(I'm also really interested if this description is clear and would love your feedback and questions!)