> If “contact discovery” isn’t part of the core offering, it certainly makes a great attempt to look like it is.
You are looking at only a single implementation here. The point is that this is a set of federated protocols that has been specifically designed to provide freedom of implementation in this regard.
> But if we can’t agree that the flow recommended on the website is the one that the vast majority of users are going to follow, there’s not much room for a productive discussion.
I never claimed otherwise? We seem to be talking past each other.
You say you followed the top recommendation provided to you and that the end result was essentially equivalent to Signal. Since you appear to approve of how Signal handles things, that hardly seems like a complaint to me?
The key difference, of course, is that for Signal that's the only option. If the central authority changes it tomorrow, then tough. Matrix, on the other hand, provides you the freedom to select (or build, or patch, or whatever) a client that meets your needs. It's providing a superset of what Signal is offering.
Except this isn’t the same as how Signal handles things. Signal uses SGX specifically so that they can store metadata without exposing it to the server. Matrix’s contact discovery spec doesn’t.
My initial question, earlier up the chain, was in regards to this dilemma: Signal didn’t upload contact metadata to their servers for years, until they implemented SGX to allow them to do so securely. By contrast, every other messaging platform (Matrix included) just wrote up a spec for contact metadata storage that doesn’t address protections from the server operator.
We’ve got back and forth about the upsides of federation and open source clients and such, but as I’ve tried to point out, none of that is relevant to the actual question I asked, or the upstream point in the thread: that Signal’s spec didn’t include contact uploads at all until there was a way they could store them securely, and other message platforms just skipped straight to storing them.
In practice I have no way of preventing Signal from turning off SGX any time they feel like it because they aren't open and federated. They could push a software update and I'd be none the wiser until a security researcher noticed and pointed it out!
I guess it would be nice if Matrix integrated some sort of remote attestation support into the identity server protocol. Maybe they should have done so from the start, maybe not. At this point I don't see their offering as being less secure than Signal's though, just slightly different.
It's also worth noting that SGX (and AMD's competitive offering) has been broken an embarrassing number of times at this point. From my perspective, secure storage by the server is more or less orthogonal to any given spec or implementation. You either provide data to a server as cleartext or ciphertext. The server does with it what it will - you as the user have effectively no control over that.
You are looking at only a single implementation here. The point is that this is a set of federated protocols that has been specifically designed to provide freedom of implementation in this regard.
> But if we can’t agree that the flow recommended on the website is the one that the vast majority of users are going to follow, there’s not much room for a productive discussion.
I never claimed otherwise? We seem to be talking past each other.
You say you followed the top recommendation provided to you and that the end result was essentially equivalent to Signal. Since you appear to approve of how Signal handles things, that hardly seems like a complaint to me?
The key difference, of course, is that for Signal that's the only option. If the central authority changes it tomorrow, then tough. Matrix, on the other hand, provides you the freedom to select (or build, or patch, or whatever) a client that meets your needs. It's providing a superset of what Signal is offering.