News aggregator

Knowing whether your messages have reached your server is a common problem for people on unreliable connections, and XMPP addresses this with XEP-0198: Stream Management. Support for XEP-0198 has been slow to take off, but we’re starting to see a network effect of clients and servers supporting it, with a patch available for Psi, support in the upcoming release of Prosody and a working prototype for Isode’s M-Link, so we’ve reached the stage that it makes sense to add it for Swift.

Remko’s written all the code we need in our Swiften library, and I’ve plugged the UI together to produce XEP-0198 support for Swift, demonstrated in the video below. This has so far been tested against Prosody and M-Link, and has already shown itself to be useful.

Support will be included in the next beta release of Swift, or is already available in the source code repository.

As we know Facebook supports XMPP for Chat, meaning you can use your preferred XMPP Client to use Facebook for Chat. But do you really think Facebook rolled out XMPP support only for Chat?
If so, you are indeed wrong.
Facebook wants to expend their communication profile. Like others like Google, MSN, Yahoo, Skype, etc, they also want realtime interaction meaning Voice and Video communications.

Reasons:

• Facebook users have more Facebook Friends than contacts in their phonebook.
• People change phone numbers and your are not automatically updated.
• Phone Numbers belongs to Operators/Countries, your Facebook account is much more personal.
• You can control who can call you. On regular phone you are often victim of unwanted calls.
• Phone Calls and SMS are more expensive them IM and VoIP in most cases.
• Facebook average number of Contacts per user is way bigger than Skype.
• Skype is too limited and close to create the same loyalty that Facebook always had.
• If they also open this for XMPP Federation, it would indeed speed up the death of "phone numbers" as we know.

Technology:

• As Facebook already have support for XMPP Chat, certainly they will use XMPP Jingle.
• For Media Relay and Distribution Points? For sure Jingle Nodes will be the simplest, fastest and most reliable way to delivery Multimedia for their gigantic number of users at once.
• How would it look like for browser users? They will use new advanced browser features to have Jingle Clients running on it. Like GMail already have for a long while.
• They already have the PERFECT routing and presence in place, XMPP for Chat, same exact route can be used for Jingle if Facebook enable support for IQ routing in their XMPP network.

Overall Picture:


This post is a proposition of how Facebook will do their Voice/Video support in near future. The use of Jingle and Jingle Nodes is not confirmed at all. But sure will be an extremely bad idea of Facebook to do not do it like described above! I challenge them to do it better and more open than this.

Our iPhone version of TextOne, the simple and fast messenger for smartphones, has received a nice photo sharing feature.

TextOne, the simple, light and fast smartphone messenger, is now offering a new feature to share photos with your friends.

Easy, a new icon appears at the top right of the conversation screen, you just need to tap it.

There, you can choose to take a picture or select one from your albums... and add the text you wish.

This will appear in the conversation as a taped instant photo, like any other messages.

You can also browse the photos exchanged with your contacts.

Of course, this also works with TextOne Pink!

Photo sharing in TextOne will let you share good moments with the people to whom you are close. Or alternatively play ;-)

And finally, you can play with it

Due the amount of comments and emails received, I will reply to them in a post.

• How does the Authentication works?
• That is one key reason for using their established XMPP channel for placing the calls. The user is already authenticated in GMail and Google Talk. So the request is sent through the authenticated XMPP network to their XMPP Component responsible to offer SIP Gateway. From that moment one the component will convert the Jingle Signaling from the Google Talk to SIP and use your Google credentials to authenticate in their SIP Services.
• Which Codec is being used?
• G711 is the only one that I could trace, although the Plug-In indeed support iLBC and others. The reason behind it, is that G711 is a supported codec in most all PSTN, Media Gateway or other interconnection with Legacy Telecom. Alternatives would be transcode, which is out of the question due CPU load, drop of quality etc... Or use proprietary G729 which requires the payment of extremely high royalties per client/channel.
• Will they succeed in making money?
• Google "Cows" may produce some "milk", but I doubt Google consider that as an important income resource. The feature is much more related with PR and positioning about THE REALTIME company, than anything else. Having most of what Skype does in their closed client, in a browser and using open technologies is a direct confront to Skype's model. IMHO, Phone Numbers are dead, and will be ripped out of the market in less than 5 years from now. 
• Are the API for Audio/Video Streaming available for third-party usage?
• That I could not figure out. Tried document or formal info from Google without success. May someone could assist us on that matter with some Javascript reverse engineering, or a Google guy, that wanna share that with us. Please let us know :)
•  Is there any client supporting it already?
• No, it is not yet available in any client that I'm aware. But I bet that as soon Google appears with a formal specification and documentation, that will happen very very fast.

