> Thank you for this gift to humanity.

Aw thanks. That is what we're going for. One that makes sure others will always be able to give their gifts to humanity.

> I'm glad to see you are thoughtful about many protocols here. Will you be adding i2pd support?

There is no current plan to. I'd be super curious to see how well it works, but we have so many bigger fish to fry! My guess is that adding i2p support on desktop would be straightforward and that on mobile it would be costly. Would desktop-only i2p support be useful to you?

> Could you make explicit for us what parts of this tool are the least decentralized?

Our source control, update server, and CI! It would be awesome to have a p2p github alternative that could ship builds over BitTorrent or IPFS. Someday! :)

Beyond that, there are some pieces of Tor that are less decentralized (Guard nodes, e.g.) but everything else is just client code running over Tor talking to other clients.

> Do you need computational donations to the network?

Right now, the best way to donate to the Quiet network is to run a Tor relay. Beyond participating in Tor, Quiet does not allow you to help any network you're not a member of!

If you have access to a large number of machines, rigorous performance testing with hundreds of nodes could possibly be helpful? In the past we've used Fargate for this, but this is expensive so it would be nice to have something running in an ongoing way. Also, manual and automated testing on many diverse Android devices; that would be helpful!

> How can I assist?

The thing we need most are real communities of people who desperately want to switch away from Slack, Discord, or Signal but don't have a satisfactory solution. Specifically, we want to learn about their use cases and tailor Quiet to their needs as much as possible. Know anyone?

> Do you intend to provide users complete control over private/public keys within the interface?

Yes. Right now user keys are stored on their machines and nowhere else, but you have to just copy a directory to move them or back them up. Soon we'll let people recover accounts from their linked devices (e.g. from your computer if your phone is lost) and we may have some social recovery solution within communities for DMs, though that might not be feasible. We'll also do the crypto wallet thing of encouraging people to write down passphrases, but most users won't do that.

> Will you be providing significant command-line access to the tooling?

The backend is its own Node module, but we don't have a good CLI for it yet and it's not a current priority: https://github.com/TryQuiet/quiet/tree/develop/packages/back...

> How far have you attempted to scale this up?

We've run tests with 200-300 nodes on Amazon Fargate, and our frontend was the bottleneck, not the p2p layer. Libp2p currently handles 800,000 nodes on the Ethereum beacon chain. Phones will need to be given some more limited view of the network for large communities to remain performant, and we will need to add retention limits for messages and images otherwise drive space will be the bottleneck, but there is no reason why we cannot handle very large communities.

> Will you be working toward collaborative text environments like Etherpad Latency seems too high for that, right?

For text documents, latency isn't the issue, but CRDT performance is because every character is a new CRDT transaction. We would love to pursue this if our users ask for it. So far there isn't a strong signal that users need it. Many people I talk to use documents to prepare things for intended eventual publication, while they use messaging for in-progress thoughts, so docs are not as sensitive as messages. It's like, docs are an organization's mouth and messaging is an organization's brain. You care more about the privacy of your brain. But technically this would be a fun challenge and I'm sure we could build something great. There are other CRDTs we could use.

> Do you intend to enable the synchronization of larger sets of files, something like mutable torrents?

This would probably be straightforward. What's your use case?