While I do like the idea behind a P2P E2EE chat, I believe that unless you're willing to invest heavily into OrbitDB and IPFS, this project will stay niche at best.
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!
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
I appreciate the reply and I understand where you're coming from. Looking at when you released your first few versions of this project, I understand that the options you had at that time probably weren't as plentyful or mature as they might be today.
> 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.
Could I ask, with these p2p/federated projects (and thank you mrusme for helping me to get superhighway84 running! dope personal homepage, big fan of yours) why doesn't anyone use Usenet itself as resilient backup storage?
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.
Thank you kindly, I appreciate it and I'm glad you enjoy the content! Happy to help any time.
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.
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.
Thank you for the detailed description of your idea. Indeed, if you're willing to accept the shortcomings of a dedicated USENET infrastructure, then it is definitely something that could be done. In fact, I did consider NNTP for another project of mine (https://github.com/mrusme/neonmodem), which might eventually swallow up Superhighway84 altogether. If you're interested in actually giving it a try and implement a functional NNTP library for Go I'd be more than happy to make use of it! :-)
> 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.
A quick note on Quiet's capacity limits: the 30-100 number is very conservative and not an intrinsic limit of the approach we're taking.
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.
RE contributing to neonmodem, I was thinking about it! But baseline NNTP, as it sits today, is a fetid pit of spam, and I don't think it would add value. In fact, spam is, I believe, a far bigger problem with these networks than the technical distribution of messages over P2P. I took a sample of a random Usenet group today: [0] - but I really struggled to find one to post an image of here because even a lower-spam group that I found (e.g. alt.politics.uk) was full of profanities in the subject lines of the posts.
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.
> I think far more interesting these days would be projects like Veilid, Hyphanet's Locutus
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.
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
Out of curiousity, what os your plan w.r.t the business?
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?
Great questions and advice! Re: business plans, ideally we'll sell premium subscriptions for features you need a server for, like video calls.
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.
>What about our stack makes you worried about the "enough tech savvy people to fork" piece?
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.
Re: key distribution, we're just changing it now but in a few days the scheme will be:
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.e. that users shouldn't have to depend on someone else's server or run their own just to gather online
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).
> I am already running a self-hosted solution (ex: Zulip/Rocket/Mattermost). What makes this a compelling offering to me?
(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.
You aren’t missing anything. The restriction to community fences ensures that each community will have to host the community. There’s no free lunch. Now, someone in that community can be more generous with compute than others. Using Tor to try to be anonymous isn’t going to work either as Tor has been broken.
Sure thing. Let me know if you need more. Government agencies have been watching for years. Also keep in mind that no one has more admin access to network infrastructure than government agencies do such that the NSA can monitor any computer on the internet.
I think it's helpful to have a more layered perspective here. Privacy tools never provide absolute protection in the real world, because the attacker could always have some capability the user doesn't know about.
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.
> 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
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.
Isn't P2P for group messaging a weakness more than an asset, especially if the messages have any importance (I'm thinking corporate settings for instance). Or am I missing some central piece that still acts as common server ?
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.
p2p does not necessarily imply the limitation you describe.
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.
(Quiet founder here.) The OP's edge case is an interesting question and one we've given a lot of thought to!
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.
I just downloaded it and was surprised at how simple the whole process was. With technobabble like "Tor", "IPFS", "OrbitDB", "P2P", etc I was expecting to have to read through a manual and set up some complex stuff, but no. I just downloaded the app, picked a name for my community, and picked a username for myself. That's faster, easier, and more private than Discord, Slack, etc which require you to enter an email address and phone number.
(Quiet founder here) Yes! Onboarding in a p2p app can actually be easier than onboarding to a centralized app like Slack, and much easier than onboarding to a federated app like Matrix (where users need to have a notion of what a homeserver is to not mess up.)
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!
How are naming conflicts handled? I could imagine community names might need to be unique across the service and usernames unique per community but I wonder if there's something smarter which might allow seeming duplicates which are otherwise differentiated. One example is -- I guess not exactly "smarter" -- Discord with the user#numeric_id pattern.
In Quiet there is no global naming. A community is joined through an invite link (a bundle of onion addresses) so multiple communities can have the same name. Usernames are unique only within communities, and we use certificates signed by the community creator as a single source of truth on names. However, in order to allow joining when the community creator is not online, we will release changes this week that let users join provisionally with any name, even duplicates. We will show an 'unregistered' badge until registered and a 'duplicate' badge if duplicate. We will also show an aggressive warning to everyone if the registrar is malicious and gives multiple public keys the same name.
It seemed important to get unique usernames within a community because users expect that from apps like Slack and Discord.
We'll probably do this soon. Tor simplifies peer discovery and NAT traversal a lot though, so disabling Tor is actually harder unless you have a very reliable STUN/TURN service you plan to support forever.
EDIT: this comment's mostly moot as an argument but I'm keeping it around for discussion. The founder of Quiet replied here[0].
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.
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!
Adding to this as a relay operator, while I can't speak for the Tor Project or other operators, I think this is a perfectly valid use case for Tor and I happily provide ressources for it.
I appreciate you taking the time to reply, and thanks for being involved with Tor on this! If they're fine with it, I trust you're good in terms of resource usage.
We are very aware that Tor has created a public good, very grateful for it, and we will not abuse it.
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.
> it would benefit both technically and ethically from using non-Tor networks
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.
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.
Good point, though in Git's case there's the benefit of:
- Users are at least somewhat technically minded
- The ecosystem built around Git generally has good automated tooling for verifying signed commits (Gitlab and Github in particular surface that information pretty well)
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.
if Quiet doesn't catch on to provide that noise, would it be beneficial to flood Tor with LLM-generated conversatinos? We're really good at "cheaply generate near-infinite quantities of human-looking text" these days...
Presumably the content of the message is irrelevant to Tor. If the humanness of the content matters then the game is over anyway because that means it’s being read by a third party.
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.
On the other hand, if projects like this, as a side effect, increase the number of relays, and normalize using Tor, it's a win for everyone. Quiet should pay for a few servers to be used as relays and exit nodes, and also encourage users to do so, or to donate to that.
(Quiet founder here) We already support Tor financially and will probably also run relays someday!
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.
(Quiet dev here.) Correct. Quiet traffic does not use Tor exit nodes, though we might use them someday, e.g. for fetching preview metadata when you post a link.
A broadly used application that requires tor for everyday use would be beneficial for the general normalization of tor. How would many people using quiet be anything but a step in the direction of general normalization of tor?
You don't get to choose what flows through your exit node.
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.
You don't get to choose what flows through your exit node.
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.
My only assumption that would need citation (that I cannot give, I admit) is that currently the proportion of shady users is much higher on Tor than on the general Internet. From here, it's pure and simple logic: as more users transition to Tor (asymptotically all of them), this proportion can only decrease.
1. there's no clear indication whether the Tor userbase grows. Indeed, I would suspect the constant mobile is a hindrance
2. There's no clear indication in which direction the online CP people grow. They can be more or less over time. I am unaware of any studies because it's obviously extremely hard to measure.
Increased adoption also drives the volunteer amount increase. Every non-shady use of Tor is welcome, as it improves the network reputation, anonymity, and protects the use case it was created for.
The more immediate issue for Tor is the vulnerability to fingerprinting if the use of Tor Browser falls below the comfortable levels.
> 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.
Given that it's still fairly new (just coming out of draft in the coming months), no, it's not, but it is _in_ use, and it can be deployed by server operators and client devs in its draft state.
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.
> [Tor is] 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 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
If you are running an exit node, yes. However, if the general public takes up this advice, connections will time out before the whistleblower has finished uploading the 15GiB .zip to the dead drop.
As far as I know, there is no way to run IPFS over Tor.
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?
Tor can tunnel any protocol, including IPFS. The normal IPFS network and the Tor IPFS network can't really interface without nodes bridging the gap by speaking both protocols. There are a few PoCs out there for adding Tor support to IPFS.
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.
Tor works on top of TCP so it can’t tunnel UDP traffic. Lots of P2P things (like torrents) support both UDP and TCP, some only UDP. If you try to torrent and only have TCP you won’t be able to connect to other peers using UDP.
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.
I can't tell you how they've implemented it, but OpenBazaar has a Onion transport implementation of IPFS that seems to work. It's not as simple as "glue Tor to the IPFS port and hit go", of course.
TCP DHTs may not be efficient, but efficiency isn't one of IPFS's strengths anyway, in my experience.
Private IPFS networks for each Quiet community make this not a problem. I haven't investigated using Tor on the big global IPFS DHT, but we don't have to worry about that.
And before that there was TorChat [1] and another similar program I can't remember. I think both had some UX problems, but more importantly, they are generic chat networks like WhatsApp or Telegram, while this seems to be targeted specifically at Slack users (and the whole PKI architecture they rolled sounds like a nice fit for that).
(Quiet founder here) Prior work like TorChat and Ricochet was actually a huge inspiration for Quiet. We build on their insight that if you use Tor onion services as your addresses in a peer-to-peer network, a lot of things get simpler.
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.
This is what I really like about tor services. The ease in which I was able to host a blog off my heavly-natted phone internet uplink blew my mind about a decade ago. (Granted my excitement was quickly ruined by how fast my newfound pocket server ran out of juice).
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.
(Quiet founder here) Yes! This is very underappreciated! Tor is like the Internet we all dream of having: forever addresses for everyone, with built-in hole punching.
Tor startup and onion address connection times can be slow, but this is improving!
A chat platform with only textual chat and file sharing isn't an alternative to Discord nor Slack. It is barely a slightly better version of IRC. Unfortunately many messaging softwares seem to not understand what feature parity is.
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!)
This would be huge- but also a replacement forJitsi Meet, which just started requiring registration using google, Microsoft or Facebook accounts. So, anonymous E2EE( well, they used insertable streams, Firefox didnt have this fully implement
Yet but was working on it, spurred on by jitsu meet, actually)
Im a web browser accessible OR electron app form for any OS, open source, and totally anonymous, while able to host a good number of people all securely, for free, is not accessible to people anymore.
( there are other jitsi meet instances that likely will not require the same but this badly hurts nontheless, as they were perhaps the main free zoon competition in some ways.)
That's really interesting. Jitsi offers a React Native SDK and we were interested in using it (in e2ee mode) for Quiet. Twilio offers one too (FOSS on client side and Twilio SaaS on the server side) but it would be nicer to use Jitsi. If we only offered it to paying customers it would have the same downsides as using Jitsi though.
One question: speaking for yourself and the use cases you know well, how much latency or call quality would you give up for anonymity? Would you give up video? Would old-school VOIP level lags between speakers be okay?
Doing something like push to talk would be trivial now, over Tor. But an anonymous video call with lots of participants would be really hard. Sometimes I think about something in between... like a voice activated push to talk where everyone's audios are played continuously. But nothing exists like this afaik so it would be costly to explore.
My apologies on my former post, the auto correct on my phone did a number.
For the use cases I know, some quality loss wouldn't be to much of an issue, but at least rudimentary video would be desired. Lag of that sort wouldn't be too bad of an issue considering it'd be to maintain a level of security and privacy that is difficult to match.( Since Signal is still working on not needing to use phone numbers, to add a privacy/ anonymous benefit to it)
I know both Jitsi Meet and Google Duo( now google Meet) have a bit of info out there about the challenges they encountered upon finding methods to implement multiple-person E2EE video chat.
Duo had a cap of about a dozen give or take, callers at first before they could scale up. Jitsu added E2EE as a toggleable option after getting their initial product out- so this might be the sort of thing where it doesn't start out with lots of Participants, at the beginning.
Finally, you mentioned exploring some of these options not over TOR. That might be beneficial for those seeking anonymity, since TOR usage has been used to fingerprint people when no one else on a network was using it. ( VPN's and Bridges are other methods of course to plug that hole, but usually have to come from the user side at cost and some technical familiarity.)
Push to talk is not something I've seen before- I take it the technical load would be less in that format?
We can maybe do usable video calling over Tor if it's okay to have higher than normal latency. I've read about some tests with TCP WebRTC over Tor where it was usable. I should test it sometime.
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.
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?
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
> do you have an individual username for each community, or will your profile eventually be the same across all the communities you're in?
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)
> 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
> 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?
> 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
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.
> 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.
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.
Veilid is a recently announced, general-purpose peer-to-peer Stack. We're excited about it!
We would consider switching away from OrbitDB/IPFS/Libp2p/Tor for a less mature peer-to-peer state syncing stack if it offered the following as first-class features in addition to what we have, had credible longevity, and ran well on desktop and mobile:
1. Deletion
2. Encrypted groups with removal
3. Support for linking multiple devices, and removing devices
4. Support for partial syncing / lazy loading.
It would be really nice to have all of these things out of the box, alongside state syncing and BitTorrent-style file transfer (which we have now.) Veilid is still new so we haven't assessed it yet, but that would be our criteria.
My general perspective on general purpose peer-to-peer stacks (which I understand Veilid to be) is that it will be very difficult to build meaningful general purpose platforms until we have more examples of popular desktop + mobile peer-to-peer products with large numbers of users in the wild that would let us identify all the things a general purpose stack would need to have, and that right now the best thing to do is build single-purpose peer-to-peer apps in whatever way you can (whether it's by building your own non-general stack or cobbling together existing building blocks as we're doing) and struggle to find product market fit!
The way I think about it is: would you have been able to build Heroku before there were a few successful production Ruby on Rails apps with product-market fit? Probably not! So we shouldn't expect to be able to build useful general purpose p2p stacks without clear examples of successful p2p products with product-market fit.
Hmm, it feels like a CRDT + any overlay network (This is probably how you use tor or IPFS p2p) would get you there. Matrix p2p is developing pinecone [1] as an overlay network, which seems very aligned with your needs, though, as you say, it is less mature.
Well, pinecone/yggdrasil/cjdns/tor are only part of the question, as they provide encrypted E2E connectivity. You still have to build on top of it to handle groups and lazy loading. They do solve routing though, so you can just try to send packets to every group member (like Matrix does). For a more efficient implementation, it would be nice to have multicast/unicast integrated in the overlay network at the protocol level. API-wise, it could be made as simple as sharing a private key with a group: multiple peers with the same address would then receive the same packets.
In any case, I feel like working together with Matrix (/new vector) on pinecone would help both of you.
I've been following the P2P Matrix work intermittently but closely. Matrix clients are so much more mature than ours, so having a first-class P2P mode in Matrix would be a solution to this whole problem.
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.
The reason that P2P Matrix (arewep2pyet.com) exists is precisely to provide a 1st class P2P mode to Matrix - it's not just for awesome reliability and network resilience, but for easier onboarding; killing off public-service homeservers like matrix.org; etc. The onboarding and identity piece is covered by MSC4014 (which just got implemented in Dendrite.)
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 :)
This is all great news, and it's really cool to get an update on the state of P2P Matrix from its creators deep in a thread like this. HN is amazing.
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 a Matrix enthusiast, run my own homeserver and I've been playing around with Quiet today.
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. :)
Yes! I've followed the progress of Loki/Oxen/Session since a talk I gave at HOPE 2020 surveying the field of p2p messaging approaches, and since then a mutual friend introduced me to the Session/Lokinet team and we had a great meeting.
The Oxen/Session approach of having a bunch of crypto-incentivized, investor-subsidized always-on servers to do stuff for you is very powerful and makes a lot of things easier. Where it really shines is supporting iOS devices where the OS gives you very tight constraints on how much CPU and time you can use to connect to a peer and sync messages. I true
We decided to start without depending on a cryptocurrency or a cryptocurrency-incentivized network because I don't think we need it. I know some people hate crypto too. I don't but it keeps things cleaner to not depend on it. Also, when it comes to onion routing Tor is a lot more battle-tested and has many more eyes on it, so I'm fairly confident that it's superior to the extent we only need that piece.
There is also some actual worrying ambiguity around what happens with lokinet if their coin price drops but their traffic goes up a lot. (Though the same thing could be said of Tor, swapping out "community support" for "coin price", so we may have to roll our own network in the future anyway or give users more options for connecting directly when they feel it's safe to do so.)
I don't agree that you need feature parity to be an alternative though. If your use-case is only text chat and file sharing, then it is an alternative.
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 key features are chat and VoIP. File sharing is barely meaningful, except that it means not needing to use external image hosts for gifs/memes/pet pics.
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.
If you really wanted a (I am assuming free AND 0 setup) web forum, why not use reddit instead? It is at least an actual forum, that is also web searchable. And like discord, it is free and you don't have to bother with the hosting/setup.
What does discord offer that reddit doesn't? (In terms of being a web forum)
That's a good question - I suspect the answer might be "trendiness".
(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?)
I’m someone who uses Discord but (almost) never uses voice chat. To me it’s a text chat platform. This isn’t true for everyone but I feel like it is for a lot of people
But think about why you're now using Discord instead of IRC or a forum: it's because of the users who were also pulled in for the core VoIP feature and because users would rather use one program than multiple.
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.
The network effect is obviously a big part of it, but it’s also that IRC is extremely barebones and difficult to use even for messages.
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
Not all use-case requires both chat and VoIP though. I basically never use chat in my friends servers because we're on VoIP. Mumble is an alternative in that case. On the other hand I never use VoIP on servers I'm in for open sourced projects or other general hobby servers because it's a bunch of strangers and people asking for support.
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.
I use Slack huddles regularly even though my company also has Zoom and Google Meet, and would be ticked off if my company tried to replace Slack with something that was missing voice.
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!)
They say so in the project description. I think they understand what constitutes a group messaging app. It is, however, something that can be built upon and improve. That's how open source works, you have to start with just the basics. Still, it's a very good step in the right direction.
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!
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.
What you're defining is possible future feature parity, not feature parity.
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.
You're technically correct (the best kind of correct), but in the context of this comment thread the comment I was replying to said:
> 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.
He’s not complaining about it missing the features he wants, he’s complaining about it missing features of the products it’s presenting itself as an alternative to
As a major supporter of free software, I can't believe how many times I encounter this reply. No, not everyone has the resources nor skills to dedicate to a random unknown free software project online.
Criticism is helpful and can inspire others who do have the time and skills to direct or fork the project into something more useful.
Criticism can be helpful indeed; it's the form that triggers this kind of response. Let's try this one more time:
> 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. :)
Agreed, the web stack should definitely help get some contributions. I might take a look too :-)
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.)
We might switch to Tauri someday. Death-by-a-thousand-cuts is a very serious risk for us though, so we're trying to choose the most mature and widely-used tools whenever possible.
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.
Not everyone but thousands here in HN, I'm checking right now how to integrate it in my app and change the messaging platform to Quiet and maybe even the data sync between peers for other collaborative stuff
As much as I hate to say that, they are right. If you want to be a significant competitor to centralized plateforms, you gotta at least do as much at them.
and from where would you start? How should the project be defined if they are yet not an alternative? The "soon to be if people contribute" P2P alternative to slack and discord?
Recently I've tried to organise an IPFS source mirror for a linux distro.
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.
(Quiet founder here) Quiet creates small, closed, private IPFS networks specific to each community, so it avoids a lot of the performance problems that plague the big global IPFS network, and is also a lot more private!
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.
Mh, XMPP is well known, open, far lighter than IPFS... Why the hell I'd want a MONSTER software just to chat knowing that "real security" of such giants is far theoretical since they are so big that their knowability is limited for anyone and attack surface is enormous?
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.
it's not the same: IRC or XMPP are very small piece of sw compared to IPFS alone. While for messaging do essentially the same: why using a many hundred of megabyte app when a 10Mb one can do the same?
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 :)
> 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.
I remember chatting with you at FOSDEM (Snikket dev here). Congratulations on the launch!
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 :)
IPFS is a resource hog. Not sure if it's just the implementation or if it's because of architectural limitations, but it gobbles up CPU and RAM much more than you'd expect it to. I shut down my self-hosted IPFS server because it kept pegging a CPU core doing what seemed like nothing (no new pins, barely any network traffic, just sitting there).
(Quiet founder here) Yes, IPFS is a resource hog when running on the global IPFS network, but Quiet never touches that network, and this improves performance a lot.
I can run Quiet in the background all day on my Pixel 6 and we haven't even started optimizing for battery life yet.
I'd like to point out that you probably cloned https://github.com/ipfs/kubo there, which is only one part of what accounts for the "IPFS codebase". If you want to find out the actual LoC, I'm afraid you will need to dig through https://github.com/ipfs/kubo/blob/master/go.mod and pick everything that's github.com/ipfs/*, github.com/libp2p/* and github.com/ipld/*.
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".
And had bridges across to other systems and POTS! It was amazing. Curse of google though. They replaced it with 4 other non-interacting chat systems, none of which were as good.
Looks really interesting! Huge shame there isn't any native client, but at this point, I wouldn't even know what stack can still produce a native client without being shunned by HN ;)
I mean really - the obvious, most featureful and well known one would be C++ with Qt or something, but thats way too unsafe (says the crowd using Chrome which is mostly C++).
Rust doesnt have any mature GUI frameworks, and Lisp is probably the best choice here (for some reason).
what would be a native client? They need the nodejs server in the client so Electron and React Native are the platforms needed to support their architecture.
A native client would usually, for the most part, be written in a language native to that OS, and usually compiled. The discerning factor is that native apps, or any apps which use (actually) native GUI frameworks (as opposed to gpu rendering their own), integrate much better with the OS
Your selling points are the opposite of Discord and Slack's selling points. Slack login is entirely corporate controlled. Discord just works with one login across communities. These products are not popular in spite of their terrible privacy patterns, they are popular because of characteristics that intrinsically have terrible privacy patterns.
I think they are aware. Let the corporate crapsters do their thing and let us have our thing. To me, a community that relies on discord or slack is a red flag. I would really like something like this to become the default instead. Long live irc!
> Let the corporate crapsters do their thing and let us have our thing.
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.
To me, particularly in the FLOSS sphere, it belies a certain level of amateurism. Particularly when it is the primary method of “support”. As a place of community, it is fine enough. As a place for technical questions? Stop trying to fit a square peg in a round hole and grow the fuck up. Especially since it makes indexing these solutions nigh impossible, even within the Discord app itself, meaning any effort put into fixing them is meaningless.
g0v is full of a lot of heavy hitter hackers that run a lot of their own software (including the full gamut of federated software), but a slack server is maintained because that's how the "normies" commonly interact with g0v as a community. Not everyone in the community is an engineer or technically savvy, and unfortunately a lot of these tools really aren't noob friendly. Yes, even IRC.
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.
For support, ideally something actually indexed like Github/Gitlab. I don’t want to have to use their Discord to sort through hundreds of questions that failed to get answers to finally get to the one solution I need, when on a git site I can simply search the issues and find X solution away from all the chaff, since they’re all labeled as “duplicate of X”.
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.
You can hide it from other users by using a cloak (which some servers enforce on all connections), if that's a concern (but I don't think it's much of a concern). If you want some anonymity from both the server and users you're probably already connecting to the server from Tor (or maybe a VPN if it's blocked). OTOH discord is difficult/impossible to use from Tor Browser due to phone number requirements on suspicious connections and email verification when changing countries, which sucks.
Yes, and on top of that i don't have to use a javascript enabled browser or some proprietary app, instead i can chose between many minimal and foss irc clients.
Nothing about this is IRC. It is undoubtedly sacrificing a lot of things that the vast majority of people look for in multiplayer notepad, for properties that are sought after by privacy wonks. Mind you, IRC barely if at all addressed these “concerns”.
Any client/server based app for a company-controlled replacementt The server manages rights and auth.
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.
Thanks. Offtopic, but this is the second time in a week the person who answered my question gets downvoted (if that's what the reduction in contrast of your post indicates). I'm not sure why that's happening.
who is the target audience for this product? if companies, imagine the discussion they need to have when your communication channel relies on random machines vs single company with SLA/SLOs + bunch of engineers employed
For enthusiasts maybe good, eventually maybe there will be ISP like providers which can guarantee hosting these nodes
That's the cool thing about open source I guess. The target audience starts with the initial developer(s) who want to build it for their own reasons. Then others may find it and use it for their own purposes, even if it's just for education.
I'd say that the target audience is (1) people who have some secrets to share among them, and (2) people who pretend they have such secrets, or just enjoy the feeling of extra privacy.
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?
If all the users in the chat are offline, the chat is gone, right. Because it’s decentralised so there is nowhere to take the messages from? As there is no “cloud”
edit: ahh yeah it’s in the FAQ in “session comparison”
As someone using matrix currently: Is there a reason i'd switch to something like this for my business use or is their really only legit use cases around journalists/activists?
Endpoint discoverability is important. You just need to come up with an hidden onion address and the network takes care or getting you connected to that address. That removes the need for a common server.
Came here to ask this.. Embedding tor is a bit disingenious for adoption because it puts you in the same bucket as a lot of very abusive content. Not worth it IMO and the extreme privacy protection isn't really needed here.
Seems strange to me too, can't think of anything that would need it functionality wise that can't be done in less, let's say, problematic, dependencies.
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.
I'd rather not participate in the network, have the network flow logs on my ISP and it's slow. You can run the app on top of Tor if you need it. Seems to be not just me that can't understand why it's needed and it's definitely turned me off as a potential user.
A lot of people think that by using Tor they are routing traffic for others, but this isn't the case. Is this what you mean?
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.
What if I send some secret key using such a 'secure' app, and invoke some corporated app to sent large encrypted data? Thus the speed and security will both be granted.
(Quiet founder here) We actually don't use any of that server-based IPFS infrastructure at all. Since Quiet is built on closed, private IPFS networks that are specific to each community we don't touch the global IPFS network.
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 :)
(Quiet founder here) The non-trivial thing about DMs is multiple device support, so that when someone sends you an encrypted DM you will receive it on any of your devices.
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.
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.