This argument doesn't make sense, Signal is fundamentally not an anonymity tool. It's a privacy tool.
They intentionally store very little data about their users but their "mailbox" model explicitly means that the server (or an attacker) can figure out who is talking to whom. And that's fine! Signal isn't trying to be an anonymity network, so while stuff like sealed sender are nice features it's important to remember that anonymity breaks are explicitly not part of the Signal threat model.
"Don't stand out" only makes sense as advice for anonymity tools to avoid bifurcating the anonymity set -- it doesn't make much sense when you're taking about a service which links your account to your phone number and thus every server request is explicitly identifying you.
One of the goals of Signal is that they do not know who is talking to whom. Sealed sender and all that. This can possibly break down in certain scenarios with some server-side correlation. But they certainly do have a design goal that the social graph is entirely private.
I am aware of sealed sender, I even mentioned it in my comment. ;)
My point is that by construction they are not an anonymity tool, no centralised server can be. They can add features to make it less easy to track users but that's not the same as providing anonymity, and it's important to not confuse the two.
To give an example: my email provider has a feature to auto-encrypt all inbound emails to a PGP public key. Is this a nice feature to make it harder for someone to read my past emails if someone gets access to their infrastructure? Sure. Does this make my emails end-to-end encrypted? Absolutely not. In a similar vein, Signal making social graph correlation harder is a welcome feature but is not the same as making it anonymous.
Yes, I know you're aware of them :) And maybe I'm splitting hair here--I agree with you that Signal isn't as robust wrt anonymity as, e.g. Tor.
Signal explicitly considers anonymity/a private social graph to be a design goal. Their documented considerations of things like sealed sender and use of Intel SGX's remote attestation clearly demonstrate this.
Yes, these measures are imperfect. Like you say, it's a centralized service and has weaker anonymization properties because of that. However, because of its design, to de-anonymize Signal users requires the server operator to do continual, non-trivial work as long as they want to de-anonymize users.
In other words, deanonymization attacks against Signal users works just like any other kind of attack: the question isn't whether it can be done, but whether the attacker has the resources to do it. Presumably you'd consider Tor to be an anonymity tool. Yet, even though they're distributed, deanonymization attacks against certain users can succeed, given enough resources. (I don't mean to imply that Signal is equally resistant as Tor!)
Note: big fan of the work you all are doing at Amutable! I'm following the news eagerly. Best of luck!
Sure, I guess it's more a question of degree.
I still think the original point I was replying to ("don't stand out") doesn't apply to systems with "soft" anonymity like Signal. Even more importantly, arguing that specific features like custom servers or non-Firebase notifications are problematic because they "stand out" is particularly silly -- those features are the exact kind that are already fingerprintable by virtue of Signal's inbox design. Even if the social graph is somewhat anonymised, Signal does not attempt to hide that you are using Signal. (You could argue custom servers leak some data about your social graph but I'm not sure it is much worse than the theoretical leaks we spoke about earlier. And it's kinda notable that when Moxie argued against federated servers as a concept, that wasn't among the arguments he made.)