5 ms·

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 explici

by 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?
- h0p3 3y ago
  > we have so many bigger fish to fry! I can see that. Your roadmap makes sense to me. My [[wife|k0sh3k]] (without having seen your roadmap) picked out many of the same points as reasons she must wait to use it for her library staff. I appreciate how you must triage with the resources you have. Most of what I have to say isn't going to be as important to the non-poweruserbase you are trying to capture (and rightfully so!), so please take what I have to say with a grain of salt. You obviously know what you are doing. Reading through your account, I think you already know what I have to say here. > Would desktop-only i2p support be useful to you? Yes, and not just because I think it's important to contribute back to the network as a regular user. It would be especially nice with command-line tooling, and you can pickup UDP support. I've encountered plenty of failures on Tor (and you have too), and there are many I've encountered who I believe are rational in their desire not to be so reliant upon that network. I'd also be happy to use i2p on a mobile device just in case I had somewhat convenient control over when that occurred. If you provide logical accounts (where my decentralized identity can be wielded by multiple cooperating devices), then i2p becomes even better. Retroshare's use of both Tor and i2p have demonstrated the value of diversity here to my eyes as well. I'll add that something like multiplexing over multiple Tor or i2p tunnels could significantly improve throughput performance (a difficult place where you might be able deliver in some cases where no one has). However, I think your focus on mobile is more important (and I say that with a deep-seated grudge against phones). You serve the poorest on the planet by targeting mobile first. That isn't to say that you don't have any use for desktop users to assist on this network, but I can see why i2p, among many of my suggestions, should take a backseat. `/nod`. > It would be awesome to have a p2p github alternative that could ship builds over BitTorrent or IPFS I understand you've been around the block, so please ignore my gibberish. To my eyes, you're also building a serious competitor to [[P2P Matrix|2021.11.17 - HN Log: Arathorn & P2P Matrix]], which is still under development. I'll mention that Radicle may be worth your consideration. The functionality of [[DarkMX]] is worth your time as well (it is closed source, but its creator is one of the few with the right to ask us to trust him [even if I stand in disagreement]). I know some, like [[Ian Clarke]], will claim it is better not to "focus too much on competitors, better to focus on the needs of users," however, given the specialization of this tool, I think there's something to be said for having tasted the alternatives. [[Aether]] may be a direction you could eventually go, but I understand that isn't your immediate target; I don't know if protocol design decisions now might affect the future of such a thing. > Beyond participating in Tor, Quiet does not allow you to help any network you're not a member of `/nod`. I wonder if it is feasible for Quiet to have something like the Encrypted Key option in Resilio Sync, enabling one to seed in swarms without knowing the contents. There are some cases where it's useful, though there are tradeoffs. There may come a time where you've decentralized to the point where it hurts too much, and you'll have to centralize until it works. I wonder if there are cases in which randos must hold at least metadata for others or act as proxies (I understand that Tor solves many problems for you). [[Tox|Toxcore]] is an exemplary tool in part of this space you're solving, and even they haven't solved some of these problems. Seamless multidevice and offline messaging are dealbreakers for many people. > If you have access to a large number of machines, rigorous performance testing with hundreds of nodes could possibly be helpful?... manual and automated testing on many diverse Android devices; that would be helpful! I'll be thinking about that then. NixOS with solid orchestration on a beefy machine (I'm not sure if zswap would assist here, but memory seems a serious bottleneck) may be able to push hard. There's probably no way around using a lot of machines unless a much thinner client were feasible. The nice part is that donations might allow you to control the machines remotely while dogfooding.

by h0p3 3y ago

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?

h0p3 3y ago
> we have so many bigger fish to fry! I can see that. Your roadmap makes sense to me. My [[wife|k0sh3k]] (without having seen your roadmap) picked out many of the same points as reasons she must wait to use it for her library staff. I appreciate how you must triage with the resources you have. Most of what I have to say isn't going to be as important to the non-poweruserbase you are trying to capture (and rightfully so!), so please take what I have to say with a grain of salt. You obviously know what you are doing. Reading through your account, I think you already know what I have to say here. > Would desktop-only i2p support be useful to you? Yes, and not just because I think it's important to contribute back to the network as a regular user. It would be especially nice with command-line tooling, and you can pickup UDP support. I've encountered plenty of failures on Tor (and you have too), and there are many I've encountered who I believe are rational in their desire not to be so reliant upon that network. I'd also be happy to use i2p on a mobile device just in case I had somewhat convenient control over when that occurred. If you provide logical accounts (where my decentralized identity can be wielded by multiple cooperating devices), then i2p becomes even better. Retroshare's use of both Tor and i2p have demonstrated the value of diversity here to my eyes as well. I'll add that something like multiplexing over multiple Tor or i2p tunnels could significantly improve throughput performance (a difficult place where you might be able deliver in some cases where no one has). However, I think your focus on mobile is more important (and I say that with a deep-seated grudge against phones). You serve the poorest on the planet by targeting mobile first. That isn't to say that you don't have any use for desktop users to assist on this network, but I can see why i2p, among many of my suggestions, should take a backseat. `/nod`. > It would be awesome to have a p2p github alternative that could ship builds over BitTorrent or IPFS I understand you've been around the block, so please ignore my gibberish. To my eyes, you're also building a serious competitor to [[P2P Matrix|2021.11.17 - HN Log: Arathorn & P2P Matrix]], which is still under development. I'll mention that Radicle may be worth your consideration. The functionality of [[DarkMX]] is worth your time as well (it is closed source, but its creator is one of the few with the right to ask us to trust him [even if I stand in disagreement]). I know some, like [[Ian Clarke]], will claim it is better not to "focus too much on competitors, better to focus on the needs of users," however, given the specialization of this tool, I think there's something to be said for having tasted the alternatives. [[Aether]] may be a direction you could eventually go, but I understand that isn't your immediate target; I don't know if protocol design decisions now might affect the future of such a thing. > Beyond participating in Tor, Quiet does not allow you to help any network you're not a member of `/nod`. I wonder if it is feasible for Quiet to have something like the Encrypted Key option in Resilio Sync, enabling one to seed in swarms without knowing the contents. There are some cases where it's useful, though there are tradeoffs. There may come a time where you've decentralized to the point where it hurts too much, and you'll have to centralize until it works. I wonder if there are cases in which randos must hold at least metadata for others or act as proxies (I understand that Tor solves many problems for you). [[Tox|Toxcore]] is an exemplary tool in part of this space you're solving, and even they haven't solved some of these problems. Seamless multidevice and offline messaging are dealbreakers for many people. > If you have access to a large number of machines, rigorous performance testing with hundreds of nodes could possibly be helpful?... manual and automated testing on many diverse Android devices; that would be helpful! I'll be thinking about that then. NixOS with solid orchestration on a beefy machine (I'm not sure if zswap would assist here, but memory seems a serious bottleneck) may be able to push hard. There's probably no way around using a lot of machines unless a much thinner client were feasible. The nice part is that donations might allow you to control the machines remotely while dogfooding.