> What are the benefits of decentralized servers over p2p?
* A server-based system gives you a well-defined secure place to keep an always-on copy of your data, with whatever physical/geographic/network security model you prefer... rather than smearing it across a bunch of handsets or laptops which could get lost/stolen/run-out-of-storage etc.
* Thin-client protocols like Matrix or XMPP are going to typically use way less battery and bandwidth than maintaining a full p2p mesh on a mobile device, which is generally desirable. The way to fix that in p2p is to introduce master nodes of some flavour... at which point you're back in a hybrid p2p/federated architecture again.
* A thin-client-first approach also means that you can easily support different clients (and bots/bridges etc) rather than the client being tightly coupled to a complicated p2p protocol.
To repeat: i'm advocating a hybrid p2p/decentralised approach - not religiously pure decentralisation, nor religiously pure p2p either.
> "Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.
My point was that in the medium/long term we have a clear route to avoid having to expose metadata on servers.
> One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.
You're missing the point. There's nothing insecure about the clients. The whole idea of the PDF is to spell out that you could swap out a federated server for a local p2p-based server (perhaps even running in the client) whilst reusing all the same clients... which now magically become p2p (if desired). This agility is very desirable indeed, given the huge amount of effort which has now gone into writing good Matrix clients like Riot, nheko, Quaternion etc.