6 ms·

Quiet founder here! First, the big advantage of Quiet over IRC is that Quiet has eventual consistency built on a CRDT, so you'll sync messages sent while you w

Quiet founder here! First, the big advantage of Quiet over IRC is that Quiet has eventual consistency built on a CRDT, so you'll sync messages sent while you were offline. In a team chat setting this is really useful and was one of Slack's big draws when it launched, as I remember it. Re: video calling -- end-to-end encrypted voice and video calls (or channels, huddles, what have you) are actually something we plan to add someday, as we've had users asking for it. Right now many voice and video calls are at least partly peer-to-peer, so with some caveats a p2p video calling solution is actually more straightforward than p2p chat. The caveats are: 1. We wouldn't want to use Tor, at least in its current form, because its multiple hops and lack of UDP support will increase latency, so you wouldn't get the same metadata privacy. 2. Larger group calls (>10 voice participants, >3 video participants) may well require a server, since the standard solution for pure p2p group calling is for all participants to stream pairwise to all participants, so the number of participants is limited by the upstream bandwidth of the slowest participant divided by the stream bitrate. 3. Even small group video calls often require a relay server sometimes, because roughly 10-20% of peers in real world settings cannot make direct connections to each other even with holepunching techniques. (A classic scenario: two peers on the same public wifi, when the router's security settings prohibit local connections, will need a reliable external server to send all the data.) So our current plan is to offer voice and video calling (and any other features that require a server, like file storage beyond the capacity of the network's devices) as a paid subscription feature. Picture a freemium SaaS product where the free version is open source, forkable, and fully reliable in its p2p form without any support from us. This gives users a lot of power to keep us honest, but it would let people pay us for stuff you really want a server for. All that said, maybe somebody will come up with a great p2p, large-group video calling solution with reliable decentralized holepunching and we can use that approach! (But I'm not holding my breath!)

37469920away 3y ago
Always good to have alternatives. Thanks for your work and good luck.
- holmesworcester 3y ago
  Thanks!!
thewanderer1983 3y ago
Have you considered lokinet? It may help for the video/audio calls.
- holmesworcester 3y ago
  Yes! I've followed the progress of Loki/Oxen/Session since a talk I gave at HOPE 2020 surveying the field of p2p messaging approaches, and since then a mutual friend introduced me to the Session/Lokinet team and we had a great meeting. The Oxen/Session approach of having a bunch of crypto-incentivized, investor-subsidized always-on servers to do stuff for you is very powerful and makes a lot of things easier. Where it really shines is supporting iOS devices where the OS gives you very tight constraints on how much CPU and time you can use to connect to a peer and sync messages. I true We decided to start without depending on a cryptocurrency or a cryptocurrency-incentivized network because I don't think we need it. I know some people hate crypto too. I don't but it keeps things cleaner to not depend on it. Also, when it comes to onion routing Tor is a lot more battle-tested and has many more eyes on it, so I'm fairly confident that it's superior to the extent we only need that piece. There is also some actual worrying ambiguity around what happens with lokinet if their coin price drops but their traffic goes up a lot. (Though the same thing could be said of Tor, swapping out "community support" for "coin price", so we may have to roll our own network in the future anyway or give users more options for connecting directly when they feel it's safe to do so.)
