Ridley

No, my views are not based on my own needs or paranoia. As a security-oriented software developer I recognize that software that claims to be secure needs to deliver, because people like Snowden, Assange et al. may be relying on it some day.

I'm not making any assumptions as to their motives; I have not accused them of any wrong doing. As far as I'm concerned, they might be working in good faith or they might not be. That's not good enough when it comes to security. You're incorrect with that last sentence as I and others have pointed out already.

Yes, in theory it is possible. However even 100% secure proprietary software must be assumed to be insecure, because we're still running on blind faith, which is patently stupid for anyone who requires security.

You're making the baseless (and some might say naive) assumption that it is secure to the best of their knowledge. If they really wanted to build trust then they would prove it and leave no doubt in people's minds.

Your points are well taken, but this is unfortunately a sacrifice that needs to be made in the name of security. While partial centralization would solve a few problems, it would also introduce weak points in its security model that three letter agencies would be quick to exploit.

Tox actually does NAT traversal quite well I've found, and it does support SOCKS5 connections out of the box, albeit through TCP relay nodes rather than direct P2P.

There are already FOSS replacements for Skype, such as Tox. The fact is that if every line of code can't be inspected then the software can't be considered secure, and we're forced to put blind faith in a faceless corporation, which is understandably not acceptable for many people. I don't really care if you think this is "practical" or not. That's simply the reality of the situation. Proprietary == insecure.

If a company is unable to profit off of making FOSS software then they can go ahead and keep it closed source, but they should not be claiming that their software is secure when their claims cannot be verified. That's simply dishonest, and only proves the critics right about their trustworthiness.

No one is taking this project lightly and I don't know why you would suggest otherwise. You keep vaguely alluding to "the nature of the commits" but still have yet to give a single concrete example of what you have issue with. I take it that you don't actually know any C and are just repeating what you've read somewhere else.

I have extensive C experience, and I have looked through the code. While there have been plenty of bug fixes in the commit log - as is to be expected for a project of this scope in its pre-alpha/alpha stages - I have not seen anything that resembles a security threat, much less something as serious as the heartbleed bug that you keep bringing up for some reason.

At this point I have to conclude that you're either a troll with too much time on your hands, or being paid to spread FUD.

Google play store doesn't have that problem.

Comparing C to Javascript makes no sense, and Javascript is NOT a safe language. Those issues you mentioned are due to programmer incompetence. Bad programmers will make bad code no matter what language they program in. Security should not rely on a language hand-holding bad programmers.

Yes, everything is encrypted from what I can tell.

You're talking complete nonsense. Constructive criticism please.

C is far from a non-safe language; it's the language of choice for NASA systems that lives depend on after all.

I'm not sure what you're trying to point out with those links. How is this related to openssl?

Toxic is the name of the CLI client. https://github.com/tox/toxic

I take the opposite perspective though. In nature toxins and poisons are used as protection against predators.