[mashedvikings]

You mean, Matrix does not pose arbitrary limitations to clients that want to use end-to-end encryption. Clients that do not yet feature it by default, and that give huge warnings when you try to enable it. Clients that have problems with complex navigation when trying to verify fingerprints. Matrix is not the future, because at some point you're going to need to defeat metadata, and decentralized platforms can't do that. The future is in apps like Ricochet and Briar.

[Arathorn]

To be fair; Matrix's crypto is fairly solid. The key management however is a mess, and we have run late on fixing it - but we're working on it currently. The metadata concern is bogus however: we designed Matrix to evolve into a hybrid p2p/decentralised architecture in future without changing a line of clientside code, so folks who want to store their metadata on their client rather than their server can do so - https://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%... has some notes on that. In practice, we think neither pure federation (like XMPP) or pure p2p (like Riocochet) or pure centralisation (like Signal) is desirable - you want to have a hybrid of decentralisation & p2p so you can get the best of both worlds.

[mashedvikings]

What are the benefits of decentralized servers over p2p?

"Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.

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.

I hope you fix things before it's too late and focus on Pond or other Tor hidden service based communication.

[Arathorn]

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