Thanks for all the questions, I hope I have answered most of it.

I just confirmed in my Wireshark that Google Call on Gmail uses exactly what I recommended in a previous post back in 2009 when they acquired Gizmo5. And YES, it's Jingle!
Their wise choice of having a portable and extensive protocol(XMPP) as the bus and having specialized technologies like SIP, will grant them a flexibility never seen before on platform and device portability.
Their master plan is to be able to delivery mass market a cheap and alternative method for calling the old fashioned telephone numbers. And sure they have the right platform and tools in their hands:

Android

Almost all Android phones have with GTalk application pre-installed, which already runs a nice XMPP Client, besides other great alternatives like Nimbuzz.

Now imagine what Google can bring to the market without much effort due their choice of using Jingle extension of XMPP for their service? Google Call support on Android phones. That is the key and reason behind this service.



Overview Diagram:

Good things come to those who wait!

 

The Ignite Realtime Community is pleased to announce the beta for the next release of Openfire. This release contains a number of important  fixes and improvements to stability and XMPP protocol compliance. You can find a full list of fixed issues here. This beta is also the first version of Openfire to be released by the Ignite Realtime community under the Apache License v2.0.

 

You can download the 3.7.0 beta release here. Please provide us your feedback on the Ignite Realtime support forums. It would be helpful if you would tag your comments, discussions and questions with a tag that reads "openfire370beta"

 

As always, but particularly since this is a beta release, make sure to backup any existing version of Openfire and the persistent storage that it uses, before upgrading!

 

Some important security related notes to this release:

• Openfire no longer ignores the system property to disallow password changes via XMPP. With previous releases, it was not possible to prevent users from changing their password via their XMPP connection. (CVE-2009-1596)
• Fixed a XSS attack on the admin console login form.

 

Protocol compliance improvements:

• Publish Subscribe (PubSub)
• BOSH (http-bind) xml namespace compliance fix.

 

Some highlights of this beta release:

• Improves how Openfire handles "idle" connections. Some of you may have  the system property xmpp.client.idle set to -1 to work around  previously broken behaviour. You may now let it default to 6 minutes or  set it to your preference.
• Improved Openfire's caching to be less prone to memory exhaustion by correctly calculating cache size usage.
• Fixed a bug where admin console login into a newly installed Openfire server would fail until restarted.
• Fixed a bug with shared rosters within a LDAP environment.
• Openfire now ships with the latest JRE (1.6.0u21).
• A memory leak with the Personal Eventing Protocol (PEP) was fixed.
• Openfire's custom log interface has been replaced with SLF4J and a Log4J backend.
• Fix issues with self signed SSL certificates.
• A number of improvements and fixes were made to the Multi-User Chat (MUC) configuration pages on the admin console
• There were also some improvements made to the plugins.
• There are also French, Russian, and Lithuanian langauge translation fixes for Openfire and some of the plugins.

You probably have noticed many recent changes with Ignite Realtime! Thanks to the help of Benjamin Sherman of Jive Software, the entire suite of Ignite Realtime servers and infrastructure have been migrated to a Contegix hosted location external to Jive. This was done so that the community could take administrative control of Ignite Realtime and push projects forward as we wanted without relying on help from Jive Software.

So has Jive Software abandoned Ignite Realtime? No! They continue to generously fund the infrastructure and colocation costs at Contegix.  They also will participate with the community when appropriate. The community is now in tasked with moving projects forward!

 

