[0]: The story of Karl Koch for example https://en.wikipedia.org/wiki/Karl_Koch_(hacker) who's death was ruled a suicide, and his history is... "colourful".
True anonymity in a messaging service is hard to achieve, and not even remotely user friendly.
As a practical example, would you say that bitcoin wallets are anonymous, given that they use random IDs?
Still beats using your phone number for chats, or your SSN in place of bitcoin wallet.
Again, for the practical example, people bought and sold bitcoins with the broad assumption that it was anonymous. It's a widely understood falsehood, yet new people almost universally believed it was anonymous and safe from law enforcement/the tax man.
Pretending that a random yet static ID adds any level of anonymity is simply dangerous. At best, it keeps honest people honest; like locking your door but not the bay window next to it.
https://signal.org/blog/contact-discovery/
(not just individual people obsessed with privacy, the large numbers of people who can see the advantage of privacy but may not invest a lot of effort to achieve it)
* has (almost) no tests,
* has no CI (at least I could find none),
* lacks some basic features competitors have,
* sometimes doesn't ring when you call, and
* they just closed all 1100 open issues without reading their contents [1]."
Don't get me wrong, I think Signal is a great idea and have contributed some code to it, but these look like some red flags to me.
Obviously hard to compare to Telegram, which is closed source so we can't know whether they have similar problems.
[1]: https://github.com/signalapp/Signal-Android/issues/7598
What do tests and CI have to do with the usability and usefulness of a program? I agree that the other issues could be worrying, but those first two throw me for a loop.
The grandparent poster also wrote about security/privacy, for which I think tests are pretty important.
Finally, having CI would allow the developers/contributors with limited time to spend more time on usability and usefulness instead of on issues like "master doesn't build, anybody else have this problem?" (when I wanted to PR something to Signal, master did not build).
This also makes the assumption that since there are few automated tests, that there are no tests done on a build at all. I disagree that it is a valid assumption. Most security vulnerabilities are not found by unit or functional tests, but instead by linting and code reviews.
This may be true in a megacorp. I doubt it's true in a project like Signal where resources are limited and a few developers are the single bottleneck for everything, UX or otherwise.
>However, the sheer volume of legacy issues, combined with submissions that completely ignore the provided issue template, has created a situation where there are currently more than 1,100 open tickets. Most of these issues have been inactive for several years and they reference versions of Signal that are no longer available. Many open issues are essentially ad-hoc discussion threads or feature requests that are a better fit for the community forum. Perhaps most importantly, many of these issues lack debug logs, descriptions, and the steps that would be necessary to understand and reproduce the reported behavior.
Oh, and they will keep doing so: "Legacy issues that are more than one month old will be closed by an automated process as part of this cleanup effort."
https://news.ycombinator.com/item?id=13396083
I'm running this on my own server (using ejabberd [1] as Prosody - which I used previously - still has problems with some of the required XEPs[2]) using several different clients (Conversations [3] on Android, Pidgin on Linux, etc).
The one weak link in OMEMO is the difficulty of verifying the authenticity of the device key signatures used by communication counterparts. These signatures are 64-character hexadecimal strings which the user is supposed to verify being authentic before initiating encrypted communications. Humans as not very good at this task, computer can help but they can also be tampered with. There are ways around this problem - e.g. meeting up in person before initiating communications (viz. PGP key signing parties), sending Q-codes off-line, using algorithms to turn those numbers into things which humans are better at recognising (e.g. the coloured emoji used by Telegram etc.). Encrypted group chat only works if all participants have all other participants in their address lists. Then again, it does work and it is fully standardised with several compatible implementations.
[1] https://github.com/processone/ejabberd
It's "good enough" for 90% of cases, but it depends on clients supporting emoji.. :(