(Quiet founder here)
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
1. http://www.paulgraham.com/schlep.html
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
1. http://www.paulgraham.com/schlep.html