@Natanox @freundTech @delroth yeah, we're against it. it's such a strange way to implement things... it probably felt natural because they treated the encryption as a bolt-on feature that happens in addition to the cleartext protocol, not instead of it, but there are very good security and architecture reasons not to do that.

@ireneista @Natanox@chaos.social @freundTech@chaos.social @delroth Are there any credible ways to prevent this in a general-purpose protocol like Matrix? Because I always see people bringing up Signal's sealed sender in response but as far as I can tell it does nothing of the sort.

@joepie91 @Natanox @freundTech @delroth the fix is that privacy and security need to be things that are considered from the earliest steps of product development, in the initial requirements, not towards the end of the process.

@ireneista @Natanox@chaos.social @freundTech@chaos.social @delroth Okay, but say that they do. How do you address metadata around who talks to whom, on a technical level?

Because from what I've seen, there just seem to be no known ways to do this, that don't involve severe usability tradeoffs that would make something unusable as a general-purpose messenger.

@joepie91 @Natanox @freundTech @delroth you really need an onion routing protocol to fully have public trust, and it needs to go further than current ones do on preventing timing attacks by global passive adversaries

@ireneista @Natanox@chaos.social @freundTech@chaos.social @delroth Okay, but this to me sounds like it implies *P2P* messaging specifically - because if you are going through a server, onion routing or not, there is still conversational metadata available to that server.

And so that immediately poses a significant tradeoff, because that leaves a large gap in functionality like "offline messages".

@joepie91 @Natanox @freundTech @delroth yes, we think that's likely necessary, but another option would be that routing happens via multiple servers so there's no single one in control

@ireneista @Natanox@chaos.social @freundTech@chaos.social This notably also introduces all of the other complexities of P2P design, in particular how difficult it is to build something that remains interoperable and possible to adapt over time, and isn't constantly at risk of feature-freezing because of its P2P nature. Because if it feature-freezes, it will never be used for anything except highly specialized cases.

I'm not saying that work is not worth doing, but it's several orders of magnitude more complex and unexplored than "make your protocol not leak metadata" would imply, and that is likely also the answer as to why people aren't doing it - we barely have infrastructure to fund a run-of-the-mill protocol project on proven technology as it is.

So this really shouldn't be a conversation about metadata at all, in my opinion, it should be a conversation about sustainable structures for community infrastructure. That's the dependency that will likely need to be resolved before this can actually be pulled off successfully.

And that, ironically, requires a good-enough platform to communicate on. I would say that Matrix doesn't really meet the "good enough" criterium, but that "metadata-preserving" is an expectation that lies too far in the other direction.

@joepie91 @Natanox @freundTech absolutely. we have an architecture sketched out that we believe achieves all this without being a monolith, but it's not written up well enough to make public at this time.

@joepie91 @Natanox @freundTech our intent is that we will publish it before we implement it, so that it can be meaningfully changed in response to public feedback, we're just not there yet.