> requires stable addresses -- meaning VPNs for everyone
The true requirement is for a stable identity, not a stable address. You just mentioned Syncthing, which is an example of this: every Syncthing node has a stable identity (which is its public key), but not necessarily a stable address. All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node.
> requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage" [...] People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server
You stated the solution yourself: to access the data when the phone is offline, mirror it to a node which is online. Just because these particular protocols require you to set up your own always-on node doesn't mean it's a hard requirement; some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users.
> All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node.
That's true; but I think bittorrent DHT is the only decentralized one that seems have succeeded (I remember quite a few unsuccessful attempts two decades ago), and its success is probably related to its use case - it is of everyone's interest to have hashes well-mapped in case you'd need them.
> Some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users.
And for various reasons, they are all gone, whereas e.g. rfc822 email - which is properly decentralized/federated but does require a stable online node, is still going strong nearly 40 years later, despite somewhat successful attempts to re-centralize it by the likes of google.
I think it's inherent - many people now only have a phone, but no one wants a service that becomes unavailable when you lose your phone or step in a faraday cage -- there even used to be on-phone voicemails back in the dumb phone days -- as peer to peer as dumb phones can get -- and they were not popular for the same reasons.
And if it is indeed inherent, it would be better to take it into account when designing the next stage.
The true requirement is for a stable identity, not a stable address. You just mentioned Syncthing, which is an example of this: every Syncthing node has a stable identity (which is its public key), but not necessarily a stable address. All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node.
> requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage" [...] People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server
You stated the solution yourself: to access the data when the phone is offline, mirror it to a node which is online. Just because these particular protocols require you to set up your own always-on node doesn't mean it's a hard requirement; some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users.