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