So how will this work? At the moment, there is a handful of active community members that have been working hard to get the infrastructure setup. This infrastructure includes:

 

• Atlassian's Bamboo available at:  http://bamboo.igniterealtime.org
• Atlassian's JIRA available at: http://issues.igniterealtime.org
• Jive Software's SBS available at http://community.igniterealtime.org
• Atlassian's Fisheye available at http://fisheye.igniterealtime.org
• Subversion server at http://svn.igniterealtime.org/svn/repos

 

So who is running the show here? We currently do not have any formal community leadership process in place. The handful of us that are currently getting the infrastructure setup have been working together to make decisions to move Ignite Realtime forward.  With more community involvement and interest, we'll certainly wish to formalize roles and responsibilities soon.

 

So when will project X on Ignite make a new release? Depends Here is a brief summary of the various projects status:

• Openfire is very close to a 3.7.0 beta release. Guus der Kinderen and others have been working hard to squash remaining bugs and get a formal beta release out the door.
• Spark continues to struggle along and sure could use some developers to help get a formal release out the door. Please let us know if you are interested in helping out.
• XIFF released version 3.0.0 just this week thanks to the work of Mark Walters. Congratulations on the new release!
• Smack has seen recent development and could use more developers to help progress things along.
• Tinder is developed by Guus and he continues to make improvements to the library projects like Openfire uses.
• Spark Web has not seen development on Ignite for quite some time. Community member Dele Olajide has made a number of improvements to spark web on the version he maintains offsite.
• Whack could use some development help, so please let us know if you are interested.

 

At the end of the day, the productivity of the Ignite Realtime Community depends on you! We have been given the power to push projects forward as fast as we wish, so let us take advantage of this wonderful infrastructure setup provided by Jive Software.

 

Onward and upward!

(Cross-posted from the Gmail Blog)

Gmail voice and video chat makes it easy to stay in touch with friends and family using your computer’s microphone and speakers. But until now, this required both people to be at their computers, signed into Gmail at the same time. Given that most of us don’t spend all day in front of our computers, we thought, “wouldn’t it be nice if you could call people directly on their phones?”

Starting today, you can call any phone right from Gmail.



Calls to the U.S. and Canada will be free for at least the rest of the year and calls to other countries will be billed at our very low rates. We worked hard to make these rates really cheap (see comparison table) with calls to the U.K., France, Germany, China, Japan—and many more countries—for as little as $0.02 per minute.

Dialing a phone number works just like a normal phone. Just click “Call phone” at the top of your chat list and dial a number or enter a contact’s name.


We’ve been testing this feature internally and have found it to be useful in a lot of situations, ranging from making a quick call to a restaurant to placing a call when you’re in an area with bad reception.

If you have a Google Voice phone number, calls made from Gmail will display this number as the outbound caller ID. And if you decide to, you can receive calls made to this number right inside Gmail (see instructions).

We’re rolling out this feature to U.S. based Gmail users over the next few days, so you’ll be ready to get started once “Call Phones” shows up in your chat list (you will need to install the voice and video plug-in if you haven’t already). If you’re using Google Apps for your school or business, then you won’t see it quite yet. We’re working on making this available more broadly - so stay tuned!

For more information, visit gmail.com/call.
Posted by Robin Schriebman, Software Engineer

Google Call, as I mentioned before in a previous post, was added as a Calling feature direct to the browser.
I hope this take down Skype monopoly built on top of a closed and proprietary fuzzyware.

Google now has the most powerful position on VoIP world and soon will take down Skype eagerness for a proprietary/closed network.

Google's solution is built on top of a plugin, which is embedded on new Chrome and also easy to install on other browsers. They are using Standard XMPP and Jingle at Client Level with SIP in the backend, Streaming RTP with Standard Codecs directly from the browser. ( NO CRAP FLASH TRANSCODE USED! )

Google Call offer several advantages:

• Browser Based
• Open, so they can make use of third-party clients for it ( Do you need more reasons??? )
• VoIP everywhere, browser or in your favorite Client. Solid Model.

Hope Nimbuzz adds support for it soon!