tyzoid 3y ago
What about Veilid?
- holmesworcester 3y ago
  Veilid is a recently announced, general-purpose peer-to-peer Stack. We're excited about it! We would consider switching away from OrbitDB/IPFS/Libp2p/Tor for a less mature peer-to-peer state syncing stack if it offered the following as first-class features in addition to what we have, had credible longevity, and ran well on desktop and mobile: 1. Deletion 2. Encrypted groups with removal 3. Support for linking multiple devices, and removing devices 4. Support for partial syncing / lazy loading. It would be really nice to have all of these things out of the box, alongside state syncing and BitTorrent-style file transfer (which we have now.) Veilid is still new so we haven't assessed it yet, but that would be our criteria. My general perspective on general purpose peer-to-peer stacks (which I understand Veilid to be) is that it will be very difficult to build meaningful general purpose platforms until we have more examples of popular desktop + mobile peer-to-peer products with large numbers of users in the wild that would let us identify all the things a general purpose stack would need to have, and that right now the best thing to do is build single-purpose peer-to-peer apps in whatever way you can (whether it's by building your own non-general stack or cobbling together existing building blocks as we're doing) and struggle to find product market fit! The way I think about it is: would you have been able to build Heroku before there were a few successful production Ruby on Rails apps with product-market fit? Probably not! So we shouldn't expect to be able to build useful general purpose p2p stacks without clear examples of successful p2p products with product-market fit.
  - MayeulC 3y ago
    Hmm, it feels like a CRDT + any overlay network (This is probably how you use tor or IPFS p2p) would get you there. Matrix p2p is developing pinecone [1] as an overlay network, which seems very aligned with your needs, though, as you say, it is less mature. Well, pinecone/yggdrasil/cjdns/tor are only part of the question, as they provide encrypted E2E connectivity. You still have to build on top of it to handle groups and lazy loading. They do solve routing though, so you can just try to send packets to every group member (like Matrix does). For a more efficient implementation, it would be nice to have multicast/unicast integrated in the overlay network at the protocol level. API-wise, it could be made as simple as sharing a private key with a group: multiple peers with the same address would then receive the same packets. In any case, I feel like working together with Matrix (/new vector) on pinecone would help both of you. [1]: https://github.com/matrix-org/pinecone https://github.com/matrix-org/pinecone
h0p3 3y ago
Thank you for this gift to humanity. * I'm glad to see you are thoughtful about many protocols here. Will you be adding i2pd support? * Could you make explicit for us what parts of this tool are the least decentralized? * Do you need computational donations to the network? How can I assist? * Do you intend to provide users complete control over private/public keys within the interface? * Will you be providing significant command-line access to the tooling? * How far have you attempted to scale this up? * Will you be working toward collaborative text environments like Etherpad? Latency seems too high for that, right? * Do you intend to enable the synchronization of larger sets of files, something like mutable torrents?
- holmesworcester 3y ago
  > 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/backend/ 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?
