[tor-dev] We built a new Tor-based team chat prototype. Wanna try it?

[Holmes Wilson]

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!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20220415/5793a111/attachment.htm>