You can try it here: http://www.google.com/chat/voice/


As you asked how it works:
Google is making use of recent acquired GIPS Company Technology to add native RTP streaming directly to the browser.
For PSTN Termination, Google is using Gizmo5, together with previous Google Voice partners.
I promise to post deeper technical information like protocol details and Codec later on.

 

We are pleased to announce the release of XIFF 3.0.0!

This major release includes many bug fixes, improvements, and features over the previous beta release, including Digest-MD5 support and removal of all Flex dependencies for pure AS3 project support. This release also includes a new class namespace (igniterealtime instead of jivesoftware).

You can view the full change log here.

 

Download XIFF from here.

 

Nightly builds are also maintained for XIFF now. You can access those here.

 

Enjoy!

There’s a raging argument going on in WebSocketLand (ie, the hybi@ietf.org list), between Shelby Moore and – well – everyone, about layered designs in protocols. I shared my views, but I thought it might be interesting to some of you lot, my imaginary readers, so I repost here.

To give you some context, the subject of channel binding was being raised as an interesting, and positive, application of layer violations.

On Tue Aug 24 03:32:28 2010, Shelby Moore wrote:

In the ideal way, one would first connect with say TLS, then Upgrade to the Authentication protocol, which would interact with the encrypt layer in a standard API, and then the higher layer would interact with the Authentication layer through another standard API.

FWIW, this is more or less how it happens, just with an ordering change.

One first connects with the application protocol (and there are several we might choose, such as XMPP). Next, a layer insertion happens, inserting TLS. Next, a second layer insertion occurs, inserting SASL. The SASL layer may communicate with the TLS layer for authentication or channel binding – both are abstract concepts, and could be done with an abstract API. Finally the application layer continues.

If you accept the conceit of layer insertion – and why not – then you can use the existing layer model just fine. Adding layer insertion also helps conceptually with compression techniques like XEP-0138 or RFC 4978, which insert a compression layer into the stack.

However, it’s important to recognise the distinction between a model, which is a method for people to understand and discuss particular areas of the overall functionality, and the reality.

In reality, the authentication provided by TLS, if any, is mediated by the application – which controls authorization, and therefore needs to ascertain whether the TLS credentials (typically an X.509 certificate) can be used to authorize the session. Similarly, SASL communicates back to the application protocol to translate from a username to whatever the application deals in (which can be similar or wildly different – for XMPP, a Jid; for LDAP, a DN). So as long as you don’t look too closely, the layer model holds, but in many areas, the boundaries are blurred.

There’s two important things to remember, though:

1. In abstract terms, the layers exist, and are reusable. Thus generic TLS and SASL libraries can, and do, exist, and applications can use them.
2. But the layer model is just a model; it is there for humans, and doesn’t produce any inherently better overall solution. By limiting the amount of knowledge required at each layer, though, it allows us to work around human limitations and achieve good solutions via combining specialized expertise. So I get to treat TLS as a “magically secure” thing for exchanging certificates and “doing security”, and TCP is “just a pipe”.

If anything, it’s the human expertise that really follows the layer model – as an application protocol guy, every time I need to know something new about TLS or TCP in order to properly code a client or server, that’s the kind of layer violation that I really care about.

Of course, the worst layer violation is the one where we force the user to have to have significant understanding of some portion of the stack. (We do this far too often, by trying to explain X.509 strong authentication to users in Firefox, and trying to explain the intricacies of unauthenticated addressing in internet mail).

It’s been a while since we released the previous Swift beta. As a result, the sixth beta is quite packed with bugfixes, speedups, and general improvements. The list of changes is too long to describe here, so head on over to http://swift.im/releases/swift-1.0beta6/ for details and downloads of the last Swift beta, and let us know what you think in the MUC room – swift@rooms.swift.im.

We  have just released Tinder  1.2.2, which is a maintenance release. It  fixes a number of bugs, features improved performance and has a number  of new features.

 

Download Tinder from: http://www.igniterealtime.org/downloads/index.jsp