LWIRVoltage 3y ago
This would be huge- but also a replacement forJitsi Meet, which just started requiring registration using google, Microsoft or Facebook accounts. So, anonymous E2EE( well, they used insertable streams, Firefox didnt have this fully implement Yet but was working on it, spurred on by jitsu meet, actually) Im a web browser accessible OR electron app form for any OS, open source, and totally anonymous, while able to host a good number of people all securely, for free, is not accessible to people anymore. ( there are other jitsi meet instances that likely will not require the same but this badly hurts nontheless, as they were perhaps the main free zoon competition in some ways.) https://news.ycombinator.com/item?id=37316959 https://news.ycombinator.com/item?id=37316959 https://news.ycombinator.com/item?id=37381508 https://news.ycombinator.com/item?id=37381508 You'll be filling that gap, and it is a badly needed one from an anonymity /E2EE functionality perspective.
- holmesworcester 3y ago
  That's really interesting. Jitsi offers a React Native SDK and we were interested in using it (in e2ee mode) for Quiet. Twilio offers one too (FOSS on client side and Twilio SaaS on the server side) but it would be nicer to use Jitsi. If we only offered it to paying customers it would have the same downsides as using Jitsi though. One question: speaking for yourself and the use cases you know well, how much latency or call quality would you give up for anonymity? Would you give up video? Would old-school VOIP level lags between speakers be okay? Doing something like push to talk would be trivial now, over Tor. But an anonymous video call with lots of participants would be really hard. Sometimes I think about something in between... like a voice activated push to talk where everyone's audios are played continuously. But nothing exists like this afaik so it would be costly to explore.
  - LWIRVoltage 3y ago
    My apologies on my former post, the auto correct on my phone did a number. For the use cases I know, some quality loss wouldn't be to much of an issue, but at least rudimentary video would be desired. Lag of that sort wouldn't be too bad of an issue considering it'd be to maintain a level of security and privacy that is difficult to match.( Since Signal is still working on not needing to use phone numbers, to add a privacy/ anonymous benefit to it) I know both Jitsi Meet and Google Duo( now google Meet) have a bit of info out there about the challenges they encountered upon finding methods to implement multiple-person E2EE video chat. Duo had a cap of about a dozen give or take, callers at first before they could scale up. Jitsu added E2EE as a toggleable option after getting their initial product out- so this might be the sort of thing where it doesn't start out with lots of Participants, at the beginning. Finally, you mentioned exploring some of these options not over TOR. That might be beneficial for those seeking anonymity, since TOR usage has been used to fingerprint people when no one else on a network was using it. ( VPN's and Bridges are other methods of course to plug that hole, but usually have to come from the user side at cost and some technical familiarity.) Push to talk is not something I've seen before- I take it the technical load would be less in that format?

37469920away 3y ago

Always good to have alternatives. Thanks for your work and good luck.

holmesworcester 3y ago
Thanks!!

thewanderer1983 3y ago

Have you considered lokinet? It may help for the video/audio calls.

holmesworcester 3y ago
Yes! I've followed the progress of Loki/Oxen/Session since a talk I gave at HOPE 2020 surveying the field of p2p messaging approaches, and since then a mutual friend introduced me to the Session/Lokinet team and we had a great meeting. The Oxen/Session approach of having a bunch of crypto-incentivized, investor-subsidized always-on servers to do stuff for you is very powerful and makes a lot of things easier. Where it really shines is supporting iOS devices where the OS gives you very tight constraints on how much CPU and time you can use to connect to a peer and sync messages. I true We decided to start without depending on a cryptocurrency or a cryptocurrency-incentivized network because I don't think we need it. I know some people hate crypto too. I don't but it keeps things cleaner to not depend on it. Also, when it comes to onion routing Tor is a lot more battle-tested and has many more eyes on it, so I'm fairly confident that it's superior to the extent we only need that piece. There is also some actual worrying ambiguity around what happens with lokinet if their coin price drops but their traffic goes up a lot. (Though the same thing could be said of Tor, swapping out "community support" for "coin price", so we may have to roll our own network in the future anyway or give users more options for connecting directly when they feel it's safe to do so.)

tyzoid 3y ago

What about Veilid?

holmesworcester 3y ago
Veilid is a recently announced, general-purpose peer-to-peer Stack. We're excited about it! We would consider switching away from OrbitDB/IPFS/Libp2p/Tor for a less mature peer-to-peer state syncing stack if it offered the following as first-class features in addition to what we have, had credible longevity, and ran well on desktop and mobile: 1. Deletion 2. Encrypted groups with removal 3. Support for linking multiple devices, and removing devices 4. Support for partial syncing / lazy loading. It would be really nice to have all of these things out of the box, alongside state syncing and BitTorrent-style file transfer (which we have now.) Veilid is still new so we haven't assessed it yet, but that would be our criteria. My general perspective on general purpose peer-to-peer stacks (which I understand Veilid to be) is that it will be very difficult to build meaningful general purpose platforms until we have more examples of popular desktop + mobile peer-to-peer products with large numbers of users in the wild that would let us identify all the things a general purpose stack would need to have, and that right now the best thing to do is build single-purpose peer-to-peer apps in whatever way you can (whether it's by building your own non-general stack or cobbling together existing building blocks as we're doing) and struggle to find product market fit! The way I think about it is: would you have been able to build Heroku before there were a few successful production Ruby on Rails apps with product-market fit? Probably not! So we shouldn't expect to be able to build useful general purpose p2p stacks without clear examples of successful p2p products with product-market fit.
- MayeulC 3y ago
  Hmm, it feels like a CRDT + any overlay network (This is probably how you use tor or IPFS p2p) would get you there. Matrix p2p is developing pinecone [1] as an overlay network, which seems very aligned with your needs, though, as you say, it is less mature. Well, pinecone/yggdrasil/cjdns/tor are only part of the question, as they provide encrypted E2E connectivity. You still have to build on top of it to handle groups and lazy loading. They do solve routing though, so you can just try to send packets to every group member (like Matrix does). For a more efficient implementation, it would be nice to have multicast/unicast integrated in the overlay network at the protocol level. API-wise, it could be made as simple as sharing a private key with a group: multiple peers with the same address would then receive the same packets. In any case, I feel like working together with Matrix (/new vector) on pinecone would help both of you. [1]: https://github.com/matrix-org/pinecone https://github.com/matrix-org/pinecone

