I think that it is not ideal, but changing it means that Signal would need to store the entire contact-graph of the network, which is much worse from my POV. I think they want to go there which is why they are doing the SGX-thing.
The only motivation I can think of for moving contact lists server side would be to make moving from one phone to another easier, but that's not required to implement easy migration.
But not having this decreases usability even further. You wouldn't only need to discover all of your contact's usernames, but also need to rediscover them when you lose your phone. All these things are solvable, but I just don't see it happening.
The things I asked for are very straightforward and don't require coimplicated changes of the status quo.
@__h2__ @fdroidorg Signal protocol over XMPP sounds great to me. When people lose their phone, they can recover the XMPP usernames of the people they talk to the same way they would recover their address book (which for me is backups)
I do hear you about discoverability though. Usernames require two parts so it's clear which server should get the traffic. People accepted that paradigm for email though.
Do you know of any mobile apps that make e2ee XMPP easy?
I wrote a proposal some years ago to add phone-number bases client-side discovery, but the authors were not interested ;-)
@__h2__ @fdroidorg I read through your proposal and my concern is that it would allow a guess-and-check way to obtain a person's contact list. Just query a user with all possible phone numbers. This is bad in that I can't control if anyone ever puts my JID and phone/email in their contact list and this feature is the link that allows randos to query this info.
If I were an advertiser, or Facebook or whomever, I'd absolutely use this to suck up contact lists.
Mostly hackers, mostly in Urbana, IL, talking to each other & our friends on like-minded servers without giving our personal data to the marketing machine.