ERROR SaltyRTC.RSignaling - No shared sub-protocol could be found about saltyrtc-client-java

[dbrgn]

@lgrahl is the demo server already using the latest protocol version?

[sibirchakraborty]

Yes I checked that 0.8.2 (running v0 protocol is working fine with demo server). I have some difficult in setting the demo server on windows, hence would like to use the demo server for the time being.

NOTE: How to connect Initiator and Receiver from different IPs?

[lgrahl]

@dbrgn Nope. Updated it just now, thanks for the reminder. :) Probably incompatible with the demo until its being updated.

@sibirchakraborty The demo worked because it uses v0. The current master of this repository however does already use v1. I upgraded the server to v1 now. Try again.

By the way, there shouldn't be any issues running the server on windows, so let us know if there are any issues (in the server repo).

I don't understand your last question. The IPs of the clients do not matter at all, they find each other by the public key of the initiator.

[sibirchakraborty]

Hello, Also do you have a java based SaltyRTC Server? Regards, Sibir

…

On Sun, Apr 9, 2017 at 5:40 AM, Lennart Grahl ***@***.***> wrote: @dbrgn <https://github.com/dbrgn> Nope. Updated it just now, thanks for the reminder. :) Probably incompatible with the demo until its being updated. @sibirchakraborty <https://github.com/sibirchakraborty> The demo worked because it uses v0. The current master of this repository however does already use v1. I upgraded the server to v1 now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACn2PrI8f2MFI6SemjiwVgJ-1Tv_RMNkks5ruCHvgaJpZM4M3sFK> .

-- Thanks and regards, Sibir

[lgrahl]

Nope. We had no need for that so far.

[lgrahl]

Is this issue resolved or do you still have problems with the sub-protocol?

[sibirchakraborty]

No, please close the thread. One final query: SaltyRTC server/client can it be configured for Insecured access (like HTTP instead of HTTPS) for signalling?

…

On Sun, Apr 9, 2017 at 3:33 PM, Lennart Grahl ***@***.***> wrote: Is this issue resolved or do you still have problems with the sub-protocol? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACn2PmUSCZjDRkt92DDJyCdDE7ocJYuaks5ruK0KgaJpZM4M3sFK> .

-- Thanks and regards, Sibir

[lgrahl]

Yes, that's possible. Simply don't provide a certificate and a key and the server will tell you what you need to do.

saltyrtc-server serve

It is REQUIRED to provide a SSL certificate and a server permanent key unless the environment variable 'SALTYRTC_SAFETY_OFF' is set to 'yes-and-i-know-what-im-doing'

You can ask further questions to the server in its respository. :)

[sibirchakraborty]

How to connect to that kind of server which is non-HTTPS using SaltyRTC Client?

…

On Sun, Apr 9, 2017 at 4:20 PM, Lennart Grahl ***@***.***> wrote: Closed #68 <#68>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACn2PrAOaFOaNp3B6_zbq9kRYo9WYxjGks5ruLf1gaJpZM4M3sFK> .

-- Thanks and regards, Sibir

[lgrahl]

I think you have to override the protocol attribute of the Signaling class. It's intentionally hard to prevent insecure usage. @dbrgn can tell you more.

[dbrgn]

@sibirchakraborty right now the saltyrtc-client-java does not support connection to a server without TLS.

What would be the reason why you don't want TLS? For testing? If that's the case, I've planned to add documentation on how to generate a self-signed certificate for testing. You could also take a look at the testing setup that generates a self-signed certificate and adds it to a Java KeyStore: https://github.com/saltyrtc/saltyrtc-client-java/blob/master/.travis.yml#L25-L28 The same JKS file could be used in the client, see here. (Yes it's a bit complicated, but that's Java 🙄)

Regarding the demo app, I'll update it soon to use the latest protocol version.

[dbrgn]