h0p3 3y ago

Thank you for this gift to humanity. * I'm glad to see you are thoughtful about many protocols here. Will you be adding i2pd support? * Could you make explicit for us what parts of this tool are the least decentralized? * Do you need computational donations to the network? How can I assist? * Do you intend to provide users complete control over private/public keys within the interface? * Will you be providing significant command-line access to the tooling? * How far have you attempted to scale this up? * Will you be working toward collaborative text environments like Etherpad? Latency seems too high for that, right? * Do you intend to enable the synchronization of larger sets of files, something like mutable torrents?

holmesworcester 3y ago
> 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/backend/ 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?

LWIRVoltage 3y ago

This would be huge- but also a replacement forJitsi Meet, which just started requiring registration using google, Microsoft or Facebook accounts. So, anonymous E2EE( well, they used insertable streams, Firefox didnt have this fully implement Yet but was working on it, spurred on by jitsu meet, actually) Im a web browser accessible OR electron app form for any OS, open source, and totally anonymous, while able to host a good number of people all securely, for free, is not accessible to people anymore. ( there are other jitsi meet instances that likely will not require the same but this badly hurts nontheless, as they were perhaps the main free zoon competition in some ways.) https://news.ycombinator.com/item?id=37316959 https://news.ycombinator.com/item?id=37316959 https://news.ycombinator.com/item?id=37381508 https://news.ycombinator.com/item?id=37381508 You'll be filling that gap, and it is a badly needed one from an anonymity /E2EE functionality perspective.

holmesworcester 3y ago
That's really interesting. Jitsi offers a React Native SDK and we were interested in using it (in e2ee mode) for Quiet. Twilio offers one too (FOSS on client side and Twilio SaaS on the server side) but it would be nicer to use Jitsi. If we only offered it to paying customers it would have the same downsides as using Jitsi though. One question: speaking for yourself and the use cases you know well, how much latency or call quality would you give up for anonymity? Would you give up video? Would old-school VOIP level lags between speakers be okay? Doing something like push to talk would be trivial now, over Tor. But an anonymous video call with lots of participants would be really hard. Sometimes I think about something in between... like a voice activated push to talk where everyone's audios are played continuously. But nothing exists like this afaik so it would be costly to explore.
- LWIRVoltage 3y ago
  My apologies on my former post, the auto correct on my phone did a number. For the use cases I know, some quality loss wouldn't be to much of an issue, but at least rudimentary video would be desired. Lag of that sort wouldn't be too bad of an issue considering it'd be to maintain a level of security and privacy that is difficult to match.( Since Signal is still working on not needing to use phone numbers, to add a privacy/ anonymous benefit to it) I know both Jitsi Meet and Google Duo( now google Meet) have a bit of info out there about the challenges they encountered upon finding methods to implement multiple-person E2EE video chat. Duo had a cap of about a dozen give or take, callers at first before they could scale up. Jitsu added E2EE as a toggleable option after getting their initial product out- so this might be the sort of thing where it doesn't start out with lots of Participants, at the beginning. Finally, you mentioned exploring some of these options not over TOR. That might be beneficial for those seeking anonymity, since TOR usage has been used to fingerprint people when no one else on a network was using it. ( VPN's and Bridges are other methods of course to plug that hole, but usually have to come from the user side at cost and some technical familiarity.) Push to talk is not something I've seen before- I take it the technical load would be less in that format?