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!)
The Oxen/Session approach of having a bunch of crypto-incentivized, investor-subsidized always-on servers to do stuff for you is very powerful and makes a lot of things easier. Where it really shines is supporting iOS devices where the OS gives you very tight constraints on how much CPU and time you can use to connect to a peer and sync messages. I true
We decided to start without depending on a cryptocurrency or a cryptocurrency-incentivized network because I don't think we need it. I know some people hate crypto too. I don't but it keeps things cleaner to not depend on it. Also, when it comes to onion routing Tor is a lot more battle-tested and has many more eyes on it, so I'm fairly confident that it's superior to the extent we only need that piece.
There is also some actual worrying ambiguity around what happens with lokinet if their coin price drops but their traffic goes up a lot. (Though the same thing could be said of Tor, swapping out "community support" for "coin price", so we may have to roll our own network in the future anyway or give users more options for connecting directly when they feel it's safe to do so.)
We would consider switching away from OrbitDB/IPFS/Libp2p/Tor for a less mature peer-to-peer state syncing stack if it offered the following as first-class features in addition to what we have, had credible longevity, and ran well on desktop and mobile:
1. Deletion
2. Encrypted groups with removal
3. Support for linking multiple devices, and removing devices
4. Support for partial syncing / lazy loading.
It would be really nice to have all of these things out of the box, alongside state syncing and BitTorrent-style file transfer (which we have now.) Veilid is still new so we haven't assessed it yet, but that would be our criteria.
My general perspective on general purpose peer-to-peer stacks (which I understand Veilid to be) is that it will be very difficult to build meaningful general purpose platforms until we have more examples of popular desktop + mobile peer-to-peer products with large numbers of users in the wild that would let us identify all the things a general purpose stack would need to have, and that right now the best thing to do is build single-purpose peer-to-peer apps in whatever way you can (whether it's by building your own non-general stack or cobbling together existing building blocks as we're doing) and struggle to find product market fit!
The way I think about it is: would you have been able to build Heroku before there were a few successful production Ruby on Rails apps with product-market fit? Probably not! So we shouldn't expect to be able to build useful general purpose p2p stacks without clear examples of successful p2p products with product-market fit.
Well, pinecone/yggdrasil/cjdns/tor are only part of the question, as they provide encrypted E2E connectivity. You still have to build on top of it to handle groups and lazy loading. They do solve routing though, so you can just try to send packets to every group member (like Matrix does). For a more efficient implementation, it would be nice to have multicast/unicast integrated in the overlay network at the protocol level. API-wise, it could be made as simple as sharing a private key with a group: multiple peers with the same address would then receive the same packets.
In any case, I feel like working together with Matrix (/new vector) on pinecone would help both of you.
That said, they have to solve more problems than just the problems solved by Pinecone. (Like onboarding and identity.) And over the past few years my impression has been that the Matrix team is focused on the federated use case, because that's where their users are. It seems hard for them to pay attention to both.
My guess is that P2P Matrix will land as an awesome reliability feature for uninterrupted messaging when a server goes down or when the Internet goes out, but that it will take longer for them to tackle problems specific to P2P that don't graft on easily to federated Matrix.
However, you're totally right that our main focus is on the federated use case, because that's where everyone is today, and its own fair share of Hard Problems (e.g. reliable decentralised E2EE, byzantine-fault-tolerant conversation replication, decentralised ACLs, lazy-loaded conversation state) before we chuck P2P into the mix too.
The P2P Matrix project is currently focusing mainly on MSC4014 (i.e. pseudo-IDs, account portability, multihomed accounts) which benefits both P2P and normal Matrix... although I'm hoping that we'll get back to Pinecone & actual P2P work eventually (especially if someone explicitly funds it).
Meanwhile, it's super cool to see the progress on Quiet and OrbitDB. It's come a long way since Orbit launched at the 2016 Decentralised Web Summit, and I'm glad to see the tech is still progressing. FWIW, We did the first versions of P2P Matrix on top of libp2p (but then switched to Yggdrasil and then Pinecone in order to work with a monolithic stack, for better or worse). Might be interesting to figure out how the projects could interop in future :)
It has nowhere near the features of Matrix at this point, but it is useable and I'm having fun with it, and I really look forward to see progress on both projects. :)
Re: interop, the easiest way to interop would be if Matrix solves all these problems for us before we get anywhere close! Then we can be a P2P Matrix client or just use Matrix :)
But I bet either way it will be possible to make robust transformation layers between different eventually consistent protocols. This is similar to one of the hard problems: interop between multiple versions of a single decentralized application. If we solve that it might generalize if we can bridge the network layers too?
And yes, there is indeed a really long list of hard problems to solve. I really really hope one of us, or one of the other similarly motivated projects, is able to solve them all and deliver the whole package!!!
* I'm glad to see you are thoughtful about many protocols here. Will you be adding i2pd support?
* Could you make explicit for us what parts of this tool are the least decentralized?
* Do you need computational donations to the network? How can I assist?
* Do you intend to provide users complete control over private/public keys within the interface?
* Will you be providing significant command-line access to the tooling?
* How far have you attempted to scale this up?
* Will you be working toward collaborative text environments like Etherpad? Latency seems too high for that, right?
* Do you intend to enable the synchronization of larger sets of files, something like mutable torrents?
Aw thanks. That is what we're going for. One that makes sure others will always be able to give their gifts to humanity.
> I'm glad to see you are thoughtful about many protocols here. Will you be adding i2pd support?
There is no current plan to. I'd be super curious to see how well it works, but we have so many bigger fish to fry! My guess is that adding i2p support on desktop would be straightforward and that on mobile it would be costly. Would desktop-only i2p support be useful to you?
> Could you make explicit for us what parts of this tool are the least decentralized?
Our source control, update server, and CI! It would be awesome to have a p2p github alternative that could ship builds over BitTorrent or IPFS. Someday! :)
Beyond that, there are some pieces of Tor that are less decentralized (Guard nodes, e.g.) but everything else is just client code running over Tor talking to other clients.
> Do you need computational donations to the network?
Right now, the best way to donate to the Quiet network is to run a Tor relay. Beyond participating in Tor, Quiet does not allow you to help any network you're not a member of!
If you have access to a large number of machines, rigorous performance testing with hundreds of nodes could possibly be helpful? In the past we've used Fargate for this, but this is expensive so it would be nice to have something running in an ongoing way. Also, manual and automated testing on many diverse Android devices; that would be helpful!
> How can I assist?
The thing we need most are real communities of people who desperately want to switch away from Slack, Discord, or Signal but don't have a satisfactory solution. Specifically, we want to learn about their use cases and tailor Quiet to their needs as much as possible. Know anyone?
> Do you intend to provide users complete control over private/public keys within the interface?
Yes. Right now user keys are stored on their machines and nowhere else, but you have to just copy a directory to move them or back them up. Soon we'll let people recover accounts from their linked devices (e.g. from your computer if your phone is lost) and we may have some social recovery solution within communities for DMs, though that might not be feasible. We'll also do the crypto wallet thing of encouraging people to write down passphrases, but most users won't do that.
> Will you be providing significant command-line access to the tooling?
The backend is its own Node module, but we don't have a good CLI for it yet and it's not a current priority: https://github.com/TryQuiet/quiet/tree/develop/packages/back...
> How far have you attempted to scale this up?
We've run tests with 200-300 nodes on Amazon Fargate, and our frontend was the bottleneck, not the p2p layer. Libp2p currently handles 800,000 nodes on the Ethereum beacon chain. Phones will need to be given some more limited view of the network for large communities to remain performant, and we will need to add retention limits for messages and images otherwise drive space will be the bottleneck, but there is no reason why we cannot handle very large communities.
> Will you be working toward collaborative text environments like Etherpad Latency seems too high for that, right?
For text documents, latency isn't the issue, but CRDT performance is because every character is a new CRDT transaction. We would love to pursue this if our users ask for it. So far there isn't a strong signal that users need it. Many people I talk to use documents to prepare things for intended eventual publication, while they use messaging for in-progress thoughts, so docs are not as sensitive as messages. It's like, docs are an organization's mouth and messaging is an organization's brain. You care more about the privacy of your brain. But technically this would be a fun challenge and I'm sure we could build something great. There are other CRDTs we could use.
> Do you intend to enable the synchronization of larger sets of files, something like mutable torrents?
This would probably be straightforward. What's your use case?
I can see that. Your roadmap makes sense to me. My [[wife|k0sh3k]] (without having seen your roadmap) picked out many of the same points as reasons she must wait to use it for her library staff. I appreciate how you must triage with the resources you have. Most of what I have to say isn't going to be as important to the non-poweruserbase you are trying to capture (and rightfully so!), so please take what I have to say with a grain of salt. You obviously know what you are doing. Reading through your account, I think you already know what I have to say here.
> Would desktop-only i2p support be useful to you?
Yes, and not just because I think it's important to contribute back to the network as a regular user. It would be especially nice with command-line tooling, and you can pickup UDP support. I've encountered plenty of failures on Tor (and you have too), and there are many I've encountered who I believe are rational in their desire not to be so reliant upon that network. I'd also be happy to use i2p on a mobile device just in case I had somewhat convenient control over when that occurred. If you provide logical accounts (where my decentralized identity can be wielded by multiple cooperating devices), then i2p becomes even better. Retroshare's use of both Tor and i2p have demonstrated the value of diversity here to my eyes as well. I'll add that something like multiplexing over multiple Tor or i2p tunnels could significantly improve throughput performance (a difficult place where you might be able deliver in some cases where no one has).
However, I think your focus on mobile is more important (and I say that with a deep-seated grudge against phones). You serve the poorest on the planet by targeting mobile first. That isn't to say that you don't have any use for desktop users to assist on this network, but I can see why i2p, among many of my suggestions, should take a backseat. `/nod`.
> It would be awesome to have a p2p github alternative that could ship builds over BitTorrent or IPFS
I understand you've been around the block, so please ignore my gibberish. To my eyes, you're also building a serious competitor to [[P2P Matrix|2021.11.17 - HN Log: Arathorn & P2P Matrix]], which is still under development. I'll mention that Radicle may be worth your consideration. The functionality of [[DarkMX]] is worth your time as well (it is closed source, but its creator is one of the few with the right to ask us to trust him [even if I stand in disagreement]). I know some, like [[Ian Clarke]], will claim it is better not to "focus too much on competitors, better to focus on the needs of users," however, given the specialization of this tool, I think there's something to be said for having tasted the alternatives. [[Aether]] may be a direction you could eventually go, but I understand that isn't your immediate target; I don't know if protocol design decisions now might affect the future of such a thing.
> Beyond participating in Tor, Quiet does not allow you to help any network you're not a member of
`/nod`. I wonder if it is feasible for Quiet to have something like the Encrypted Key option in Resilio Sync, enabling one to seed in swarms without knowing the contents. There are some cases where it's useful, though there are tradeoffs.
There may come a time where you've decentralized to the point where it hurts too much, and you'll have to centralize until it works. I wonder if there are cases in which randos must hold at least metadata for others or act as proxies (I understand that Tor solves many problems for you). [[Tox|Toxcore]] is an exemplary tool in part of this space you're solving, and even they haven't solved some of these problems. Seamless multidevice and offline messaging are dealbreakers for many people.
> If you have access to a large number of machines, rigorous performance testing with hundreds of nodes could possibly be helpful?... manual and automated testing on many diverse Android devices; that would be helpful!
I'll be thinking about that then. NixOS with solid orchestration on a beefy machine (I'm not sure if zswap would assist here, but memory seems a serious bottleneck) may be able to push hard. There's probably no way around using a lot of machines unless a much thinner client were feasible. The nice part is that donations might allow you to control the machines remotely while dogfooding.
My family tests this type of software often enough. I know my daughter, [[j3d1h]], desperately hopes for a secure replacement to Discord for her [[friend]] groups. She's sitting on the couch with me right now writing up what she's missing most in your software. Here is what she said:
```
just my opinion, man
-how are profiles going to work? do you have an individual username for each community, or will your profile eventually be the same across all the communities you're in?
-profiles you can customize to servers *can be* useful, so long as you can still trace them back to the user's actual profile. otherwise that might enable masquerading as other users
-users able to mark as invisible (appearing offline without actually being so)? good to have in many situations imo, obscuring information from people who may be a danger to you
-how is name collision handled? in a large community, you're bound to have a few people who want the same name (and i get it, your screen name can be very personal)
-discord's old solution, a username and 4 digit id (e.g. felix#1234), seemed convenient and effective to me, but there must be tons of solutions; i like having a way to easily distinguish two users with the same screen name
-personally blocking users you are uncomfortable interacting with, kicking users from communities vs. banning repeat offenders in a more permanent way, temporarily muting a spamming user?
-kicking vs. banning can be an important distinction; i'd rather kick you if you're just inactive all the time, you're free to rejoin whenever you like
-i like keeping it very, very clear what does (or does not) happen when you block, kick, ban, etc; a user shouldn't have to "test" features like these
-important to keep in mind that you rarely (or never) want a user to completely disappear; i always want to leave the option to get back in touch, unban, unmute, etc.
-a friends system is useful for this; maybe i don't want anyone i haven't marked as a friend to DM me
-selectively muting different portions of the app (e.g. i *only* want to be notified of a DM or @ mention, or *only* notifications from *this* community, or no notifications from this channel except @ mentions)
-what if i want to be notified whenever this phrase pops up in a community? might be a question of how easily you can build your own scripts *on top of* Quiet (which i would quite like to do)
-are voice and/or video planned, both in communities as well as dms?
-muting + deafening + turning off camera, nothing in a voice/video chat should be mandatory (owners shouldn't be able to *un*mute someone, but owners muting others can be useful)
-maybe i want to mute that user, but allow everyone else to hear them? turn this one up and that one down on my end?
-audio controls that make sense. if there's a layer of noise cancellation, leave the option to turn it off in case it messes with your audio, etc.
-taking microphone input as it is works just fine, though i can see some users disliking that (mostly people who don't know how/can't modify their settings *outside* of Quiet)
-i've seen many communities in other applications where multiple "owners" existed, as it can make a more safe/welcoming community
-if one owner in any way becomes untrustworthy, having someone with equal permissions in place to get rid of them and undo damage can help; whether they can remove each other or not seems like an important decision
-question about the threat model; members are not capable of sending messages that appear to be from another member, which implies that owners *are* capable of this? that could become a serious issue if true
-user discovery outside of communities, preferably just typing in a username they send you elsewhere?
-will it be possible to delete an entire community? can an owner do this in situations where members don't agree?
-searching channels (and more advanced searches; sent by this user, with an image attached, in this channel; hopefully accessible to users even if they can't do regex on the fly, lol)
-i've found it frustrating not to be able to search every community i'm in at once for something i said; is that feasible?
-any distinction between a community and a DM with 3+ users in it?
-i don't personally see the point, but some apps have this
nitpicky, visual polish, further off details
-dark mode, and in my opinion, ideally a way to customize everything more thoroughly
-if thorough customization, maybe a way to save/export those settings to share?
-maybe the ability to see separate messages sent in a row - is that a message in 3 lines, or 3 messages? just hovering and seeing one line highlighted (and the timestamp for just that line)?
-embedding video and audio files in a convenient manner?
-replying to messages, pinning them to channels (so they can be easily found again) seem very useful
-channel organization and categories; i don't always want the art channels open, i want #announcements at the top, etc.
-messages marked as read/unread can be useful, something to carefully think about
-sometimes i like knowing that someone has read my message; sometimes i like the safety that comes with people *not* being able to know. if i had to pick, it'd be the latter, users can always prove they have read something by responding to it
-client side unread; i'd like to pick up from the last message i read in this channel
-having channels visually marked that there are unread messages is nice
-keyboard navigation beyond pressing tab is super useful; a screen you can reach to describe these shortcuts is equally so
I hope you'll consider adding more control over the keys within the application itself. Ideally, I should be able to generate my own private key from scratch, paste it in, and recover at least a bare identity (this can be bootstrapped further). I should be able to hand someone just a public key for any of the functions we may need; these keys should be easy to copy and paste into and out of the application. Key control pedagogy is not fun, but it's ultimately required for us to own the means of production; I think you've a difficult usability fence to straddle here, and perhaps a ladder to construct.
> Soon we'll let people recover accounts from their linked devices (e.g. from your computer if your phone is lost) and we may have some social recovery solution within communities for DMs, though that might not be feasible.
What feasibility concerns do you have?
> Phones will need to be given some more limited view of the network for large communities to remain performant, and we will need to add retention limits for messages and images otherwise drive space will be the bottleneck, but there is no reason why we cannot handle very large communities.
Lawd, I'm a preachy sumbitch here. I have yet to find a tool that I think does this really well. It's probably going to be crucial to have not only sane default but strong controls available to users. I am pretty worried you won't escape some elements of federation or at least asking users to rely upon friends or additional devices. Can kids across the planet safely pirate arbitrary files on their phones together? That's the bar, homie. You know whom we serve, and I think you're doing it. I [[hope]] we don't fail.
Do not make the mistake that [[Aether]] did on retention, please. Users must have the opportunity to pin/seed with complete persistence. Any tool (e.g. [[Session|2021.09.25 - Computer Musings: Session Fucked]]) that has forced me to lose my identity or my messages is not a tool I'm going to recommend to anyone again. I understand you may wish to minimize the prices the average person must pay to manage their data, but at some level, there is so substitute for having the user be responsible for it. Joining a room without having to traverse and download an entire graph of content will be important.
Low-end phone performance (not the mobile devices you and I can afford) is such a hard and important problem that I wouldn't be surprised to find that what you're making at the moment is ultimately a prototype. I obviously [[hope]] I'm wildly wrong about that.
> We would love to pursue this if our users ask for it. So far there isn't a strong signal that users need it.
Then please ignore my desire. Your task is already absurdly difficult as it is.
> It's like, docs are an organization's mouth and messaging is an organization's brain. You care more about the privacy of your brain. But technically this would be a fun challenge and I'm sure we could build something great.
It's so interestingly phrased, I feel uniquely qualified to speak on this matter. I probably hold a contrarian position. This is obviously an imperfect way to do it, but I'll leave the tool up for a while; you'll find the link in this room (channel is your handle): ukkmcdhhymxki3plly2w7mkweafijihwhldwnmt6yzwan6rmtuin7zid.
> But technically this would be a fun challenge and I'm sure we could build something great. There are other CRDTs we could use.
Speaking of a narrow challenge, E2EE P2P Tiddlywiki isn't that far off. You might consider hitting [[Sir Jeremy Ruston|2023.08.08 - TW-Community: Hello]] up (TW5-Bob is also dope; and Jed would understand what you're doing well, imho).
> This would probably be straightforward. What's your use case?
I provide access to my constantly updating site (almost exclusively consisting of a single ~60MB html file growing at ~8MB of pure text a year on average) over multiple networks, and few are designed for such a thing (you're already got a foundation for something better than Zeronet and Beaker [both venerable projects, obviously]). I [[share]] mutable directories with many folk, some of whom I cannot [[trust]] (I often have to use Whonix). I need a turnkey multi-platform open-source replacement to Resilio Sync that people are comfortable using. I understand you will be limited by IPFS here as well; I can share 6TB of an evolving curated library using just a couple gigs of RAM on Resilio Sync (with selective syncing on mobile), and I can speedily and efficiently share my `/home/h0p3` (millions of files) across my devices with it as well. I hope to be able to recover identities, contents and all, seeded on these networks. Writing a Discord-killer is already a [[monster]] of a task (bless you), but mutable torrents with a solid chat-based community is where you can walk on water where no one else has.
We're starting with names specific to each community, since that is simplest/cleanest and best for privacy.
> profiles you can customize to servers can be useful, so long as you can still trace them back to the user's actual profile. otherwise that might enable masquerading as other users
There are some decentralization-friendly ways you could link your profile to other profiles, like a Discord or HN account. tlsnotary.org is one example. Would that be good for preventing masquerading?
> users able to mark as invisible (appearing offline without actually being so)? good to have in many situations imo, obscuring information from people who may be a danger to you
we do plan to do this, but it's some complexity to really hide it from a tech-savvy malicious user, so the first version of invisibility will be weak and we'll tell users this. Here's the open issue and there are links to proposed designs in there if you'd like to give feedback! https://github.com/TryQuiet/quiet/issues/1504
> how is name collision handled? in a large community, you're bound to have a few people who want the same name (and i get it, your screen name can be very personal) discord's old solution, a username and 4 digit id (e.g. felix#1234), seemed convenient and effective to me, but there must be tons of solutions; i like having a way to easily distinguish two users with the same screen name
we're not allowing name collisions for registered users. in the coming release there will also be unregistered users who will have a badge until they register with the community owner. if the community owner lets registered users' names collide we treat that as an impersonation attack and warn everyone. since names aren't global you'll usually be able to get the name you want!
> personally blocking users you are uncomfortable interacting with, kicking users from communities vs. banning repeat offenders in a more permanent way, temporarily muting a spamming user? kicking vs. banning can be an important distinction; i'd rather kick you if you're just inactive all the time, you're free to rejoin whenever you like
we don't have user removal yet but obviously that's a big priority for us.
since we don't have usernames, to ban somebody you would kick them and reset the invite link. blocking and muting and silencing people will all be very straightforward. as will roles and other kinds of moderation, and external identity linking would be helpful for this too. you'd be able to make someone link another profile and approve who you are letting in.
> i like keeping it very, very clear what does (or does not) happen when you block, kick, ban, etc; a user shouldn't have to "test" features like these
this is a great note, thank you!
> important to keep in mind that you rarely (or never) want a user to completely disappear; i always want to leave the option to get back in touch, unban, unmute, etc.
hmmmm. this is an interesting and cool idea I have not run into before. yeah, unban and unmute are possible.
> a friends system is useful for this; maybe i don't want anyone i haven't marked as a friend to DM me
Our first plan is to not allow DMs at all outside a community, but there are some ways we could do this.
> selectively muting different portions of the app (e.g. i only want to be notified of a DM or @ mention, or only notifications from this community, or no notifications from this channel except @ mentions)
this is planned, and thanks for the details! Here's the issue for channel notifications: https://github.com/TryQuiet/quiet/issues/623
> what if i want to be notified whenever this phrase pops up in a community? might be a question of how easily you can build your own scripts on top of Quiet (which i would quite like to do)
i'd love to enable this someday but we have no immediate plans to. but it is one exciting thing about a fully user-controlled app: you can give users a lot of flexibility. Imagine a team chat that was as flexible as Wordpress!
> are voice and/or video planned, both in communities as well as dms?
yes, but I'm not sure if we'll do unlimited group calls for free, since we'll need servers for this piece so it's a natural place for us to charge money (we'll need to). And I don't really have clear plans for how voice or video will work yet, since it's far off.
> i've seen many communities in other applications where multiple "owners" existed, as it can make a more safe/welcoming community. if one owner in any way becomes untrustworthy, having someone with equal permissions in place to get rid of them and undo damage can help; whether they can remove each other or not seems like an important decision
yes, we'll allow multiple owners at some point, though the naming role will belong to one user. https://github.com/TryQuiet/quiet/issues/1758
> question about the threat model; members are not capable of sending messages that appear to be from another member, which implies that owners are capable of this? that could become a serious issue if true
this is an issue right now yeah. what we can and will do very soon is show an aggressive warning almost immediately in most circumstances if this happens. see: https://github.com/TryQuiet/quiet/issues/119. but there are edge cases where spoofing could happen that are hard to reason about or convey, so it's unlikely we'll fully address this weakness soon.
> user discovery outside of communities, preferably just typing in a username they send you elsewhere?
Global naming features like this exist in tension with decentralization, unless you make people pay for usernames, which isn't a great experience.
> will it be possible to delete an entire community? can an owner do this in situations where members don't agree?
Yes. A member could block deletion by not going online or by modifying their Quiet app, but deletion is important enough for activists that we want to make it easy. Maybe this is a setting on the community level or user level.
> searching channels (and more advanced searches; sent by this user, with an image attached, in this channel; hopefully accessible to users even if they can't do regex on the fly, lol)
we'll definitely have search but don't yet!
> i've found it frustrating not to be able to search every community i'm in at once for something i said; is that feasible?
yes! it's all on your computer so totally feasible and this is a helpful note! i feel this way about email all the time when using gmail so I get it.
> any distinction between a community and a DM with 3+ users in it?
DMs will exist within a community; a community is at the level of a Discord server, e.g. We're not planning to do the Slack thing of giving ad hoc group chats their own special status, but 1:1 DMs will be special probably.
> dark mode, and in my opinion, ideally a way to customize everything more thoroughly. if thorough customization, maybe a way to save/export those settings to share?
We already have designs for dark mode: https://github.com/TryQuiet/quiet/issues/1502. what app or site does customization great? what approach can we follow, if any?
> maybe the ability to see separate messages sent in a row - is that a message in 3 lines, or 3 messages? just hovering and seeing one line highlighted (and the timestamp for just that line)?
these two things drive me crazy too! See: https://github.com/TryQuiet/quiet/issues/505 & https://github.com/TryQuiet/quiet/issues/1403
> embedding video and audio files in a convenient manner? replying to messages, pinning them to channels (so they can be easily found again) seem very useful
we'll definitely do this!
> channel organization and categories; i don't always want the art channels open, i want #announcements at the top, etc.
Cool, I'll make an issue for this!
> messages marked as read/unread can be useful, something to carefully think about. client side unread; i'd like to pick up from the last message i read in this channel
we have a floating "unread" notification but there's more on this to do!
> sometimes i like knowing that someone has read my message; sometimes i like the safety that comes with people not being able to know. if i had to pick, it'd be the latter, users can always prove they have read something by responding to it
We can do either but now we don't show who has read your messages, with the same caveats as above about strict invisibility of your online status being tricky.
> keyboard navigation beyond pressing tab is super useful; a screen you can reach to describe these shortcuts is equally so
Yeah! Ctrl-K works right now for jumping to channels but we don't make it discoverable enough.
Im a web browser accessible OR electron app form for any OS, open source, and totally anonymous, while able to host a good number of people all securely, for free, is not accessible to people anymore.
( there are other jitsi meet instances that likely will not require the same but this badly hurts nontheless, as they were perhaps the main free zoon competition in some ways.)
https://news.ycombinator.com/item?id=37316959
https://news.ycombinator.com/item?id=37381508
You'll be filling that gap, and it is a badly needed one from an anonymity /E2EE functionality perspective.
One question: speaking for yourself and the use cases you know well, how much latency or call quality would you give up for anonymity? Would you give up video? Would old-school VOIP level lags between speakers be okay?
Doing something like push to talk would be trivial now, over Tor. But an anonymous video call with lots of participants would be really hard. Sometimes I think about something in between... like a voice activated push to talk where everyone's audios are played continuously. But nothing exists like this afaik so it would be costly to explore.
For the use cases I know, some quality loss wouldn't be to much of an issue, but at least rudimentary video would be desired. Lag of that sort wouldn't be too bad of an issue considering it'd be to maintain a level of security and privacy that is difficult to match.( Since Signal is still working on not needing to use phone numbers, to add a privacy/ anonymous benefit to it)
I know both Jitsi Meet and Google Duo( now google Meet) have a bit of info out there about the challenges they encountered upon finding methods to implement multiple-person E2EE video chat.
Duo had a cap of about a dozen give or take, callers at first before they could scale up. Jitsu added E2EE as a toggleable option after getting their initial product out- so this might be the sort of thing where it doesn't start out with lots of Participants, at the beginning.
Finally, you mentioned exploring some of these options not over TOR. That might be beneficial for those seeking anonymity, since TOR usage has been used to fingerprint people when no one else on a network was using it. ( VPN's and Bridges are other methods of course to plug that hole, but usually have to come from the user side at cost and some technical familiarity.)
Push to talk is not something I've seen before- I take it the technical load would be less in that format?
Push to talk was a thing in old-school mobile telephony. It's basically audio messages but they play as soon as you receive them (or stream) so it feels more like a conversation.
LibreOffice is still an alternative of Microsoft Office without having all the features. Firefox is an alternative of Chrome without WebHID or Web Bluetooth.
Discord's initial pull was from gamers who were using teamspeak/ventrilo/mumble + twitch chat and maybe IRC.
If it doesn't do VoIP then it's not a viable alternative to Discord.
It'd be like if LibreOffice couldn't save new files or if Firefox couldn't render images or video.
I didn't stop using Mumble or IRC because they couldn't, combined, meet my needs. I even prefer them to Discord on a principle basis.
But everyone I wanted to communicate with moved to Discord because it was easier -- as it had both core features which are necessary for gamers.
That's the real reason why you use Discord. Peer pressure.
Discord is in no way a replacement for a forum
I’m quite a techy person and I even wrote my own frontend to Discord a while ago, but I’ve struggled with things like bouncers and authentication to the point where it’s just easier to set up a bridge to Discord and use that when I need to use IRC, and then I miss features like editing and profile pictures (there are proposals to add these things to IRCv3 but they aren’t widely supported)
IRCCloud seems to have a good solution to some of this but is paid
It is, however, a potential alternative to one common use case for Discord, namely: "What we really wanted was a web forum, but this is easier."
This describes all 15 of the Discord servers I'm currently on.
What does discord offer that reddit doesn't? (In terms of being a web forum)
(My only experience of Reddit is from Boogle searches landing there [an immediate point in its favour over Discord] and it appears to be pretty heavyweight, loads down the browser even more than Discord, and has ads everywhere - maybe the experience is better if you actually create an account and log in?)
Most companies use multiple products even if they could use less.
As an example, most companies using Zoom also use Slack. So they don’t use all the slack features although they could. Maybe because they think, for whatever reason, Zoom is better at conf call and Slack is better as chat application.
The same is true with Teams, that basically any company owning office licences get for free and still prefer using something else (because it’s garbage).
So if you can make a chat app that can make Slack look garbage as a chat app, you don’t need feature parity. Maybe adding an integration to external conf call services like Jitsi or Zoom can be enough for your potential customers, especially if they already pay for those.
Slack's huddles are about eliminating the friction for hopping on a voice call. There's no waiting time for Zoom to start, no camera check, no "join with computer audio". You can go from a synchronous text-based conversation to a voice call in two seconds flat, as soon as it becomes obvious that's what is needed. That is the value proposition of Slack huddles, and external tools can't replace that.
I think both this point and OP's point can be true, depending on what the value is that people get from switching from Slack to a secure alternative. (And yes I've also been in teams that usually used Zoom or Meet but where the convenience of quick 1:1 calls in Slack was really nice!)
If a team is sufficiently desperate (as some we've talked to are) for something with end-to-end encryption but specific advanced moderation features that Signal lacks, then using Zoom, Meet, Signal, or some other video calling solution is fine. Sure it will be annoying, but there's a clear benefit the organization gets in return.
And yes, most teams do not get enough value from e2ee (or don't yet believe that they do) that giving up on the frictionlessness of a Slack huddle is worth it for them.
If we find product-market fit with an enthusastic niche of teams that need security, we'll be able to grow from there and address their needs for video calls too. If we can't find some users who are passionate about the particular advantages of what we're offering and willing to trade some features and convenience for those advantages, we're toast anyway :) (But we think we've found some!)
I wish my company believed this.
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!
https://en.wikipedia.org/wiki/Substitute_good#Imperfect_subs...
stares at MS Teams
vomits
1. Can the protocol support it (well)
2. Is the tech mature enough / is there enough contributors to ensure the client adds support
For a new tech only the first bullet point is relevant - from a brief scan it seems like a hopeful but emphatic yes.
I guess there's a third soft question which is, does the project have the branding, polish, marketing clout to gain traction: much harder to gauge but looks polished at least.
A project does not have feature parity until the features are actually built—promises that the features are possible and if you really wanted it you could build it yourself are nice in their own way, but they're not features.
> many messaging softwares seem to not understand what feature parity is.
That implies either no intent to implement feature parity, or having had enough time & resources to do so without bothering to. Neither of those things are the case here - hence my breakdown.
I've edited my comment to better address your particular point though, thanks.
So the dev(s) are indeed claiming it's an alternative to both Slack and Discord.
Criticism is helpful and can inspire others who do have the time and skills to direct or fork the project into something more useful.
> Very impressive project! It's neat that you can get this far without relying on any central servers at all. Personally though, I'm missing a couple more features – this only has textual chat and file sharing, while Discord or Slack have a lot more niche features. Achieving feature parity is a prerequisite for getting any user base nowadays, so I hope it is something team would account for before the 1.0 launch :-)
I agree with the objection that not everybody can just contribute patches for major features to an open source project, and I think it's fair to say that the comparison to Slack and Discord is not 1:1 without voice and video calls (which we do plan to offer someday, FWIW) and to feel disappointed by that. Though I think when an open source alternative emerges it is usually understood that it could take a while to get to feature parity, and we try to be very clear about what Quiet already does and doesn't do yet on our homepage.
That said, Quiet is written in TypeScript and built on a web stack almost every engineer is somewhat familiar with, so it's really easy to get hacking on, and we'd love the help. :)
Here are the instructions to build Quiet desktop: https://github.com/TryQuiet/quiet/blob/develop/packages/desk...
And here are some good first issues! https://github.com/orgs/TryQuiet/projects/3/views/1?filterQu...
Tangential but have you considered something like https://tauri.app/ instead of Electron for the app? (One of my major concerns with Electron apps is that every app ships and runs its own copy of Chromium – Tauri mitigates that by using system web engine instead.)
As noted on our website, we still have a lot of work to do on security (including some open issues you could probably tackle! and thanks for expressing interest!!) so it will be a wonderful day when Electron's lag in staying up to date with Chrome security fixes is our most pressing security issue!
In the meantime, if Signal chooses Electron that is a good indicator that, all things considered, it is a good choice for us. They have a lot more resources than us, are much farther along than we are, and they take security seriously.
One immediate issue with Tauri, just to give an example, is that it would require us to worry about Safari quirks on Mac.
I've also heard from projects in our space that the handling of platform-specific functionality outside the browser window is not as mature in Tauri as it is in Electron. This is totally understandable and Tauri is a great project with great goals, but the possibility of running into some deal-breaker Windows-specific issue, say, is scary.