The demo (https://github.com/saltyrtc/saltyrtc-demo) is now updated to the latest version. We still have quite some documenting to do :)

[sibirchakraborty]

Hi, Also, how to have 1 receiver with 2 Senders, can I have an example of that ? (example a chat room) Regards, Sibir

…

On Mon, Apr 10, 2017 at 2:39 AM, Danilo Bargen ***@***.***> wrote: The demo (https://github.com/saltyrtc/saltyrtc-demo) is now updated to the latest version. We still have quite some documenting to do :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACn2Ps8I6QcYTkZmXrtG3pBkKO-Zzjs2ks5ruUj4gaJpZM4M3sFK> .

-- Thanks and regards, Sibir

[dbrgn]

@sibirchakraborty group messaging is not currently supported by the protocol, SaltyRTC is intended for point-to-point connections. As far as I know, the same counts for WebRTC, a DataChannel is always between two peers.

You could designate one of the users as "admin" though. The admin has connections to all people in the chatroom and relays messages for them.

[sibirchakraborty]

But if you see PeerJS, which has Chat room solutions, this also uses WebRTC, but yes, server facilitates the chat. Is that possible in here?

…

On Mon, Apr 10, 2017 at 1:07 PM, Danilo Bargen ***@***.***> wrote: @sibirchakraborty <https://github.com/sibirchakraborty> group messaging is not currently supported by the protocol, SaltyRTC is intended for point-to-point connections. As far as I know, the same counts for WebRTC, a DataChannel is always between two peers. You could designate one of the users as "admin" though. The admin has connections to all people in the chatroom and relays messages for them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACn2PpN_r3Guz8Ot18OHs3rvT7p-uhVyks5rudwlgaJpZM4M3sFK> .

-- Thanks and regards, Sibir

[dbrgn]

Technically possible, yes. But not currently supported by SaltyRTC.

Please open an issue here https://github.com/saltyrtc/saltyrtc-server-python/issues if you want to know more.

[lgrahl]

You can do whatever you want on top of SaltyRTC. To establish a group chat using WebRTC data channels, you have to connect every peer with every other peer (or have a master peer that relays all data). The first one is quite finicky (but so is peer-to-peer group communication). The second one is easy:

1. Master peer acting as initiator generates a key for the upcoming responder.
2. Responder connects to the master peer using SaltyRTC.
3. Data channel messages are relayed from the master peer to each other peer.
4. (Optionally establish a connection to each other peer now.)

Only the key management will become easier and the amount of initial WebSocket connection will be less once we add group communication. Fully meshed peer-to-peer group communication will remain complex.

PeerJS will require exactly the same management but with PeerJS there will be no end-to-end encryption during the signalling phase, thus it's a much easier protocol.

[sibirchakraborty]

Are you going to add the group communication to SaltyRTC?

…

On Mon, Apr 10, 2017 at 2:55 PM, Lennart Grahl ***@***.***> wrote: You can do whatever you want on top of SaltyRTC. To establish a group chat using WebRTC data channels, you have to connect every peer with every other peer (or have a master peer that relays all data). The first one is quite finicky (but so is peer-to-peer group communication). The second one is easy: 1. Master peer acts as initiator generates a key for the upcoming responder. 2. Responder connects to the master peer using SaltyRTC. 3. Data channel messages are relayed from the master peer to each other peer. 4. (Optionally establish a connection to each other peer now.) Only the key management will become easier and the amount of initial WebSocket connection will be less once we add group communication. Fully meshed peer-to-peer group communication will remain complex. PeerJS will require exactly the same management but with PeerJS there will be no end-to-end encryption during the signalling phase, thus it's a much easier protocol. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACn2PsDhhlFHqDwhkHlWY2M4D-HRu3jKks5rufWMgaJpZM4M3sFK> .

-- Thanks and regards, Sibir

[dbrgn]

Maybe. It definitely has low priority though. The tracking issue is here: saltyrtc/saltyrtc-meta#83

I'll close this issue for now. If you have further questions, feel free to open a new issue in the respective project.