| (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. |