The main difference is that Ring.cx is built on top of open standards and only add the minimal additional infrastructure (the decentralized DHT layer) to allow it to work without a server. It is SIP compliant and can be used as work phone or your average VoIP provider, but you lose some the the privacy and advantages provided by decentralization.
Ring.cx is also not technically anonymous for mostly the same reasons. A decentralized hash table leave some metadata in the open, then when you call someone, there is a UDP stream between them. Ring wont give away your IP and details to the world, but it is vulnerable to many of the same metatdata vulnerabilities as Tor or Bitorrent.
You can configure Ring to be "more anonymous" by adding some proxies/middleman-server and messing with the connection sequence, but it cannot really be used in the default configuration or it would not "just work". Adding proxies for voice stream also add audio latency.
Edit: Our NAT punching is IETF compliant STUN/TURN/ICE/UPnP, so you can always just pick a third party you trust in the rare few cases you need one (we don't support IPv6 that well yet, so no luck there, it will come at some point).
Why is SDES the default and ZRTP disabled/unavailable in the windows client?
I'm no expert but SDES seems like a bad choice[1] from what I can gather in 5 minutes with google.
ZRTP is disabled because we are looking for a new implementation. The previous implementation we used depended on CCRTP and it wasn't running very well in least tested OS, like Windows. This is network facing code, so you have to have faith in the code, sandboxing help, but is limited. If anyone know a GPLv3 compatible stand alone C or C++ implementation, let us know.
To spell it out for you, sending keys unauthenticated is scary. Double scary because these folks are writing security software so it ought to be in their motor memory to avoid trivial mitm attacks.
The problem with public registries is that anyone can spam them. Checking the key would involve retrieving it via multiple sources which is tedious.
> doesn't apt-key already do that when adding the key?
Man page doesn't say, nor can I find quickly on Google if apt-key does any additional verification. It doesn't seem likely though, because if verification step did occur the entire command would be redundant as the same mechanism that verified the key could be used to verify source list entry.
I don't really get that part. You have everything needed to build it yourself (and so host it) on the wiki [0].
Also, everytime someone builds something now, it seems to be the first comment out there "it needs to be self-hosted". I get that this is a security oriented communication app, so it needs to be audited and open sourced so we can trust it, but now that this part is OK, people are finding something more to ask: the self-hosting part.
I would say that it is a valid question, because the answer sheds some light on the architecture and goals (or business model) of a project. It also reflects a (healthy) renewed interest in reducing our dependency on cloud services; because of privacy concerns or legal implications for example.
It is also not immediately apparent from Ring's website and wiki. The developers of Ring are quite helpful in replying here on HN though.
Ring.cx run server-less. It use the same technologies as Bittorrent (DHT tables) to find and connect users. You can also self host a server such as Asterisk or Freeswitch in a VM if you like, this is supported too, so is inter-operability with commercial VoIP providers.
Group chats are also possible. They've demonstrated it on the FOSDEM presentation, it should soon be available under: https://video.fosdem.org/2016/k1105/
This is not the same software. This ring is https://ring.cx/ But well, before the video you also get a ring sound just like before the voice. To me the only problem is that it is too generic: two words would be better.
"Ring is a secure and distributed voice, video and chat communication platform that requires no centralized server and leaves the power of privacy in the hands of the user."
I don't think most people actually care about any of this. The app is ugly, too.
I want a Skype killer, but everyone who writes this type of software panders to security and tech people, when really these applications should pander to people people.
If you leave out the secure, distributed, decentralised, free software, and privacy conscious aspects Ring is touting, you get Skype. Why do you want a Skype killer if not for those features?
Because of tact. That's why. It's entirely image. Anyone can make a great technical replacement for Skype. Multiple solutions have come before this one.
What do they all lack? What's the common pattern? They all pale in comparison to Skype's invitingness regardless of how horrible Skype has become over the years.
If I don't want to use voice calls or SMS messaging, these permissions are excessive.
I also can't distinguish between giving Ring permission to access all my contacts' details and send them to some third party, and giving Ring permission to associate ring IDs with contacts without exposing other details about that contact to Ring.
Also, you don't need storage permission to store app-specific data, only to access the "external" storage. (In general, this is the storage you see when you mount the phone over USB.) Presumably, this permission is to support copying an existing key from a PC.
Note that these problems are not Ring's fault, but caused by Android's permissions system. Fixing it in Ring would require splitting the app up into pieces for voice, sms, text, etc. Possible, but a lot of effort.
Only microphone (and the normal network) access makes sense. The ID management can reside in the app itself, separate from the unsecured phone agenda. Every other mentioned permissions are liabilities from a security point of view. These are valuable only because of convenience, and it's known that the very same convenience is used as a Trojan Horse carrier for means of abuse. To see that they focus on respectable goals like security, decentralization and free software and yet leak data in the phone for other applications or present a spectacular example of suspect feature creep, it's like hearing a sadistic joke.
We are working on that, it will likely change. Contact/phone integration cause most of them. The Android client is still Alpha code and experimental. The (Desktop) Gnome, KDE and OS X clients are the most mature. Windows is starting to be quite good too, almost on par with the other.
I'm excited about this! I'll even try contributing to the app :)
I haven't gone through the entire tech of it, but i'm guessing because you've said it is serverless, does it follow it similar to a DHT model? Are encryption and decryption of messages/data only possible and source and target and not by anyone intercepting it?
It use the DHT model, but not the mainline DHT (anymore).
> Are encryption and decryption of messages/data only possible and source and target and not by anyone intercepting it?
It would fail its purpose quite badly if it didn't ;)
I linked it elsewhere in the thread, you take a look at https://elv13.wordpress.com/2015/09/05/what-is-ring-and-how-... . It is outdated, but I hope it will give you the "big picture" of how Ring.cx work. Some parts are still incomplete and/or disabled by default, but 90% is there.
