3 ms·

> This technology for peer-to-peer discovery is also not standardized, I assume. DHT has been used in the wild for more than a decade now, it is very well unde

by Elv13 11y ago

> This technology for peer-to-peer discovery is also not standardized, I assume. DHT has been used in the wild for more than a decade now, it is very well understood. SIP over DHT idea has also been studied[1] academically for a long period of time, even if it was never really implemented in commercial products. Finally, our P2P "protocol" is still using the standards mentioned above for cryptographic identity and other negotiation details, so there is very little that isn't fully standard. [1] Example: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183.4313&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183... (not used for the current Ring implementation)

madez 11y ago
DHT has been used in the wild for more than a decade now, it is very well understood. Tox also uses DHT for contact discovery [1]. Does Ring support communication without having to register any type of account on any third-party server? [1]: https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artifact/tox.pdf/ https://jenkins.libtoxcore.so/job/Technical_Report/lastSucce...
- Elv13 11y ago
  No server account are required, it is what DHT is for. However, if you do have a server SIP account, we also support them. This is all about interoperability with existing infrastructure.
  - madez 11y ago
    I see value in the support of server accounts. However, the DHT-based account-less p2p part seems to redoing work Tox has done. Why not use their efforts and experience? They offer their core separately and Ring could be a client for it.
    - Elv13 11y ago
      That would duplicate most of our code and we chose not to do so. We currently have an unified architecture that handle both existing sip infrastructure and the distributed one. The distributed part is less or more done, it isn't a big part of the code (about 4% according to a quick rexgex) compared to SIP. We currently use an open network model, but will switch to a closed one based on the cryptographic chain of trust in the coming weeks. That about all there is to it, everything else is SIP/ICE/UPnP/TLS/RTP.
      - madez 11y ago
        That would duplicate most of our code You wouldn't have had to write that code if using Tox were chosen in the first place. will switch to a closed one based on the cryptographic chain of trust This could differentiate the decentralized part of Ring from Tox. Can you give more details on this? Anyway, I still think you should try to join efforts.
      - Elv13 11y ago
        > You wouldn't have had to write that code if using Tox were chosen in the first place. First of all, it is important to understand that Ring is based on SFLphone. Our team have over 10 years of experience (and code) working with the existing SIP infrastructure. Have an inter-operable SIP based decentralized network is really the whole point of doing what we do. > Can you give more details on this? (please note that this section talk about features in development, it can still change) The classical phone network is an open system. Everybody call call everybody, some for emails. This can cause some issues, such as tele-marketing and scam (+ spam, called "SPIT" in the VoIP community). Some other IM networks (MSN messenger, Skype, in fact, most of them) use the opposite. You can only open communication with people who are whitelisted. Traditional SPAM methods are mostly useless on most VoIP media such as voice and images as there is no "ahead of time" processing (everything is RTC). A distributed server-less network also cannot ban accounts, there is none. With IPv6, an IP based blocklist is also impossible. There is a bunch of ways to fix those issues. One is to build a validation network be asking the peers you currently trust to validate new persons. The downside of this is some serious anonymity issues. You basically tell the world who is calling you. The second option is to use a chain of trust. There is multiple ways this can be implemented. First, it can be done on the DHT itself. You only talk to nodes that are signed by a certificate authority you whitelisted and use TLS revocation and other protocol features to manage a pseudo-clean distributed closed-network from which intruders are banned. The second way is to use the full "global" DHT, but only allow calls signed by a trusted authority. For example, this allow a small startup to sign a bunch of certificates, place them on the DHT and let employees call each other. This network will be about as insulated from unwanted external calls as a private SIP server. Obviously, those 3 strategies are complementary and can be combined to eliminate SPIT and to a certain extent third party meta-data collection.

by Elv13 11y ago

madez 11y ago

DHT has been used in the wild for more than a decade now, it is very well understood. Tox also uses DHT for contact discovery [1]. Does Ring support communication without having to register any type of account on any third-party server? [1]: https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artifact/tox.pdf/ https://jenkins.libtoxcore.so/job/Technical_Report/lastSucce...

Elv13 11y ago
No server account are required, it is what DHT is for. However, if you do have a server SIP account, we also support them. This is all about interoperability with existing infrastructure.
- madez 11y ago
  I see value in the support of server accounts. However, the DHT-based account-less p2p part seems to redoing work Tox has done. Why not use their efforts and experience? They offer their core separately and Ring could be a client for it.
  - Elv13 11y ago
    That would duplicate most of our code and we chose not to do so. We currently have an unified architecture that handle both existing sip infrastructure and the distributed one. The distributed part is less or more done, it isn't a big part of the code (about 4% according to a quick rexgex) compared to SIP. We currently use an open network model, but will switch to a closed one based on the cryptographic chain of trust in the coming weeks. That about all there is to it, everything else is SIP/ICE/UPnP/TLS/RTP.
    - madez 11y ago
      That would duplicate most of our code You wouldn't have had to write that code if using Tox were chosen in the first place. will switch to a closed one based on the cryptographic chain of trust This could differentiate the decentralized part of Ring from Tox. Can you give more details on this? Anyway, I still think you should try to join efforts.
    - Elv13 11y ago
      > You wouldn't have had to write that code if using Tox were chosen in the first place. First of all, it is important to understand that Ring is based on SFLphone. Our team have over 10 years of experience (and code) working with the existing SIP infrastructure. Have an inter-operable SIP based decentralized network is really the whole point of doing what we do. > Can you give more details on this? (please note that this section talk about features in development, it can still change) The classical phone network is an open system. Everybody call call everybody, some for emails. This can cause some issues, such as tele-marketing and scam (+ spam, called "SPIT" in the VoIP community). Some other IM networks (MSN messenger, Skype, in fact, most of them) use the opposite. You can only open communication with people who are whitelisted. Traditional SPAM methods are mostly useless on most VoIP media such as voice and images as there is no "ahead of time" processing (everything is RTC). A distributed server-less network also cannot ban accounts, there is none. With IPv6, an IP based blocklist is also impossible. There is a bunch of ways to fix those issues. One is to build a validation network be asking the peers you currently trust to validate new persons. The downside of this is some serious anonymity issues. You basically tell the world who is calling you. The second option is to use a chain of trust. There is multiple ways this can be implemented. First, it can be done on the DHT itself. You only talk to nodes that are signed by a certificate authority you whitelisted and use TLS revocation and other protocol features to manage a pseudo-clean distributed closed-network from which intruders are banned. The second way is to use the full "global" DHT, but only allow calls signed by a trusted authority. For example, this allow a small startup to sign a bunch of certificates, place them on the DHT and let employees call each other. This network will be about as insulated from unwanted external calls as a private SIP server. Obviously, those 3 strategies are complementary and can be combined to eliminate SPIT and to a certain extent third party meta-data collection.