Since upgrading to WordPress 3.0.1 recently, I’ve noticed that the category-specific syndication feeds seem to be broken. I’ll have to fix that so the folks at Planet Jabber don’t get bored with my posts about philosophy and such…

(Cross-posted from the Gmail Blog)

If you’ve been wanting to use voice and video chat on Linux (our top video chat request), then we have good news for you: it’s now available! Visit gmail.com/videochat to download the plugin and get started. Voice and video chat for Linux supports Ubuntu and other Debian-based Linux distributions, and RPM support will be coming soon.

Posted by Tristan Schmelcher, Software Engineer

Tsung 1.3.3 fixes severals bugs. It fixes support for SSL with erlang R14A.

Tsung 1.3.3 brings some minor bugfixes.

• fixed parent proxy not working in 1.3.x (tested with 1.3.2 and 1.3.0).
• fixed url substitution is broken in some cases
• fixed Tsung not using sessions with low probabilities
• fixed SSL not working with erlang R14A
• fixed failure when a proxy is used and an URL substitution is set
• fixed HTTP cookies support when a proxy is used
• fixed hanging at the beginning using distributed setup
• fixed "if" statement, which is not allowed in a transaction

My friend Dizzy just pointed me to a fine essay by Daniel Akst on friendship (or the lack thereof) in modern society. It’s no surprise that I would enjoy the essay, given that I’m a big fan of both Aristotle and Epicurus, that I have written two essays on friendship, and that I have re-published essays on the topic by Emerson, Montaigne, and Randolph Bourne over at monadnock.net. Good reading!

This is my final report on my Google Summer of Code 2010 project. During the last three months I've learned quite a lot about Psi's and Iris' codebase and implemented most of what's been planned.

I started off implementing a new SASL mechanism, SCRAM-SHA-1, in Psi which will be used if no external SASL library is available.
Using this mechanism users can login securely even over unencrypted connections and if they want Psi to remember their password, this can be done more securely if SCRAM-SHA-1 is available at the server.
More on this part here.

The second part of the project was implementing Stream Management, XEP-0198, in Psi. Luckily, Matthew Wild, one of Prosody's main developers, started to implement it around the same time so we could easily test each independent implementation against each other.
I've implemented the most important and interesting parts of XEP-0198: stanza acknowledgment and stream resumption. Together they make chatting, but basically everything in XMPP, more reliable.
Especially stream resumption is nice in case your connection is dropped. In this case you don't have to go through the whole roster retrieval and presence distribution steps again. The stream resumption part wasn't that easy to implement, because currently Psi destroys its complete XMPP stack state on disconnection with the server.

During the last couple of weeks I've added a new groupchat join dialog to Psi. This included reusable data models for browsing server room listings, bookmarks and history of joined rooms. Additionally the new dialog lets you choose more than one room to join. I've also modified the still existing old join dialog (It still exists because it also handles join logic.) to support bulk join. This means if you join multiple rooms on login, due to bookmarks, or via the new join dialog, the dialogs indicating join process are hidden as long as no error occurs.

It was quite interesting getting to know Psi's and Iris's codebase which are from quite varying design quality considering their parts but most of the time it was quite understandable and Justin, Psi's and Iris's original and main developer, was always able to answer my questions on the code and design.
Coding in the GSoC umbrella organisation XSF was quite fun and well organized. The weekly meetings helped to keep you on track and frequent reports from fellow student kept you up to date on their projects' progress.

All the developed code is available at my github account.

While travelling in Europe a few weeks ago, I thought of a book I’d like to write:

Don’t Buy This Book, You Can Read It for Free on the Internet!
The Closing of the Copyright Era, the Open-Sourcing of the Book, and What it All Means for Readers, Writers, and Publishers

Not that I’ll have time to write it anytime soon…

I finally got the new join dialog for Psi finished.

When the dialog opens it shows you the rooms available at your server, if there are any, your recently joined rooms and your bookmarked ones. At the top you simply enter the nickname which you want to use to join the rooms.

There's little special about this dialog and it works how you'd expect it to work, hopefully. If you want to give it a try yourself the code is available here.