Quiet – Encrypted P2P team chat with no servers, just Tor
github.com
github.com
The performance issues that come along with running OrbitDB/IPFS on a machine, let alone a mobile device, are still significant unfortunately. Adding Electron on top of what is already a heavy-weight application is probably going to make people's devices go brrrrr all the time. Not only that, but I would argue that for instant communication this stack might not be the best idea in terms of performance in first place.
Besides, the way IPFS has been (and still keeps) changing their dozens of libraries doesn't make development particularly smooth either. OrbitDB is always behind the latest IPFS version due to all these changes that are being introduced. Hence unless you're planning to allocate developer time on these two things as well, my guess is that you probably won't have too much fun with your back-end.
The integration with Tor is another thing that will likely be a time drain for developers, as other people here already pointed out, and that will lead to even more performance issues down the line.
Don't get me wrong, I really like the idea behind this project. However, I feel like the aspirations are unrealisticly high and the actual outcome might be realtively frustrating for the average end-user. Having that said, I would love my gut feeling to be proven wrong!
Disclaimer: I'm the developer of Superhighway84 (https://en.wikipedia.org/wiki/InterPlanetary_File_System#App..., https://github.com/mrusme/superhighway84), a USENET-inspired, uncensorable, decentralized internet discussion system running on IPFS & OrbitDB.
All of these things are true and it's clear you know the problem space well! We avoid the primary "go brrrrr" performance issue with IPFS by using small private IPFS networks and never touching the noisy, CPU-intensive global network.
You didn't even mention the biggest time drain, which is getting everything to work well on Android and iOS! This is on track to dwarf all other time drains by 10x or more.
However, the amazing thing is, as full-of-warts as the stack we've chosen is, it isn't a clearly worse choice than the alternatives, from GUN, to Hypercore, to the Automerge space, to Braid, to Holochain, P2Ppanda, and so on. All the other attempts to build a general purpose stack have a few things they do well and a bunch of things they don't do well, or at all, or they have similar questionable longevity to something like OrbitDB.
But if you believe what we both believe (i.e. that users shouldn't have to depend on someone else's server or run their own just to gather online) what is to be done? It seems like you decided to roll up your sleeves and try. Maybe the necessary ingredient is PG's "Schlep Blindness" [1] where you have to be pretty naive or masochistic to get started but if you keep pushing you can make something really new and valuable.
I think the reason why the field is in this place is simply that a general purpose p2p stack for user-facing apps needs to do the impossible: it needs to build complex solutions to an actually very long list of heterogeneous problems, without clear knowledge of what those problems are and what form they take in production, because there aren't any successful, desktop + mobile peer-to-peer apps yet to provide that reality-tested information, unless you count WebRTC video calls, which only covers a small piece of the picture.
So we just have to push through. And it's fun! Also, please do DM or email me! I'd love to compare notes more deeply than would be possible here (same offer goes for others who are interested in these questions!): h [at] quiet.chat
> However, the amazing thing is, as full-of-warts as the stack we've chosen is, it isn't a clearly worse choice than the alternatives, from GUN, to Hypercore, to the Automerge space, to Braid, to Holochain, P2Ppanda, and so on.
I think far more interesting these days would be projects like Veilid, Hyphanet's Locutus and ultimately Nostr -- even though not truly P2P in that sense -- which already happens to have a first try going with nostrchat.io. If P2P is something that is truly desired, I feel like projects like Briar (https://briarproject.org/how-it-works/) have solved this with Bramble (https://code.briarproject.org/briar/briar-spec/blob/master/p...) more eloquently than it could be done on top of IPFS.
> It seems like you decided to roll up your sleeves and try.
Ultimately IPFS was designed as a file store, which to me was the main reason to use it for Superhighway84. I intended to implement USENET-like file attachments and (go-)OrbitDB was merely an easier way to deal with the messages posted into the groups. However, if instant communication would be my main focus, I would rather try more lightweight frameworks (see above), especially if mobile devices should come into play eventually. Superhighway84 was never intended to leave the beautiful space that is the command line and hence niche-by-design. :-)
Again, I will definitely keep an eye on Quiet, to see how it ultimately evolves on top of IPFS. I could nevertheless imagine it being overtaken fairly quickly by other projects sporting a rather lightweight and more managable basis, that allows for increased development speed and ultimately for faster iteration on features that users might wish for (e.g. DMs, @-mentions, message deletion, mobile clients, you-name-it) -- without the need to invest heavily into e.g. performance (or reliability!) issues of the underlying framework.
I have not assessed Veilid yet but it's on my list and at a first glance seems like a very serious and informed attempt. I'm personal friends with Freenet / Hyphanet's Ian Clarke and spoke with him about Locutus when he was just getting started. It sounded awesome then and I will give this a second look too, though when he explained it to me it sounded like it had the same limitations with deletion that Nostr or the global IPFS network would have. It does seem important to note here that both Veilid and Locutus are much less mature and battle-tested than libp2p and Tor and have less Lindy longevity (longevity as a function of age.) We already suffer a lot from being on the bleeding edge, so it's nice to limit the number of bleeding edge tools we use. Libp2p, notably, has been rock solid for us and barely a time drain at all, apart from some unexpected interactions with Tor which are mostly about the lack of an official first-class Tor transport, which is specific to our use case and should start to change soon when Tor's Arti is ready.
> and ultimately Nostr -- even though not truly P2P in that sense -- which already happens to have a first try going with nostrchat.io.
Nostr and Bluesky both seem very promising for the open-world use case of social networking, and it has been amazing to see Nostr grow so rapidly as a community. I am rooting for this project and we might use it someday in Quiet for public feeds. Timed deletion is the user requirement that drives me away from building Quiet on Nostr. Based on conversations I've had with users doing sensitive work (and based on my own experience as a founder of Fight for the Future) timed deletion is extremely important to team security, and for deletion to be meaningful one needs more control over where the data is relayed than what Nostr provides in the default mode. A group that wanted trustworthy timed deletion would have to control their own private Nostr relay. Technically, a Tor relay could subvert the timed deletion of some Quiet messages just by capturing all traffic, but this is much less of a worry.
> If P2P is something that is truly desired, I feel like projects like Briar (https://briarproject.org/how-it-works/) have solved this with Bramble (https://code.briarproject.org/briar/briar-spec/blob/master/p...) more eloquently than it could be done on top of IPFS.
Bramble could work for us and I would recommend that anyone look into it. Briar is probably the most similar thing to Quiet that exists right now. There are big differences between Quiet and Briar, but we could definitely build Quiet on Bramble if it adequately supports iOS. My worry would be its maturity as a tool for people building things other than Briar. That could be worth the risk though and I do recommend anyone else reading this thread look at Bramble if you are doing something similar.
> I could nevertheless imagine it being overtaken fairly quickly by other projects sporting a rather lightweight and more managable basis, that allows for increased development speed and ultimately for faster iteration on features that users might wish for (e.g. DMs, @-mentions, message deletion, mobile clients, you-name-it) -- without the need to invest heavily into e.g. performance (or reliability!) issues of the underlying framework.
This is definitely something we will keep an eye on, and thank you for the thoughtful advice! My guess is that as soon as we have a significant number of real users we will need to build things that don't happen to be supported by whatever stack we choose (whether that is our current stack, Bramble, Veilid, Automerge, etc.) So the question is what's the easiest one to maintain and adapt. So far libp2p and IPFS have both been good in that department: implementations in many languages, active development, an absence of major problems showing signs of maturity (especially in libp2p), etc.
Also, my 2 cents are (for anyone following along) that if I had to do this all over again I would use Tor + Libp2p + Automerge. Libp2p and Gossipsub are solid, flexible, and will be around a while. No need to reinvent the wheel. The conceptual framework behind Automerge and Briar/Bramble are pretty similar (sync state!) but the Automerge team exists to serve people building other apps, while the Bramble team mostly focuses on Briar AFAIK. What's nice about Automerge is that the community around it (Ink & Switch, Martin Kleppmann, and other academics) is all at the academic frontier, so the level of thought and anticipation of user needs that goes into their decisions is very thorough, even if the implementations lag behind the papers. If I was doing real-time p2p text editing I would also look at the Braid project (braid.org) and Seph Gentle's work on Diamond Types, since that's where the most thought has gone into the raw performance you need for text CRDTs that can handle large documents: https://github.com/josephg/diamond-types
The Usenet network itself is always online and highly resilient - most providers offer ~5000 days of binary retention, and endless retention on text - and great bandwidth to boot. If a user doesn't have Usenet, or the Usenet isn't at the 'current' timestamp, that's where the Tor/P2P layer could kick in. You would only need a single server (with a private key, trusting the public key in the main executable) that continuously archives new posts to Usenet to make it work.
Your thought sounds interesting, however I'm not sure I fully grasp the details correctly, so bear with me. Generally speaking though, integrating with the actual USENET these days poses a few hurdles, one of which is as plain as it gets:
Finding well-maintained libraries to do so, especially with more modern stacks (e.g. https://github.com/search?q=nntp+language%3AGo&type=reposito...). Depending on how exactly you thought to integrate with USENET servers, it might look even more meager in regard to UUCP libraries. And yes, of course you could bind e.g. existing C libraries and so on, but I'd still argue that it's not the most straight forward developer experience that you'll get -- unlike with more modern technologies that either provide language bindings or other means of integration (gRPC, websockets, etc).
But apart from this, one key difference to keep in mind in regard of especially resilience is that, with USENET, resilience depends on the number of active servers that are willing to offer unfiltered access to the content, meaning that the game of whac-a-mole is in theory slightly more predictable for an attacker or oppressor trying to limit access to the network. On the other hand with projects like I2P, Tor, or IPFS, every new client that connects to the network is also/can also be a relay at the same time, that an attacker or an oppressor would need to find and neutralize in order to successfully block the entire network.
We might as well not forget that many USENET servers are paid infrastructure these days. For someone who lives in a developed country, this might not be an issue. However, being unable to pay for your access simply because you don't have the resources, because you are unbanked, or because your government took the easy path of sanctioning financial transactions to either providers of such services, or specific payment providers in general, in an effort to curb the use of the network, makes USENET theoretically more prone to censorship than for example IPFS.
One instance where this government intervention is rampant are VPNs, which similarly rely on a legal entity that provides the server-side of the network. There are countries that have either outlawed these type of paid services altogether, or made the companies bend over, in an effort to limit freedom of access to information. In a theoretical scenario in which USENET would re-gain traction and become a more mainstream service, it would be fairly easy for governements to sanction the legal entities that provide access to the network. And there would be little alternative, as with the amount of data on USENET, it would be quite expensive for individuals to offer free, unfiltered USENET access to others. On the other hand, there's nothing that could be sanctioned with IPFS or similar peer-to-peer services. The use of this type of software might be made illegal in general, but cracking down on it, on an individual basis, is significantly harder.
Besides, the account requirement and setup for USENET also makes it more complex for an end-user to get onto the network, as compared to IPFS, where one can basically just download and run Kubo (and use a browser extension to access the local gateway). However, from what I understood, your idea would not imply each user having an individual USENET account, but rather having own USENET servers that trust the client no matter of the user that's using it, which thinking about it, might come with its own set of challenges.
I would argue that the resilience we experience with USENET was/is partially due to the the lack of interest from many otherwise censor-trigger-happy parties, simply because unlike Tor (https://www.youtube.com/watch?v=YlZZQYLIXe8) or the Signal messenger (https://www.aljazeera.com/news/2021/1/26/iran-blocks-signal-...), it's not a mainstream technology that's used by everyone and their dog.
To get back to the topic at hand, I would rather not implement USENET or any client-server-based system as a sort of backup for an otherwise P2P app (e.g. Superhighway84), as I tend to agree with what OP stated in a different comment, which is...
> The thing that frustrates me about free and open source software that requires servers is: most people don't have servers! And the prevalent model for using others' servers involves a terrible power / dependence relationship. One thing that drives me to build Quiet is that I want to see a world where free software comes "batteries included" with all of its promised freedoms and advantages, for the vast majority who do not have servers.
A software landscape in which end-user applications are not dependent on dedicated servers at all, and would instead be able to directly communicate and exchange information with each other, is ideally how I, too, would envision the future. Hence, while I'm a fan and user of USENET, XMPP, IRC and so on, and I have the knowledge and can afford the /luxury/ of renting servers to host these kind of things, I'm far from being the average end-user. I believe that the future should belong to truly peer-to-peer decentralized technologies.
RE the libraries, while it is true that I can't find anything made specifically for Usenet in Go, Usenet itself is just an extension of the Telnet protocol[0], and there are Telnet clients in Go[1] and Node[2]. It probably isn't simple, but I'm sure working with OrbitDB wasn't easy either!
RE the resilience of content on Usenet, the vast majority of binaries are heavily encrypted, and doesn't make sense to anyone without the key, despite being conveyed en-masse between the world's 10-ish full-scale Usenet backbones [3]. I'm proposing that the backend of a service that makes use of Usenet could be similar, with a single 'background server' on one trusted machine enough to continuously push the history to Usenet. A regular user client could then search for the latest version of this history and quickly refresh their side from Usenet, regardless of the status of IPFS at the time.
RE democratic access to technology, at least with Superhighway84 it was very expensive for me to actually run the software, as I have a small allocation of bandwidth from my ISP and not much I can do about that in my area, and I ultimately had to delete it due to ongoing transfers of 3GB/day running the IPFS node. Quiet itself notes a limit of 30-100 individuals with its application - I'm proposing that using the one remaining federated multicast technology with some modern encryption might help with issues around blasting data everywhere from a bandwidth-constrained environment. I know that definitely in Africa, there are ongoing issues with bandwidth and networks that we forget about in the West. Usenet, with extremely lean network overheads, could be part of the answer.
I do agree with your vision of a future of truly peer-to-peer technologies, but for those of us who are bandwidth-constrained or otherwise limited in our access to those technologies, having a technology-agnostic application that just 'does magic' to do whatever it needs to do with your content is what's going to make a majority of users happy.
[0] https://www.itprotoday.com/windows-78/how-can-i-use-telnet-a... [1] https://github.com/reiver/go-telnet [2] https://www.npmjs.com/package/telnet-client [3] https://svgshare.com/i/oti.svg
> Superhighway84 it was very expensive for me to actually run the software
I agree with you, in terms of efficiency IPFS is still miles away from where it should be. Hence my feedback on Quiet, as I do not perceive IPFS to radically improve within the next few months or even years. And as you correctly stated it looks like Quiet uses some workarounds to improve on the overall mediocre efficiency of IPFS, which however lead to shortcomings on other ends:
> Quiet itself notes a limit of 30-100 individuals with its application
However, this is not how P2P should be. I'd be truly curious to hear from someone at OpenSea, or Fleek, or any of the services that offer high volume IPFS hosting about their experience and gut feeling on its future. I personally gave up on hosting my website via IPFS myself -- which I did for a brief period of time -- mainly for these exact reasons.
> but for those of us who are bandwidth-constrained or otherwise limited in our access to those technologies
I believe that quite on the contrary, this might benefit these people the most. Imagine not having to do the roundtrip from your phone, to a server on the internet, back to your computer, just to have a synchronized state of your address book available.
Similarly, imagine writing with someone in your city -- let's say Melbourne, Australia -- without your messages first travelling to Utah, USA, and then back again. My gut feeling is that overall congestion on the internet could even be reduced, by allowing more applications to communicate directly within small meshes rather than travel all the way across the globe and back again. That is, as soon as there are more efficient ways to deal with the overhead that is currently breaking IPFS' neck.
I'm pretty confident that we can get Quiet to the point where the practical limit of participation in any Quiet channel is storage, relative to the amount of message history that a particular community wants to hang on to for a particular channel.
It wouldn't be crazy difficult to shard storage either. Once we do, a community could store a lot of data by marshaling many nodes with low or uncorrelated downtime. Paying for storage is also an option.
I think superhighway84 remains no/low-spam because of the technical hurdle of connecting. I don't think you've got any inbuilt spam protection? Plebbit [1], full of spam. The innovation of Reddit is arguably that people love the power-trip that comes with moderating a reddit group, and will do it for free - there's been no shortage of moderators to replace the protesters in the latest rebellion [2]. Hacker News, where I get to talk to smarter people than myself - very well/heavily moderated [3]. The SomethingAwful forums just resorted to charging everyone $10 for an account when they started having a spam problem, and that happily paid for the hosting costs and a life for the main admin for years.
To deal with the spam, you need some kind of filter where users can't just create thousands of accounts, especially in the age of LLMs. Logging in with a social account is the obvious one - Github/Facebook/Google have expensive processes in place to reduce the deluge of spam accounts, but some obviously creep through. Do you then run on an algorithmic chain of trust, promoting posts based on the quality/ratings of the individual's contributions elsewhere? If you do this, you're creating a system to be gamed. Running on invites only is another potential solution, but then it's difficult to start the gravy train of quality posts - who wants to apply effort to talk to nobody? Do you instead run a pyramid scheme - charge $10 upfront, but give a share of the site's ongoing revenue to those who get their posts upvoted, Twitch/Youtube/Instagram style? This to me seems like the one solution that could potentially displace Reddit, but I lack the personal belief/gusto to make it a reality.
Even if you managed to register and motivate a thousand decent posters, I don't have a clear view of how you keep topics on track within a group without a human moderator, but some research has been done in using LLMs to pre-rate posts based on the history of the group. But if the LLM is agendaless, you obviously get a groupthink echochamber. Give it an agenda, and you start dealing with bias - not every post of value is war and peace, and sometimes you just want to thumbs up a funny cat.
Please forgive the above musings if they're low value. I feel like I have no answers, only problems and questions, and I believe I'll be posting on Hackernews for tech, Instagram for comedy, and Facebook groups for special interests (e.g. car repair) for some time to come.
[0] https://raw.githubusercontent.com/dvasdekis/images/master/20... [1] https://news.ycombinator.com/item?id=36203610 [2] https://www.forbes.com/sites/barrycollins/2023/07/21/reddit-... [3] https://news.ycombinator.com/item?id=34920400
I don't understand this. Can you elaborate exactly what you mean?
Because to me... you're now just depending on a whole bunch of other people's machines indirectly, and directly on the community owner's machine which is generating the certs.
It feels like a lot of complexity for something that could just be a small chat server running on the community owner's server (which they will need anyways - unless I'm misunderstanding, which is entirely possible).
---
So since I'm probably missing something - can I get the elevator pitch?
Assume I'm your target market (I want private messaging that I control).
I would likely be a "community owner" as described in your article.
I am already running a self-hosted solution (ex: Zulip/Rocket/Mattermost).
What makes this a compelling offering to me?
I think you have to clarify what you mean by that. Citation needed.
https://arstechnica.com/tech-policy/2015/01/did-feds-mount-a...
https://www.documentcloud.org/documents/2719591-Farrell-Weds...
https://mice.cs.columbia.edu/getTechreport.php?techreportID=...
https://www.vice.com/en/article/4x3qnj/how-the-nsa-or-anyone...
https://www.techtimes.com/articles/200592/20170307/fbi-drops...
Network layer privacy is even more layered in this way. A burner HN account is very anonymous for a wide range of threat models. But if you're a terrorist or spy, NSA and GCHQ will see to it that they break anything you use. Users can learn about the properties of different tools and make informed decisions. Nobody should do something they would not otherwise do just because they believe they are protected by Tor. That is a bad idea. But if someone needs to do something sensitive and wants to lower their risk profile, Tor will likely help and it's fairly low-cost to use it.
Another way to look at it is: any naively implemented p2p communication tool will reveal the IP address of all your conversation partners by default. Tor is a big improvement over that, and comes with other benefits, like NAT traversal and peer discovery.
(Quiet founder here) Great question! If you're already happy running your own self-hosted Zulip/Rocket/Mattermost/Matrix and you have no problems with maintenance or downtime, Quiet is just a cool demo and probably not useful!
If you cannot run a server (a minority on HN but a majority of the world) or you do not want to (maybe a slim majority on HN?) and you need a team chat with nice privacy properties, Quiet is being built for you!
The thing that frustrates me about free and open source software that requires servers is: most people don't have servers! And the prevalent model for using others' servers involves a terrible power / dependence relationship. One thing that drives me to build Quiet is that I want to see a world where free software comes "batteries included" with all of its promised freedoms and advantages, for the vast majority who do not have servers.
I have high hopes for this, its slow in development but its a difficult problem.
If they can get it to work it can reuse the whole rest of the ecosystem.
Not that it really managed much in mobile, but old-school Skype comes to mind as the most widely used P2P messaging application. That's probably where a lot of the most valuable 'at scale' knowledge is/was.
Given that Skype as it was originally implemented was very nearly this (P2P comms), and was targeted specifically for acquisition by Microsoft by pressure from intelligence agencies (to be re-implememted in a centralized fashion for tappability, see PRISM); I try to encourage every eager startup founder to think about their personal exit early. Any type of software offering that is done as a commercial venture lasts only as long as that founder/idealist is at the helm and there remains enough technically savvy people to fork on the inevitable rugpull. Which from your tech stack, may be an issue.
Anything like this, while noble, is going to inevitably become a hot target for law enforcement/intelligence agency/nation state compromise, or media smear campaign the first time a bad actor comes to light who has been enabled by it. Prepare for this type of stuff as early as possible, and godspeed.
Also, how'd you tackle the key distribution nut? Which is the hardest part of the entire process, in my experience. PKI?
The biggest difference between us and Skype is that Quiet is open source. But yes, open source businesses can rugpull too, as we saw recently with Terraform.
What about our stack makes you worried about the "enough tech savvy people to fork" piece? One decision we've made deliberately is to build on the most widely-used tech, so that maintenance will require less expertise than for a homegrown stack, and so there will be existing communities around the stack that are bigger than the Quiet community. I would love to know more about what problem you envision in building a tech-savvy open source community around our stack. Too boring?
If our business is upselling users to server-backed subscription plans, I think even the threat of a fork goes a long way to keeping us honest, especially since a community fork would not need to run infrastructure. If "Quiet Co." (or whatever we call ourselves) is suddenly no longer the most trusted purveyor of Quiet, we wouldn't have much of a business, which is as it should be in my view.
Re: the politics of providing these tools, I have been preparing, and I have some background in the political side of this from Fight for the Future. It's funny because I am actually quite eager to get to the point where we get to make the social and political case for Quiet to a partly-skeptical world, but first I have to make something that works well on phones! And find users! Ideally we can find some awesome initial users that really tell the story of why Quiet needs to exist.
Cryptography/cryptographic primitives/secrecy preserving architectures are a bitch and a half. :) Toss on top of having the mind/frustration tolerance to put yourself through the wringer to make all that happen without a slip up, then you run into the really hard part of taking all of that and getting regular people able to grok the thing, which takes empathy, a genuine capacity to care for the end user's time/experience, and the capability to synthesize a lotta minutiae into a limited interpersonal window. In my experience; the people with the technical chops to handle the former challenge almost always accrue deficits in the capacity for the latter, and an over abundance of the qualities to succeed in the latter aspect is almost always going to result in some level of talking past one another when dealing with your technical peeps.
It's a problem I've been ruminating on for quite a few years, because I know I'll have to solve it for my friends/family sphere before too long. The process of migrating my own mind from that crypto-weenie who actually knows what a key schedule or S-Box or what a Diffie-Hellman Key Exchange is, or what guarantees you get out of composing what primitives, who gets annoyed that other people just don't get it, or just can't be bothered to put up with a little inconvenience for the sake of reclaiming the privacy that everyone up higher in industrial hierarchy are fine with people not bothering to reclaim, to one that has the patience to sit there and try to render down for Grandma's and such that "doing this is the digital equivalent of putting something in an envelope, that will only open for the person on the other side" is... Well, not fun. It's work.
That's it I guess. I'm just now getting around to wrangling some of what were cutting edge primitives of 5 years ago, because I've lived 'under a rock' trying to get non digital natives up to speed is all. I don't believe just leaving them to die out is an acceptable approach, because if we want this to really catch on from the bottom up, you have to take cryptography, and make it easy enough a child can understand and operate it. That's hard.
It's part of why my peers think I'm nuts. I still try to tackle things like that. Computers should be bicycles for the mind. Not the Wizard of Oz.
I'll be keeping an eye on y'all. You've officially intrigued me.
1. a community member sends you an invite link containing some onion addresses of community members
2. you sync community data and send a CSR to the community owner.
3. We show an "unregistered" message next to your name until the community owner signs your CSR, at which point you're a full member.
We use PKI.js for the certs. For multi-party message-layer encryption with multi-device support we plan on using: https://github.com/local-first-web/auth, which is inspired by Keybase and a Martin Kleppmann paper.
I'm imagining being a dev in a team, I'm the only one connected on a saturday night and and my laptop bursts in flame. Wouldn't it be nice to go to a fresh laptop, just log in the central server and have access to everything without waiting for someone to get online to sync the whole history of all your chats ?
And of course, having to deal with the whole history in the first place feels like a pretty heavy issue. Using this system for a year or two with a few dozens of people would lead to crazy amounts of messages needing to exist on every client.
I don't know how Quiet uses IPFS but a truly decentralised storage system such as the design of Safe Network can hold data locally (eg using CRDTs) and/or in a decentralised, always accessible p2p network of nodes.
Chunking and redundancy ensures data is always available without the need to centralise.
For privacy reasons Quiet does not use the global IPFS network and instead gives every team their own network. This provides a clearer story around metadata privacy protection and (most importantly!) ensures that timed deletion of messages is practical and meaningful. Disappearing messages are a must-have for many threat models, and deletion is much more meaningful when you're trusting clients within a community you trust to delete the messages, rather than trusting every peer on a global network anyone can join.
So there are advantages to having an organization-specific network, and the problem the OP highlights does come up if there are no other devices online. Here's how we think about that edge case of "No other devices are online and I need to send this message before I sign off and know someone will see it as soon as they sign on":
1. If a team is worried about this, a computer under a desk or an Android device in a corner running Quiet is much easier to set up and maintain than a server, and it is trivial to add as many of these as you want in diverse locations until you are confident in the uptime, e.g. that any one of these devices could get unplugged or suffer an internet outage and it probably won't correlate or matter.
2. When running a server that does something important you need to have some separate monitoring setup like Pingdom and have someone on pager duty if you want to achieve respectable uptime. With Quiet, we can build that monitoring into the p2p app itself. We haven't done this yet, but picture a feature where the app shows you the uptime stats of your network and you designate nodes that should always be online. The network itself could notify you of any disturbance that threatens uptime, e.g. if one of your designated always-on nodes starts misbehaving.
3. People who don't want to worry about this can pay us or someone else to run a server for them and we'll make this easy. But it's better than depending on a centralized service because in most cases everything will still work if our server goes down, and they won't be dependent on us the way people depend on cloud SaaS, because Quiet is easy to fork and the fork will work pretty well out-of-the box in most cases with no infrastructure required.
4. It doesn't take many Android phones in full-p2p mode to give you a lot of often-online nodes, so continuous liveness could emerge organically in larger communities and it becomes more about showing metrics to give people confidence that this is the case (and making the experience on Android really nice--optimizing battery life, exposing choices to the user, etc.)
5. A small Quiet community without enough resources or participants to have enough always-on nodes could designate a larger, busier, more infrastructure-stable Quiet community as a trusted helper. The other community wouldn't see the plaintext of messages but it could support message syncing and provide other helpful resources. What I like about this is that well-resourced or tech-savvy communities could support other aligned communities without the hassle and responsibility of running a server.
There has to be a catch to this, right?
The catches are many, but inherently solvable!
1. You have to be online for invitees to initially join your community. We have a release planned this week that will relax/mitigate this.
2. Sometimes it will take 20 or 30 seconds to connect to a peer over Tor, and this is longer than most users expect.
3. Mobile is much harder than desktop and our mobile apps aren't in as polished a state as the desktop app. iOS background tasks and Android long-tail device support are hard!
4. iOS will almost definitely depend on a centralized push notification service for reliable notifications.
5. If you send a message and nobody is online, nobody will get it until you and someone else are contemporaneously online.
And there are more. But your point stands! Quiet can offer a superior onboarding experience in a lot of ways, and it can be snappy for day-to-day use. And thanks for taking the time to try Quiet and relaying this lovely impression to everyone here!
It seemed important to get unique usernames within a community because users expect that from apps like Slack and Discord.
This being on Tor gives me mixed feelings.
Tor's a volunteer run, fairly resource-heavy privacy tool designed to protect the most vulnerable internet users out there -- people facing state censorship on the level of corporal punishment being used, for example. While the Tor network has more capacity these days than it used to, and while having a good toolchain for Tor's intended user base matters, that's rarely the intended user base of apps like this.
When something like Quiet comes along, even with its targeting of users in open societies, it would benefit both technically and ethically from using non-Tor networks: HTTPS is safer than ever, and if you use ECH, DNS-over-HTTPS, and have reasonable cipher requirements for TLS, you can achieve an excellent level of privacy.
For when open society groups need to talk to people at risk of harm, having a Tor bridge or other such mode would be a good way to approach that. It also makes implementing video and audio much easier technically, and it decouples the "casual user" code base from the "sensitive user" code base; while that means you might have less shared code, it also means you can focus on security through simplicity (by way of fewer or less-complex features) for the sensitive users.
[0] https://news.ycombinator.com/item?id=37480552Yeah that will not happen.
It could be a Chinese dissident, it could be someone accessing a child porn forum.
When authorities go to track down the IP that sent requests to another, your IP will be the one listed on that request with no ability to trace back what IP actually sent the request so it will be difficult to not pin you for whatever was accessed.
The child porn traffickers and other problematic users are all on Tor already. With the growing number of users their proportion will only decline.
[citation needed]
This is why it is important to bookmark ExoneraTor [1] so that one can prove the IP in question is/was a Tor exit node accepting that it would still be a PITA to deal with boots-on-neck and legal fallout.
That said one could block some of the known illegal sites via DNS and IP null routing on the exit node at the risk of the Tor network flagging it as a malicious exit node.
Quiet is a founding member of Tor's Onion Services Resource Coalition, which started in response to last year's DDoS against the Tor network, which affected onion service connection times. Alongside a small circle of other affected products we helped Tor raise enough to hire ~2 full-time engineers to work on onion service reliability, which had been a bit underfunded because onion services only represent a small share of Tor's existing usage.
Obviously the performance of tor is reduced when traffic increases, but performance isn’t the goal, privacy is. Increasing the traffic of "normal" use cases (as opposed to those targeted by state-level opposition) improves privacy for the entire network.
I agree that using tor for all your video conferencing and streaming needs is probably irresponsible, possibly unethical, but the performance is likely to be so poor that it’s not a good use case anyway.
Using tor for everyday text chat (by real humans) is unlikely to have a negative performance impact, and it does provide more noise for attackers to sift through, so it could arguably improve privacy for those who need it most.
What matters for Tor is plausible looking traffic and uninteresting people doing uninteresting things with it. Then you can’t use traffic analysis to identify Tor users as points of interest.
If everyone on Tor is evading an oppressive government then oppressive governments can just use Tor to identify the people evading them.
I agree, but if performance gets bad enough, people will look elsewhere and to possibly less-private solutions. It's parallel to the whole idea of a tradeoff between convenience and security that I've had to deal with for a big part of my career (and personal anecdotes aside, why adoption for tools like PGP never picked up, at least in part).
Anyway, my original comment's mostly moot as an argument (though I'll keep it around for discussion's sake) -- the founder replied and it sounds like they're working with Tor to make sure the network stays healthy, which is all I really care about.
nit: Every competent developer I know uses PGP on a daily basis, for signing and validating commits. The responsible ones also use it to validate security-critical software is coming from the expected source. I do agree though, that the original use case of encrypted email is largely dead.
With security-critical software, specialists take on the burden of knowing how to use it as part of being in that field.
Email sadly has none of those, and the one client I've used with a "normal"-user-friendly GPG interface (Nylas N1) is now a subscription service with limited adoption. Enigmail was better than the CLI, but still not super intuitive for the average person.
I've been a bit breathlessly replying to comments and am now late for a weekly team meeting, but I just wanted to say that we're friends with the Tor Project, they like us and support apps like Quiet (and Briar, Cwtch, etc.) existing, and we're also part of a small circle of Tor fans who funded Tor to hire two full-time engineers to focus on onion services reliability after the DDoS attack last year, so we're donors to the project too.
Also, it's likely that distant future versions of Quiet (where we reach a large audience) will use Tor as just one way to connect. Gotta go but will respond more thoughtfully soon!
In a world where Quiet is a significant portion of Tor's ~2-3 million users (good problem to have!) we'll be in a good place to add other transports. Someday Quiet could even encourage users to run Snowflake bridges! (Though we have a lot of work to do before that would be meaningful at all!)
Also, thanks for saying that and for updating the comment in response to more information! People aren't always so gracious in online forums and I'm sincerely grateful.
The more immediate issue for Tor is the vulnerability to fingerprinting if the use of Tor Browser falls below the comfortable levels.
Is ESNI or ECH actually in significant use?
With low adoption comes the risk of flagging by bad actors on the network, but hopefully that goes away quickly after ECH comes out of draft.
The silver lining of having so much of the internet controlled by massive, monolithic actors like Cloudflare and Google is that when they flip the switch on ECH, it'll be widely in use within weeks or days, not months or years; and while I don't keep up with Google's involvement, it does seem like Cloudflare's been active on the ECH front with the IETF.
While this is the reason Tor was created, I don't believe it's good to segregate usage based on whether we actually need that level of privacy or not. If anything, using tor when no one else uses it may decrease privacy, because you're more easily targetable. If everyone uses it all the time, it's not clear anymore whether you're using it because you actively try to protect yourself or it's just there. Just like SSL was created at a time when businesses started to get interested in the web, now TLS is used for everything and can't be used to target specific uses.
Tor is like vaccines and masks: it works better if everyone uses them
It also says it relies on OrbitDB, which runs on the IPFS, but IPFS has to run on clearnet, and when the user accesses a content, then an observer can see what content they fetched because their node will broadcast it. I feel like I'm missing a piece here..
The Readme also says Tor2web is used to share files. I'm not familiar with this, but wouldn't that require the user to trust the entities who run these servers to not snoop on their traffic before it enters the Tor network?
Tor2web makes the claims a little suspicious, but technically speaking the system could work.
Now that Veilid is out (https://veilid.com/), that seems like a much better base to build a messenger on top of, but it probably doesn't support the IPFS features this thing requires. Maybe a v2 can use it to get the privacy features it needs.
IPFS can actually run quite well over Tor, and you don't have to use IPFS on a big global network for it to be useful.
We've modified the libp2p WebSocket transport to connect exclusively over Tor to Tor onion services, and we give every Quiet community (like a Discord "server" or Slack workspace) their own IPFS network. Since Tor v3 onion addresses are unguessable, this creates a nice outer security boundary around each community.
As others in the thread have pointed out, the disadvantage of not using a global IPFS network with "pinning services" etc. is that if no one else in your specific community is online, asynchronous message delivery will be disrupted. That said, I believe the privacy benefits are well-worth it.
IPFS is also much more performant when running on networks of a few hundred or thousand users, as opposed to the big global network, so that's another nice thing about the approach we've taken, in addition to the privacy benefits.
TCP DHTs may not be efficient, but efficiency isn't one of IPFS's strengths anyway, in my experience.
From a glance, it just looks heavier, more complicated, more moving pieces and opportunities for bugs.
Where Quiet goes farther is that Richochet (and I believe TorChat) offered 1:1 synchronous message delivery where each user sends directly to another user's onion address. Group chats were not possible, and messages were delivered only when both users were online. In Quiet, having a gossip network (libp2p) and a CRDT (OrbitDB) lets us do group chats with the "eventual consistency" property that messages sent while you were offline can be synced from other peers when you return. This also allows for asynchronous message delivery of DMs in most cases: you can gossip your (encrypted) DMs to all peers, and as long as there is a continuity of syncing between peers, the recipient will be able to retrieve them even if you are no longer online. So yes, there are some more moving parts, but they let Quiet be a lot more like Slack, Discord, Signal, Messenger, and most modern messaging apps than TorChat or Ricochet were, which means Quiet can be more functional and familiar to new users looking for alternatives.
I remember Tox from back in the day, but to my chagrin I have not assessed it since I started work on Quiet (I try to keep up on these things but there is so much prior work that didn't catch on for one reason or another!)
At a glance, it looks like Tox supports groups, which goes beyond Ricochet.
The most obvious single difference I see between Tox and Quiet right now is that Quiet is available for iOS (Testflight, for now) and Tox is not. iOS support has been a brutal slog (and the slog is not over) but it is a deal-breaker feature for every real-world team or community we have been able to talk to, so we are committed to making it work well.
I've been meaning to write one for BitTorrent Bleep too, which is also interesting prior art.
https://github.com/TryQuiet/quiet/wiki/Quiet-FAQ#how-quiet-c...
Tor comes with a bunch of features out-of-the-box that are really convenient, like NAT punching or encryption without SSL certificates.
Today we have better options for hosting but none for dns and encryption. DNS+TLS doesn't come close to the security and reliability provided by having your address be your public key. In fact, and don't think any addressing scheme does.
Offering your service as an onion service or at least making your (secured) admin panels accessible via tor is a no brainer in my opinion. No other entity can accidently block access as long as you have the private keys and tor is up.
Very good suggestion, thanks!
Tor startup and onion address connection times can be slow, but this is improving!
So the dev(s) are indeed claiming it's an alternative to both Slack and Discord.
Criticism is helpful and can inspire others who do have the time and skills to direct or fork the project into something more useful.
> Very impressive project! It's neat that you can get this far without relying on any central servers at all. Personally though, I'm missing a couple more features – this only has textual chat and file sharing, while Discord or Slack have a lot more niche features. Achieving feature parity is a prerequisite for getting any user base nowadays, so I hope it is something team would account for before the 1.0 launch :-)
I agree with the objection that not everybody can just contribute patches for major features to an open source project, and I think it's fair to say that the comparison to Slack and Discord is not 1:1 without voice and video calls (which we do plan to offer someday, FWIW) and to feel disappointed by that. Though I think when an open source alternative emerges it is usually understood that it could take a while to get to feature parity, and we try to be very clear about what Quiet already does and doesn't do yet on our homepage.
That said, Quiet is written in TypeScript and built on a web stack almost every engineer is somewhat familiar with, so it's really easy to get hacking on, and we'd love the help. :)
Here are the instructions to build Quiet desktop: https://github.com/TryQuiet/quiet/blob/develop/packages/desk...
And here are some good first issues! https://github.com/orgs/TryQuiet/projects/3/views/1?filterQu...
Tangential but have you considered something like https://tauri.app/ instead of Electron for the app? (One of my major concerns with Electron apps is that every app ships and runs its own copy of Chromium – Tauri mitigates that by using system web engine instead.)
As noted on our website, we still have a lot of work to do on security (including some open issues you could probably tackle! and thanks for expressing interest!!) so it will be a wonderful day when Electron's lag in staying up to date with Chrome security fixes is our most pressing security issue!
In the meantime, if Signal chooses Electron that is a good indicator that, all things considered, it is a good choice for us. They have a lot more resources than us, are much farther along than we are, and they take security seriously.
One immediate issue with Tauri, just to give an example, is that it would require us to worry about Safari quirks on Mac.
I've also heard from projects in our space that the handling of platform-specific functionality outside the browser window is not as mature in Tauri as it is in Electron. This is totally understandable and Tauri is a great project with great goals, but the possibility of running into some deal-breaker Windows-specific issue, say, is scary.
Based on our research with users who need sensitive communications, a working Slack or Discord alternative without video calling is desperately needed by some teams right now. (For example, teams who want end-to-end encryption but have a big community with highly specific moderation and vetting needs.)
So starting with text, images, audio messages, etc. can get us a foothold and we can build from there.
Just getting Quiet working as reliably as a centralized chat app on iOS and Android and finishing things like multi-party e2ee group chats with multiple device linking is going to be a big lift that could easily take us 6 months or more. Group video calls can come after that if our initial early adopters are asking for it!
LibreOffice is still an alternative of Microsoft Office without having all the features. Firefox is an alternative of Chrome without WebHID or Web Bluetooth.
Discord's initial pull was from gamers who were using teamspeak/ventrilo/mumble + twitch chat and maybe IRC.
If it doesn't do VoIP then it's not a viable alternative to Discord.
It'd be like if LibreOffice couldn't save new files or if Firefox couldn't render images or video.
I didn't stop using Mumble or IRC because they couldn't, combined, meet my needs. I even prefer them to Discord on a principle basis.
But everyone I wanted to communicate with moved to Discord because it was easier -- as it had both core features which are necessary for gamers.
That's the real reason why you use Discord. Peer pressure.
Discord is in no way a replacement for a forum
I’m quite a techy person and I even wrote my own frontend to Discord a while ago, but I’ve struggled with things like bouncers and authentication to the point where it’s just easier to set up a bridge to Discord and use that when I need to use IRC, and then I miss features like editing and profile pictures (there are proposals to add these things to IRCv3 but they aren’t widely supported)
IRCCloud seems to have a good solution to some of this but is paid
It is, however, a potential alternative to one common use case for Discord, namely: "What we really wanted was a web forum, but this is easier."
This describes all 15 of the Discord servers I'm currently on.
What does discord offer that reddit doesn't? (In terms of being a web forum)
(My only experience of Reddit is from Boogle searches landing there [an immediate point in its favour over Discord] and it appears to be pretty heavyweight, loads down the browser even more than Discord, and has ads everywhere - maybe the experience is better if you actually create an account and log in?)
https://en.wikipedia.org/wiki/Substitute_good#Imperfect_subs...
stares at MS Teams
vomits
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!)
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.)
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.
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.
That said, they have to solve more problems than just the problems solved by Pinecone. (Like onboarding and identity.) And over the past few years my impression has been that the Matrix team is focused on the federated use case, because that's where their users are. It seems hard for them to pay attention to both.
My guess is that P2P Matrix will land as an awesome reliability feature for uninterrupted messaging when a server goes down or when the Internet goes out, but that it will take longer for them to tackle problems specific to P2P that don't graft on easily to federated Matrix.
However, you're totally right that our main focus is on the federated use case, because that's where everyone is today, and its own fair share of Hard Problems (e.g. reliable decentralised E2EE, byzantine-fault-tolerant conversation replication, decentralised ACLs, lazy-loaded conversation state) before we chuck P2P into the mix too.
The P2P Matrix project is currently focusing mainly on MSC4014 (i.e. pseudo-IDs, account portability, multihomed accounts) which benefits both P2P and normal Matrix... although I'm hoping that we'll get back to Pinecone & actual P2P work eventually (especially if someone explicitly funds it).
Meanwhile, it's super cool to see the progress on Quiet and OrbitDB. It's come a long way since Orbit launched at the 2016 Decentralised Web Summit, and I'm glad to see the tech is still progressing. FWIW, We did the first versions of P2P Matrix on top of libp2p (but then switched to Yggdrasil and then Pinecone in order to work with a monolithic stack, for better or worse). Might be interesting to figure out how the projects could interop in future :)
It has nowhere near the features of Matrix at this point, but it is useable and I'm having fun with it, and I really look forward to see progress on both projects. :)
Re: interop, the easiest way to interop would be if Matrix solves all these problems for us before we get anywhere close! Then we can be a P2P Matrix client or just use Matrix :)
But I bet either way it will be possible to make robust transformation layers between different eventually consistent protocols. This is similar to one of the hard problems: interop between multiple versions of a single decentralized application. If we solve that it might generalize if we can bridge the network layers too?
And yes, there is indeed a really long list of hard problems to solve. I really really hope one of us, or one of the other similarly motivated projects, is able to solve them all and deliver the whole package!!!
* 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?
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?
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.
My family tests this type of software often enough. I know my daughter, [[j3d1h]], desperately hopes for a secure replacement to Discord for her [[friend]] groups. She's sitting on the couch with me right now writing up what she's missing most in your software. Here is what she said:
```
just my opinion, man
-how are profiles going to work? do you have an individual username for each community, or will your profile eventually be the same across all the communities you're in?
-profiles you can customize to servers *can be* useful, so long as you can still trace them back to the user's actual profile. otherwise that might enable masquerading as other users
-users able to mark as invisible (appearing offline without actually being so)? good to have in many situations imo, obscuring information from people who may be a danger to you
-how is name collision handled? in a large community, you're bound to have a few people who want the same name (and i get it, your screen name can be very personal)
-discord's old solution, a username and 4 digit id (e.g. felix#1234), seemed convenient and effective to me, but there must be tons of solutions; i like having a way to easily distinguish two users with the same screen name
-personally blocking users you are uncomfortable interacting with, kicking users from communities vs. banning repeat offenders in a more permanent way, temporarily muting a spamming user?
-kicking vs. banning can be an important distinction; i'd rather kick you if you're just inactive all the time, you're free to rejoin whenever you like
-i like keeping it very, very clear what does (or does not) happen when you block, kick, ban, etc; a user shouldn't have to "test" features like these
-important to keep in mind that you rarely (or never) want a user to completely disappear; i always want to leave the option to get back in touch, unban, unmute, etc.
-a friends system is useful for this; maybe i don't want anyone i haven't marked as a friend to DM me
-selectively muting different portions of the app (e.g. i *only* want to be notified of a DM or @ mention, or *only* notifications from *this* community, or no notifications from this channel except @ mentions)
-what if i want to be notified whenever this phrase pops up in a community? might be a question of how easily you can build your own scripts *on top of* Quiet (which i would quite like to do)
-are voice and/or video planned, both in communities as well as dms?
-muting + deafening + turning off camera, nothing in a voice/video chat should be mandatory (owners shouldn't be able to *un*mute someone, but owners muting others can be useful)
-maybe i want to mute that user, but allow everyone else to hear them? turn this one up and that one down on my end?
-audio controls that make sense. if there's a layer of noise cancellation, leave the option to turn it off in case it messes with your audio, etc.
-taking microphone input as it is works just fine, though i can see some users disliking that (mostly people who don't know how/can't modify their settings *outside* of Quiet)
-i've seen many communities in other applications where multiple "owners" existed, as it can make a more safe/welcoming community
-if one owner in any way becomes untrustworthy, having someone with equal permissions in place to get rid of them and undo damage can help; whether they can remove each other or not seems like an important decision
-question about the threat model; members are not capable of sending messages that appear to be from another member, which implies that owners *are* capable of this? that could become a serious issue if true
-user discovery outside of communities, preferably just typing in a username they send you elsewhere?
-will it be possible to delete an entire community? can an owner do this in situations where members don't agree?
-searching channels (and more advanced searches; sent by this user, with an image attached, in this channel; hopefully accessible to users even if they can't do regex on the fly, lol)
-i've found it frustrating not to be able to search every community i'm in at once for something i said; is that feasible?
-any distinction between a community and a DM with 3+ users in it?
-i don't personally see the point, but some apps have this
nitpicky, visual polish, further off details
-dark mode, and in my opinion, ideally a way to customize everything more thoroughly
-if thorough customization, maybe a way to save/export those settings to share?
-maybe the ability to see separate messages sent in a row - is that a message in 3 lines, or 3 messages? just hovering and seeing one line highlighted (and the timestamp for just that line)?
-embedding video and audio files in a convenient manner?
-replying to messages, pinning them to channels (so they can be easily found again) seem very useful
-channel organization and categories; i don't always want the art channels open, i want #announcements at the top, etc.
-messages marked as read/unread can be useful, something to carefully think about
-sometimes i like knowing that someone has read my message; sometimes i like the safety that comes with people *not* being able to know. if i had to pick, it'd be the latter, users can always prove they have read something by responding to it
-client side unread; i'd like to pick up from the last message i read in this channel
-having channels visually marked that there are unread messages is nice
-keyboard navigation beyond pressing tab is super useful; a screen you can reach to describe these shortcuts is equally so
I hope you'll consider adding more control over the keys within the application itself. Ideally, I should be able to generate my own private key from scratch, paste it in, and recover at least a bare identity (this can be bootstrapped further). I should be able to hand someone just a public key for any of the functions we may need; these keys should be easy to copy and paste into and out of the application. Key control pedagogy is not fun, but it's ultimately required for us to own the means of production; I think you've a difficult usability fence to straddle here, and perhaps a ladder to construct.
> 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.
What feasibility concerns do you have?
> 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.
Lawd, I'm a preachy sumbitch here. I have yet to find a tool that I think does this really well. It's probably going to be crucial to have not only sane default but strong controls available to users. I am pretty worried you won't escape some elements of federation or at least asking users to rely upon friends or additional devices. Can kids across the planet safely pirate arbitrary files on their phones together? That's the bar, homie. You know whom we serve, and I think you're doing it. I [[hope]] we don't fail.
Do not make the mistake that [[Aether]] did on retention, please. Users must have the opportunity to pin/seed with complete persistence. Any tool (e.g. [[Session|2021.09.25 - Computer Musings: Session Fucked]]) that has forced me to lose my identity or my messages is not a tool I'm going to recommend to anyone again. I understand you may wish to minimize the prices the average person must pay to manage their data, but at some level, there is so substitute for having the user be responsible for it. Joining a room without having to traverse and download an entire graph of content will be important.
Low-end phone performance (not the mobile devices you and I can afford) is such a hard and important problem that I wouldn't be surprised to find that what you're making at the moment is ultimately a prototype. I obviously [[hope]] I'm wildly wrong about that.
> We would love to pursue this if our users ask for it. So far there isn't a strong signal that users need it.
Then please ignore my desire. Your task is already absurdly difficult as it is.
> 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.
It's so interestingly phrased, I feel uniquely qualified to speak on this matter. I probably hold a contrarian position. This is obviously an imperfect way to do it, but I'll leave the tool up for a while; you'll find the link in this room (channel is your handle): ukkmcdhhymxki3plly2w7mkweafijihwhldwnmt6yzwan6rmtuin7zid.
> But technically this would be a fun challenge and I'm sure we could build something great. There are other CRDTs we could use.
Speaking of a narrow challenge, E2EE P2P Tiddlywiki isn't that far off. You might consider hitting [[Sir Jeremy Ruston|2023.08.08 - TW-Community: Hello]] up (TW5-Bob is also dope; and Jed would understand what you're doing well, imho).
> This would probably be straightforward. What's your use case?
I provide access to my constantly updating site (almost exclusively consisting of a single ~60MB html file growing at ~8MB of pure text a year on average) over multiple networks, and few are designed for such a thing (you're already got a foundation for something better than Zeronet and Beaker [both venerable projects, obviously]). I [[share]] mutable directories with many folk, some of whom I cannot [[trust]] (I often have to use Whonix). I need a turnkey multi-platform open-source replacement to Resilio Sync that people are comfortable using. I understand you will be limited by IPFS here as well; I can share 6TB of an evolving curated library using just a couple gigs of RAM on Resilio Sync (with selective syncing on mobile), and I can speedily and efficiently share my `/home/h0p3` (millions of files) across my devices with it as well. I hope to be able to recover identities, contents and all, seeded on these networks. Writing a Discord-killer is already a [[monster]] of a task (bless you), but mutable torrents with a solid chat-based community is where you can walk on water where no one else has.
We're starting with names specific to each community, since that is simplest/cleanest and best for privacy.
> profiles you can customize to servers can be useful, so long as you can still trace them back to the user's actual profile. otherwise that might enable masquerading as other users
There are some decentralization-friendly ways you could link your profile to other profiles, like a Discord or HN account. tlsnotary.org is one example. Would that be good for preventing masquerading?
> users able to mark as invisible (appearing offline without actually being so)? good to have in many situations imo, obscuring information from people who may be a danger to you
we do plan to do this, but it's some complexity to really hide it from a tech-savvy malicious user, so the first version of invisibility will be weak and we'll tell users this. Here's the open issue and there are links to proposed designs in there if you'd like to give feedback! https://github.com/TryQuiet/quiet/issues/1504
> how is name collision handled? in a large community, you're bound to have a few people who want the same name (and i get it, your screen name can be very personal) discord's old solution, a username and 4 digit id (e.g. felix#1234), seemed convenient and effective to me, but there must be tons of solutions; i like having a way to easily distinguish two users with the same screen name
we're not allowing name collisions for registered users. in the coming release there will also be unregistered users who will have a badge until they register with the community owner. if the community owner lets registered users' names collide we treat that as an impersonation attack and warn everyone. since names aren't global you'll usually be able to get the name you want!
> personally blocking users you are uncomfortable interacting with, kicking users from communities vs. banning repeat offenders in a more permanent way, temporarily muting a spamming user? kicking vs. banning can be an important distinction; i'd rather kick you if you're just inactive all the time, you're free to rejoin whenever you like
we don't have user removal yet but obviously that's a big priority for us.
since we don't have usernames, to ban somebody you would kick them and reset the invite link. blocking and muting and silencing people will all be very straightforward. as will roles and other kinds of moderation, and external identity linking would be helpful for this too. you'd be able to make someone link another profile and approve who you are letting in.
> i like keeping it very, very clear what does (or does not) happen when you block, kick, ban, etc; a user shouldn't have to "test" features like these
this is a great note, thank you!
> important to keep in mind that you rarely (or never) want a user to completely disappear; i always want to leave the option to get back in touch, unban, unmute, etc.
hmmmm. this is an interesting and cool idea I have not run into before. yeah, unban and unmute are possible.
> a friends system is useful for this; maybe i don't want anyone i haven't marked as a friend to DM me
Our first plan is to not allow DMs at all outside a community, but there are some ways we could do this.
> selectively muting different portions of the app (e.g. i only want to be notified of a DM or @ mention, or only notifications from this community, or no notifications from this channel except @ mentions)
this is planned, and thanks for the details! Here's the issue for channel notifications: https://github.com/TryQuiet/quiet/issues/623
> what if i want to be notified whenever this phrase pops up in a community? might be a question of how easily you can build your own scripts on top of Quiet (which i would quite like to do)
i'd love to enable this someday but we have no immediate plans to. but it is one exciting thing about a fully user-controlled app: you can give users a lot of flexibility. Imagine a team chat that was as flexible as Wordpress!
> are voice and/or video planned, both in communities as well as dms?
yes, but I'm not sure if we'll do unlimited group calls for free, since we'll need servers for this piece so it's a natural place for us to charge money (we'll need to). And I don't really have clear plans for how voice or video will work yet, since it's far off.
> i've seen many communities in other applications where multiple "owners" existed, as it can make a more safe/welcoming community. if one owner in any way becomes untrustworthy, having someone with equal permissions in place to get rid of them and undo damage can help; whether they can remove each other or not seems like an important decision
yes, we'll allow multiple owners at some point, though the naming role will belong to one user. https://github.com/TryQuiet/quiet/issues/1758
> question about the threat model; members are not capable of sending messages that appear to be from another member, which implies that owners are capable of this? that could become a serious issue if true
this is an issue right now yeah. what we can and will do very soon is show an aggressive warning almost immediately in most circumstances if this happens. see: https://github.com/TryQuiet/quiet/issues/119. but there are edge cases where spoofing could happen that are hard to reason about or convey, so it's unlikely we'll fully address this weakness soon.
> user discovery outside of communities, preferably just typing in a username they send you elsewhere?
Global naming features like this exist in tension with decentralization, unless you make people pay for usernames, which isn't a great experience.
> will it be possible to delete an entire community? can an owner do this in situations where members don't agree?
Yes. A member could block deletion by not going online or by modifying their Quiet app, but deletion is important enough for activists that we want to make it easy. Maybe this is a setting on the community level or user level.
> searching channels (and more advanced searches; sent by this user, with an image attached, in this channel; hopefully accessible to users even if they can't do regex on the fly, lol)
we'll definitely have search but don't yet!
> i've found it frustrating not to be able to search every community i'm in at once for something i said; is that feasible?
yes! it's all on your computer so totally feasible and this is a helpful note! i feel this way about email all the time when using gmail so I get it.
> any distinction between a community and a DM with 3+ users in it?
DMs will exist within a community; a community is at the level of a Discord server, e.g. We're not planning to do the Slack thing of giving ad hoc group chats their own special status, but 1:1 DMs will be special probably.
> dark mode, and in my opinion, ideally a way to customize everything more thoroughly. if thorough customization, maybe a way to save/export those settings to share?
We already have designs for dark mode: https://github.com/TryQuiet/quiet/issues/1502. what app or site does customization great? what approach can we follow, if any?
> maybe the ability to see separate messages sent in a row - is that a message in 3 lines, or 3 messages? just hovering and seeing one line highlighted (and the timestamp for just that line)?
these two things drive me crazy too! See: https://github.com/TryQuiet/quiet/issues/505 & https://github.com/TryQuiet/quiet/issues/1403
> embedding video and audio files in a convenient manner? replying to messages, pinning them to channels (so they can be easily found again) seem very useful
we'll definitely do this!
> channel organization and categories; i don't always want the art channels open, i want #announcements at the top, etc.
Cool, I'll make an issue for this!
> messages marked as read/unread can be useful, something to carefully think about. client side unread; i'd like to pick up from the last message i read in this channel
we have a floating "unread" notification but there's more on this to do!
> sometimes i like knowing that someone has read my message; sometimes i like the safety that comes with people not being able to know. if i had to pick, it'd be the latter, users can always prove they have read something by responding to it
We can do either but now we don't show who has read your messages, with the same caveats as above about strict invisibility of your online status being tricky.
> keyboard navigation beyond pressing tab is super useful; a screen you can reach to describe these shortcuts is equally so
Yeah! Ctrl-K works right now for jumping to channels but we don't make it discoverable enough.
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=37381508
You'll be filling that gap, and it is a badly needed one from an anonymity /E2EE functionality perspective.
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.
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?
Push to talk was a thing in old-school mobile telephony. It's basically audio messages but they play as soon as you receive them (or stream) so it feels more like a conversation.
1. Can the protocol support it (well)
2. Is the tech mature enough / is there enough contributors to ensure the client adds support
For a new tech only the first bullet point is relevant - from a brief scan it seems like a hopeful but emphatic yes.
I guess there's a third soft question which is, does the project have the branding, polish, marketing clout to gain traction: much harder to gauge but looks polished at least.
A project does not have feature parity until the features are actually built—promises that the features are possible and if you really wanted it you could build it yourself are nice in their own way, but they're not features.
> many messaging softwares seem to not understand what feature parity is.
That implies either no intent to implement feature parity, or having had enough time & resources to do so without bothering to. Neither of those things are the case here - hence my breakdown.
I've edited my comment to better address your particular point though, thanks.
Most companies use multiple products even if they could use less.
As an example, most companies using Zoom also use Slack. So they don’t use all the slack features although they could. Maybe because they think, for whatever reason, Zoom is better at conf call and Slack is better as chat application.
The same is true with Teams, that basically any company owning office licences get for free and still prefer using something else (because it’s garbage).
So if you can make a chat app that can make Slack look garbage as a chat app, you don’t need feature parity. Maybe adding an integration to external conf call services like Jitsi or Zoom can be enough for your potential customers, especially if they already pay for those.
Slack's huddles are about eliminating the friction for hopping on a voice call. There's no waiting time for Zoom to start, no camera check, no "join with computer audio". You can go from a synchronous text-based conversation to a voice call in two seconds flat, as soon as it becomes obvious that's what is needed. That is the value proposition of Slack huddles, and external tools can't replace that.
I think both this point and OP's point can be true, depending on what the value is that people get from switching from Slack to a secure alternative. (And yes I've also been in teams that usually used Zoom or Meet but where the convenience of quick 1:1 calls in Slack was really nice!)
If a team is sufficiently desperate (as some we've talked to are) for something with end-to-end encryption but specific advanced moderation features that Signal lacks, then using Zoom, Meet, Signal, or some other video calling solution is fine. Sure it will be annoying, but there's a clear benefit the organization gets in return.
And yes, most teams do not get enough value from e2ee (or don't yet believe that they do) that giving up on the frictionlessness of a Slack huddle is worth it for them.
If we find product-market fit with an enthusastic niche of teams that need security, we'll be able to grow from there and address their needs for video calls too. If we can't find some users who are passionate about the particular advantages of what we're offering and willing to trade some features and convenience for those advantages, we're toast anyway :) (But we think we've found some!)
I wish my company believed this.
Surprisingly it is unsuitable for the purpose. My node had ~800 peers, but only half of the nodes around the world were able to download anything even more than 24 hours after publishing.
I don't know what's wrong but seemingly IPFS suffers from permanent brainsplit condition.
We've run real tests with hundreds of nodes on Fargate and saw message delivery times grow to just a second or two. Plus there's a lot of room for optimization because right now OrbitDB doesn't even use the gossip network for broadcasting message data--it just broadcasts DAG heads and peers have to fetch message data in a second step!
Making initial connections between peers is slow over Tor, and there are some known issues in Quiet right now when switching networks. But those aren't IPFS issues and once you're connected it's surprisingly fast.
Also, while IPFS suffers from scaling issues, the underlying gossip network (which for us is the most important part) is currently powering the Ethereum beacon chain, which has a massive number of peers (~800,000 IIRC?). So the gossip protocol library Quiet builds on is very robust. Future optimizations of Quiet will likely move the burden of moving data down the stack to the gossip protocol, and only use IPFS for "catch up" syncing and ensuring eventual consistency.
Dear devs I know some tech are trendy, but please focus on good tech, not monsters.
For socials we have Usenet, today antispam can handle the task, and the rest while from another era works well enough. For chat we have IRC and XMPP, with the latter far more modern, featuresful and still simple enough, we have mails. Sharing files is still complex but syncthing works for mere exchange, ZeroNet is good enough for simple distributed web.
We have enough crappy monsters from the commercial big tech world to add others.
~/kubo$ find . -name \*.go | xargs wc -l | tail -1
59629 total
~/irssi$ find . -name \*.[ch] | xargs wc -l | tail -1
88551 total
Obviously ipfs doesn't have the chat UI, ipfs is just a protocol layer.
But it is a more complicated protocol than IRC, so you'd expect it to be larger. I don't think it's large out of proportion, certainly not large enough to call it a "MONSTER software".
I can run Quiet in the background all day on my Pixel 6 and we haven't even started optimizing for battery life yet.
You can't be serious. Should we abandon displayport because we have vga?
We love XMPP and IRC, but both IRC and XMPP require servers, and most people don't have a server or even a friend who has a server, so they depend on Google, Facebook, etc.
There may be work in the XMPP space on a pure p2p XMPP, but based on my conversations with folks in the (awesome) XMPP scene last year at FOSDEM, it was pretty experimental and there were major problems they hadn't tackled yet, like identity.
Quiet is an effort to make a chat app that works well out of the box without depending on a server (or a company.) This feels new, different, and helpful to the world right now! And achieving this goal feels worth loading a few MB of dependencies or even (gasp! wince!) Electron :)
Generally I agree that the goals of Quiet are sufficiently different to the way XMPP is used/deployed today that your entirely different stack is warranted. While people do use XMPP with Tor today, and I'd like to add native Tor support to Snikket at some point, I don't envision that ever working the way Quiet does.
Nevertheless, an XMPP<->Quiet bridge would be a fun project for someone, some day :)
> most people don't have a server or even a friend who has a server,
That's wrong from my point of view. In the past, in the dialup era that's normal, but we are in the fiber optic broadband era, at least in vast part of the world who are essentially the parts where IT is developed and used, so it's wrong not to have an IPv6 static global per device, it's wrong not having a domain name per human being, at least per Netizen.
Correcting this is anyway needed because even with modern connections distributed solutions have too much overhead, too little performances to be generally used. Having a homeserver, a direct connection with own devices, from cars to "smart" water heater should be normal for those who want it, normal without intermediaries but still with server, we need to know our infra.
Building giant tools to circumvent actual state of things is technically fascinating, give end user a friendly UI is remarkable but it does not really solve the background problem: giants services will be much more performant. On contrary no giant can offer something more effective than a direct connected services for any user, from a single device with data and logic and UI on it, to LAN to generic P2P connection without extra overhead. As a small example no VoIP services can be faster in my LAN than my local softphones/deskphones talking each others. No GMail alike service can search faster than my local notmuch-emacs on local maildirs. No file sharing services to exchange a file can be faster than a direct connection between someone else and me, at the maximum extreme they can be nearly equivalent.
At least, that's my vision: no chance to win competing with big & powerful on such tech, some chances pushing a local first, wide open connection between peers for the rest because users are needed, but nerd, people who know what they use is even more needed to start, just understanding IPFS from it's code and "docs" is challenging, understanding IRC is far simpler.
It was simple, light, beautiful, distraction free, user centric and fast.
LOLOL. Ask HN: "How to produce a native client without being shunned by HN?"
Rust doesnt have any mature GUI frameworks, and Lisp is probably the best choice here (for some reason).
Anything that accept OIDC or is federated for the second.
Matrix doesn't totally fit the bill yet, but zulip does, so that's what you should install.
But the one that surprisingly seems to be the best is probably email. We don't have the proper MUAs yet, but deltachat (https://delta.chat) shows that there is no reason for us to be limited to decades-old paradigms and should reinvent ourselves.
In which sense?
I boycott both tools, but there are many respectable communities relying on them (unfortunately).
Indexing is still a problem for social servers as well, but unfortunately there are no alternatives. The only current solution is to use bots to upload archives of public channels to say the Internet Archive.
Getting someone on the g0v slack is as easy as giving them a link. The entire experience is straightforward from there.
Maybe one of the federated softwares is to that point and I don't realize it, I deploy a lot of federated software but I haven't done a chat application in a long time.
I think this just cannot work if this is called alternatives. GauntletWizard wanted to specifically point this out: it's a mistake to think that the core functionality of slack and discord is just chat rooms & messaging, their mechanisms that implies terrible privacy are part of the core, and you can't expect users to dissociate messaging from the rest and call it a replacement.
+1 for having «our thing», but promoting it by bogus comparison or replacement is setting it for failure.
Chats/voip when self hosted are more dangerous to its users. I know it from experience.
For enthusiasts maybe good, eventually maybe there will be ISP like providers which can guarantee hosting these nodes
The (1) may be good guys like whistleblowers, or journalists under oppressive regimes, or less so, like black market traders or gangsters. Also, a whole spectrum in between.
The (2) are kids of all ages who love to play. If nobody plays with new tech, how can it even advance?
otherwise are there some docs/papers on how this has to be implemented so I can start my own?
edit: ahh yeah it’s in the FAQ in “session comparison”
So it really depends on if your threat model can handle others knowing that you're using Matrix. It most likely can.
If you want to run on Tor, fine, just run Tor.
I've been using another chat app that uses tor (briar) to chat with my family and the chatting app has been working flawlessly for us so far.
Tor curcomvents the nonsensical restrictions that isps place on users and makes it very easy to build p2p applications. No need for stuff like nat stun turn. Just exchange public keys and go!
If anything, I find it weird that other p2p chat apps don't use tor given how easy and reliable it makes the chatting UX.
We don't want to turn people off with the use of Tor (since it makes connecting more reliable and is quite fast for chat once connected) so I'd love to learn more about the objection.
They list some more reasons here, mostly just for privacy/anonymity: https://github.com/TryQuiet/quiet/wiki/Quiet-FAQ#why-does-qu...
Like here for example, there are still servers involved running IPFS and Tor.
I think it's fair to call Tor a peer-to-peer network, especially if you don't use the exit nodes, which we do not. Yes, it's a peer-to-peer network with some special roles and generous volunteers who run always-on nodes, often on professional infrastructure. But Tor's design is peer-to-peer and Tor has paid thorough attention to the job of limiting the power of each node to harm the network, spy on users, etc.
But yes, it's an excellent observation, and I totally agree with you that building real-world peer-to-peer networks with today's Internet and the world as it exists right now does require some compromises!
The trick is to make sure those compromises are worth it and don't harm the goals you are trying to achieve. For us we're pretty confident they don't. Right now, Quiet lets you download a client and have a shared community space on the Internet with others that does not depend on any one entity's infrastructure. And no one, including us, has any special kind of technical control over what you do or say there. And you don't have to bring your own server (or have a friend with a server) to benefit from this freedom and power.
These properties seem very significant to me, and that motivates me to keep chipping away on Quiet, despite the fact that things aren't always as pure as we might like them to be :)
Ham radio and audible conversation through the atmosphere are probably the only pure P2P connections.
We've also been prioritizing basic functionality on Android and iOS over many common-sense features like DMs because there is a lot of risk there. All users we talk to need reliable mobile support, so we want to ensure we have that locked down to a sufficient degree before adding a bunch of features (to be a bit melodramatic, we want to make sure we aren't polishing deckchairs on a Titanic!)
But we have a concrete plan for encrypted group messaging with multiple device support and removal. We plan on using this library: https://github.com/local-first-web/auth
It is very bleeding edge but is based on academic work by Martin Kleppmann and built in conjunction with the folks at Ink & Switch, so it's an earnest attempt at a solution. We'd love to use MLS but it's too complex and narrowly focused, I think, to be a good fit at this stage.
It's "ugly" and thus people really don't like it over slack.
But it's probably the best chat system available right now if you lean in to web tech.
All I'm missing is the ability to create google meetings from inside the UI.
And the mobile app is complete crap, but they're making a new one I heard.