To quickly add XMPP functionality, you could let users manage their chat buddies via Converse.js.
#EJABBERD VIDEO CALL CODE#
This will however require server-side code that can talk XMPP and therefore take a lot of time to implement nicely. That way the new “friend” automatically also becomes a chat buddy. So, when you accept someone’s friend request, the pod looks up that person’s XMPP username and sends an XMPP contact subscription (on your behalf) to that persons. they’ll be on your XMPP contacts roster) and there would be no need to add them again via Converse.js just to chat. If you “friend” someone, you’ll automatically be able to chat with them (i.e. The important thing is that the user give their Jabber credentials to the Diaspora pod, and the pod then keeps a mapping of the user’s Diaspora ID and Jabber ID and manages the users chat rosters. Loose coupling of XMPP credentials and Diaspora user account.Tight coupling of XMPP credentials and Diaspora user account.I can think of mainly two ways of adding XMPP support (both don’t require an XMPP server per pod). So certain people might want to re-use those accounts. There are public XMPP servers available (like ) and many people and companies host their own XMPP servers already.
#EJABBERD VIDEO CALL INSTALL#
Can we not let pod owners decide for themselves whether they want to install an XMPP server or not? This is bleeding edge stuff and broad support among browsers (for WebRTC) and XMPP servers is still lacking.Ībout deploying XMPP servers, I think we could perhaps do this organically. I’m sure Ejabberd and other servers will eventually catch up, but this is something to keep in mind. Thanks and I was playing with strophe.jingle about a month or so ago and noticed that it is tested with Prosody XMPP server and doesn’t yet work with Ejabberd (which is what I’m using ATM). Strophejs is an dependable workhorse and there is even a book explaining it. stanza.io is a quite good approach to hide the uglyness of XML (aka “legacy JSON”) from web developers by letting them work with JSON objects.
What library you choose is mostly a matter of preference of the guy who develops this. There is actually a third jingle implementation in the browser at and I am expecting another one to join us very soon. WebRTC doesn’t allow unencrypted media traffic at all. Others, like pidgin, are still lagging behind. Now Jitsi is one of the audio/video clients that drive development of modern protocols. In the meantime, XMPP offers a way to detect that a client is not capable of doing WebRTC+Jingle and fall back to sending a URL. That is going to be fixed at some point, but fixing and stabilizing interop between strophe.jingle in chrome30 and jitsi is currently a higher priority.
So strophe.jingle currently kind-of works with jitsi. Otherwise you could just buy the “just use our API and exchange an URL and be happy” story that some people are selling in that area. The biggest advantage in using a standard like XMPPs Jingle for WebRTC signalling is of course interoperability. Check out for a great introduction to webrtc and why you should avoid building silos (little chance here and use XMPP.
Using Jingle, which is XMPPs way of doing this is one alternative. How that is negotiated is left to the javascript. It’s just a media engine which captures data from your webcam or microphone and sends it to a peer. So… speaking as the developer of the strophe.jingle stuff and also contribute to the jingle stuff in stanza.io.
0 kommentar(er)
