Planet Jabber News
Sun Apr 24 04:41:42 EDT 2011
Home: http://planet.jabber.org/news/
Feed: http://planet.jabber.org/news/rss20.xml

Ignite Realtime: Openfire 3.7.0 has been released -

If you tried to register a new account in the last ~48 hours, you probably noticed that the certificate we use expired. We’ve updated the certificate at register.jabber.org so that it uses the same certificate we use for the XMPP service. You can now register accounts securely again. :)

The digital certificate for the jabber.org service expired this morning. We’re working to renew it as fast as possible, but it might take an hour or two because it requires manual approval by our certification authority. Sorry about the confusion.

UPDATE: The new cert is in place, and improved processes are on the way. :)

ejabberd 2.1.6 has been released, after four months of development. It contains a lot of bugfixes, improvements and some new features.

This is a small list of changes:

• BOSH: Fix rare loop, support vhosts, allow module restart
• Config: Default configuration allows registrations only from localhost
• Config: Support to change loglevel per module at runtime
• Erlang/OTP: Fix compatibility from R10B-9 to R14B01
• ODBC: Compatibility with PostgreSQL 9.0
• Privacy lists: Fix to allow block by group and subscription again

read more

ejabberd gets 8 years old. But no party yet, Yozhik is bugfixing 2.1.6 and testing 3.0.0-alpha-2.

The source and more photographs of hedgehogs pets.

read more

Here comes another short update on my Google Summer of Code project.

Stanza acknowledgement is finally done, including representation in the GUI. You can see a short demonstration of the feature in the video below where I'm chatting with Matthew Wild, one of Prosody's main developers. He developed a module for Prosody that implements parts of Stream Management. This made my client side implementation much more easier to test.

The idea is simple: the status icon in the top left corner is replaced with a throbber animation, known to users from recent OSes and browsers, as long as there are messages that haven't been acked by the server.
Psi will at least request an ack after half a minute. However only if there's something to acknowledge for the server.

This week is mid-term evaluation of the Google Summer of Code projects. SCRAM support and stanza acknowledgement, which is the most important part of the Stream Management XEP, are both finished including GUI.

I’ve filxed some minor issues, and some that could cause a crash.

This version is still 32bit, Windows 7 only.

Download here.

We’re intending to upgrade the OS on our XMPP system tomorrow evening. Although we’ll try and limit the turbulence, we’ll have to suffer at least a brief period of outage while we restart the server etc.

I’ve just recompiled xim against final (RTM) version of .NET 4.0.

Please download and reinstall .NET 4.0 RTM.

download here

On Wednesday we installed an updated build of M-Link, but we didn’t want to post about it yesterday because it was April Fools Day. :) This new build includes fixes to a few small bugs (persistence of chatroom subjects and vCard updates) as well as support for the SCRAM authentication mechanism (which we still need to enable before you can start testing with cutting-edge IM clients).

I’ve just hopefully fixed a problem when xim stuck on “Contacts Loaded”. This was really hard to find because it was happening only on specific servers.

Try to test it now.

download again :)

This morning the jabber.org admin team installed a new build of M-Link provided by Isode. This build addresses the major issues we’ve had over the last month or so.

First, communication between Google Talk and jabber.org appears to be fixed. We can’t promise that you’ll never experience any difficulties chatting with your Google Talk friends, but the previous problem (lagged and in some cases lost messages) has been solved.

Second, the old legacy SSL port 5223 is working again, enabling you to connect using most older clients (e.g., iChat on Tiger) as well as various “crippled” clients that still don’t support STARTTLS on port 5222 (e.g., mobile clients like QIP and SIM). We will continue to encourage developers of those clients to add STARTTLS support and we reserve the right to turn off port 5223 at some point in the future, but we probably won’t do so until platforms like OS X Tiger and KDE 3 have been end-of-lifed.

Several smaller issues have yet to be fixed (e.g., chatroom logs and persistent storage of changes to personal vCards and chatroom configurations), but we will be working with the Isode team on those fixes in the coming weeks. We are also aware that we still need to get web registration working again. If you really need a new jabber.org account instead of an account at one of the many other open XMPP services, please use the contact information provided on the Get Help page for assistance and we’ll try to take care of your request as soon as possible.

This is just a quick note to let jabber.org users know that the folks at Isode have been working on fixes to a number of the open issues we mentioned in our last update, including our communication problems with Google Talk. Testing is underway and we hope to be installing updated software this week.

http://xeus.googlecode.com/files/xim.zip

- some fixes

- improved message rendering

- live preview of the links!

Our apologies for the lack of reports over the last 10 days or so — most of the jabber.org admin team was at FOSDEM 2010 / XMPP Summit #8 the weekend of February 5-8, and it takes a little while to recover from so much Jabber fun. :)

As you might have noticed, last Friday we installed an updated build of M-Link, which incorporates a number of fixes and has been quite a bit more stable.

There are still some unresolved issues that are being worked on by the jabber.org admin team, the Isode M-Link team, or both:

1. Communication between Google Talk and jabber.org has unacceptable lag most of the time. We’re still working to debug this problem.
2. Some old or incomplete clients simply cannot connect to the server securely since we turned off the legacy SSL-only port 5223, including Miranda (see update!), Palringo, QIP PDA, Sameplace, and old releases of clients like Kopete on KDE 3.x and iChat on OS X Tiger. Although most clients are working just fine on port 5222 with encryption upgrade using STARTTLS, we will turn port 5223 on again in the near future (this requires a new build from Isode because they never expected that people still needed port 5223, given that it was deprecated in 2004!).
3. Room logs are not enabled yet for posting to logs.jabber.org. We should have those working again in the next week.
4. New user registration is not working yet at register.jabber.org. We’ll try to have it working again this week or next (there are some backend changes required). Until then, feel free to create an account at one of the many other XMPP-based IM services.

We think those are the main issues at this time, but as always feel free to join the jabber@conference.jabber.org chatroom via XMPP or HTTP if you have questions or comments.

– Peter Saint-Andre

It turns out that the Miranda IM client for Windows does indeed support encrypted connections on the standard XMPP port 5222. As explained by Boris Krasnovskiy on their developer list, if you are a Miranda user then you need to configure your preferences under Main Menu > Options for “port 5222″ and “Use TLS” in order to connect securely to the jabber.org service.

After many months of planning, ejabberd and exmpp have been fully migrated to Git.

During the last 7 years, ejabberd source code was hosted at:

• CVS at Jabber.Ru
• CVS at JabberStudio.org
• SVN at ProcessOne
• Git preliminarly built with git-svn, at Github

Starting now, ejabberd source code is natively in Git, and hosted at:

• https://git.process-one.net/ejabberd
• http://github.com/processone/ejabberd

The minimal instructions to start using it are mentioned in:
http://www.process-one.net/en/ejabberd/downloads

read more

As you might have noticed, the jabber.org IM service has been much more stable in the last few days, thanks to a number of bug fixes from our friends at Isode. There are still several known issues that have been fixed in M-Link, but both Isode personnel and jabber.org admins are travelling this week for the XMPP Summit in Brussels this weekend, so we won’t deploy any updated software builds until sometime next week. This will also give Isode’s QA department an opportunity to complete some more thorough testing than was possible while we were all in “crisis mode” over the last two weeks. Finally, we are also still working to pinpoint some remaining issues (such as delayed and even dropped messages from gmail.com to jabber.org), which the admin team will discuss with the Isode team this weekend. If pertinent information becomes available, we will post again in the next few days. Thanks again for your patience during the recent migration.

Peter Saint-Andre

This is the jabber.org service notice for Friday, January 28, 2010.

For the most part, today was a good day at the jabber.org IM service. We installed a new build from Isode earlier today that seems to have solved the login delays our users experienced, as well as most of the memory usage issues. This build isn’t perfect, because we had a hard crash this evening, followed by some false restarts, so we’ll be monitoring it closely over the weekend. In addition to these fixes, the jabber.org admin team corrected a problem with our digital certificate and continues to debug connection issues with a number of different IM clients.

We will post updates over the weekend, so stay tuned.

This is the jabber.org service notice for Thursday, January 28, 2010.

I think it’s safe to say that today was fairly frustrating. It was frustrating for our users, because login times were extremely slow. It was frustrating for the Isode team as they struggled to find the causes of high memory usage and deal with a few nasty bugs related to DIGEST-MD5 authentication. It was frustrating for the jabber.org admin team as we worked to diagnose some strange disk I/O behavior on the server machine itself.

This evening, Isode’s Curtis King and I completed some further testing and the initial results look promising, but we’ll know more tomorrow.

Thanks for hanging in there with us…

Peter Saint-Andre

This is the jabber.org service notice for Wednesday, January 27, 2010.

There’s not as much to report today. The Isode team continues to track down the memory issues as well as a few less significant bugs and feature requests (DIGEST-MD5 login issues, vCard fixes, enabling chatroom logs, etc.). On the jabber.org team we are working to diagnose connection problems experienced by some users of Finch, Gajim, GNU Freetalk, Kopete, Meebo, Palringo, and a few other clients (most of the issues seem to be related to our disabling of the old SSL-only port 5223, but there might be other bugs involved). We also discovered an IP address that was making about 50 TCP connections a second without ever trying to start an XMPP stream, so we have blocked that IP address. We’re on the lookout for other abusive traffic, which might be causing more general problems at the jabber.org service.

Today we also held an impromptu meeting of jabber.org users in the jabber@conference.jabber.org chatroom. If our users would like us to hold a weekly meeting for a while, drop by the jabber@ chatroom and let us know (you can even join via the web as described on the help page).

Tomorrow (Thursday) we plan to fix a problem with our certificate chain, deploy several fixes from the Isode team, and track down more of the client connection problems mentioned above. We’ll keep you posted via identi.ca (mirrored to Twitter).

Peter Saint-Andre

Share this screenshot with friends. [link]

Yes, ejabberd is already 7 years old.

Let's celebrate with a timeline of ejabberd, Erlang/OTP, XMPP/Jabber protocol, and Tkabber:

If you find any mistake, please comment. I built the graph using EasyTimeLine.pl, if you want the datafile, please comment.

read more

Version 0.3 of XEP-0227: Portable Import/Export Format for XMPP-IM Servers has been released.

This document specifies a file format for importing and exporting user data to and from XMPP-IM servers.

The changelog is:

Modified to include feedback received during the initial Last Call. Added sections for privacy lists and incoming subscriptions, as well as text on XInclude security. (wh)

Version 0.9 of XEP-0186: Invisible Command has been released.

This document specifies an XMPP-compatible protocol for user invisibility.

The changelog is:

Further clarified server and client handling of stanzas during an invisibility session. (psa)

Version 0.2 of XEP-0225: Component Connections has been released.

This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers.

The changelog is:

Modified namespace to incorporate namespace versioning; clarified that the value of the element can be either or resource>. (psa)<p>

Version 0.3 of XEP-0152: Reachability Addresses has been released.

This document defines an XMPP protocol extension for communicating reachability information related to non-XMPP devices.

The changelog is:

[See revision history] (psa)

Version 0.2 of XEP-0251: Jingle Session Transfer has been released.

This specification defines an extension to XMPP Jingle for transferring a session (such as a voice call) from one person to another.

The changelog is:

Updated examples; added reference to RFC 5359; added security considerations regarding unattended transfer. (psa)

Version 0.12 of XEP-0181: Jingle DTMF has been released.

This specification defines an XML format for encapsulating Dual Tone Multi-Frequency (DTMF) events in informational messages sent within the context of Jingle audio sessions, e.g. to be used in the context of Interactive Voice Response (IVR) systems. Note

The changelog is:

Corrected definitions and schema to make it clear that the code attribute contains one and only one character representing a DTMF tone. (psa)

Version 1.0 of XEP-0270: XMPP Compliance Suites 2010 has been released.

This document defines XMPP protocol compliance levels for 2010.

The changelog is:

Per a vote of the XMPP Council, advanced specification from Experimental to Draft. (psa)

Version 1.2 of XEP-0175: Best Practices for Use of SASL ANONYMOUS has been released.

This document specifies best practices for use of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server.

The changelog is:

Provided more detailed recommendations regarding usage restrictions for anonymous users, including the concept of different deployment types; added note about the user/anonymous service discovery identity. (psa)

Version 0.7 of XEP-0168: Resource Application Priority has been released.

This document defines an XMPP protocol extension to indicate the presence priority of XMPP resources for applications other than standard XMPP messaging.

The changelog is:

[See revision history] (psa)

Version 0.3 of XEP-0197: User Viewing has been released.

This document defines an XMPP protocol extension for communicating information about the television shows, movies, or other videos that a user watches.

The changelog is:

Modified namespace in accordance with protocol versioning policies. (psa)

Version 0.3 of XEP-0196: User Gaming has been released.

This document defines an XMPP protocol extension for communicating information about the games a user plays.

The changelog is:

Modified namespace in accordance with protocol versioning policies. (psa)

Version 0.3 of XEP-0195: User Browsing has been released.

This document defines an XMPP protocol extension for communicating information about the web pages a user visits.

The changelog is:

Modified namespace in accordance with protocol versioning policies. (psa)

Version 0.3 of XEP-0194: User Chatting has been released.

This specification defines an XMPP protocol extension for communicating information about the chatrooms a user visits.

The changelog is:

Modified namespace in accordance with protocol versioning policies. (psa)

Version 1.1 of XEP-0136: Message Archiving has been released.

This document defines mechanisms and preferences for the server-side archiving and retrieval of XMPP messages.

The changelog is:

Moved JID matching text to a dedicated section and clarified matching rules; described implementation notes regarding server interpretation of archiving preferences and conversation tracking. (at/psa)

Version 2.1 of XEP-0085: Chat State Notifications has been released.

This document defines an XMPP protocol extension for communicating the status of a user in a chat session, thus indicating whether a chat partner is actively engaged in the chat, composing a message, temporarily paused, inactive, or gone. The protocol can

The changelog is:

Clarified that any state change is allowed. (psa)

Version 0.1 of XEP-0274: Design Considerations for Digital Signatures in XMPP has been released.

This document discusses considerations for the design of Digital Signatures in XMPP, including use cases and requirements. The document also discusses various ways XML Digital Signatures could be used in XMPP.

The changelog is:

Initial published version as accepted for publication by the XMPP Council. (psa)

Version 0.1 of XEP-0273: Stanza Interception and Filtering Technology has been released.

This specification defines an XMPP protocol extension that enables a client to exercise control over the XML stanzas it will receive from the server by instructing the server to intercept and filter inbound stanzas.

The changelog is:

Initial published version as accepted for publication by the XMPP Council. (psa)

Version 1.7 of XEP-0080: User Location has been released.

This specification defines an XMPP protocol extension for communicating information about the current geographical or physical location of an entity.

The changelog is:

Added element. (psa)

Version 1.1 of XEP-0256: Last Activity in Presence has been released.

This specification defines a way to use the Last Activity extension in XMPP presence notifications.

The changelog is:

Added use case for initial presence. (psa)

Version 2.0 of XEP-0203: Delayed Delivery has been released.

This specification defines an XMPP protocol extension for communicating the fact that an XML stanza has been delivered with a delay, for example because a message has been stored on a server while the intended recipient was offline or because a message is

The changelog is:

Per a vote of the XMPP Council, advanced specification from Draft to Final; also addressed a security concern about forged timestamps that was provided during the Call for Experience. (psa)

Version 2.3 of XEP-0077: In-Band Registration has been released.

This specification defines an XMPP protocol extension for in-band registration with XMPP-based instant messaging servers and other services hosted on an XMPP network (such as groupchat rooms and gateways to non-XMPP IM services). The protocol is extensibl

The changelog is:

Clarified that fields for "first" and "last" in fact always represent given name and family name, respectively. (psa)

Version 1.3 of XEP-0055: Jabber Search has been released.

This specification provides canonical documentation of the jabber:iq:search namespace currently in use within the Jabber community.

The changelog is:

Clarified that and elements in fact always represent given name and family name, respectively. (psa)

Version 0.1 of XEP-0272: Multiparty Jingle (Muji) has been released.

This specification defines an XMPP protocol extension for initiating and managing multiparty voice and video conferences within an XMPP MUC

The changelog is:

Initial published version as accepted for publication by the XMPP Council. (psa)

Version 2.0 of XEP-0202: Entity Time has been released.

This specification defines an XMPP protocol extension for communicating the local time of an entity, including the time in UTC according to the entity as well as the offset from UTC. The time format itself conforms to the dateTime profile of ISO 8601 defi

The changelog is:

Per a vote of the XMPP Council, advanced specification from Draft to Final. (psa)

A few days ago, our server had a maintenance restart to upgrade the ejabberd software running there. Moreover, we have installed ejabberd module for xmpp ping support. This seemingly negligible change has some important consenquences, which we would like to elaborate a little about.

XMPP Ping

What's this XMPP Ping all about?

For a long time we were struggling with this bad user experience, waiting for a possible solution. Now it's here: it's called XMPP Ping.

Disadvantages

• Shorter timeout: Before the XMPP ping it was possible for your TCP connection to survive for several minutes, with the devices keeping the messages on both sides safe. It will likely be possible only for shorter periods of time now.
• More bandwidth: Many mobile users are concerned about increase in bandwidth usage. Our early estimation suggests it's not that big issue, it's only about 180 bytes a minute. And that's without compression and when you're not sending any other data. If you still thinks that's too much, please tell us!
• Problems with old and/or broken clients. There are some versions of some clients which don't behave according to „XMPP Core“: http://xmpp.or­g/…rfc3920.html specification by not replying to the IQ queries. After five years since the publication of the XMPP specification, we deem it fair to consider all non-compliant clients to be broken or buggy. Users of these clients experience frequent reconnects and should consider upgrading their clients to newer versions. If your client is affected and you can't upgrade for some reason, please contact us in support MUC room jabber@conf.ne­tlab.cz (web interface).
• Clients we know or think to be affected: CenterIM (there's a patch), Psi 0.10 and older, some versions of Pidgin. Chatopus (for Palm OS), IM+ (for iPhone), MUCkl, Kopete (at least 0.12.7 doesn't work, at least 0.70.90 works), Sameplace, SIM, AQQ, Konnekt, Spik, Trillian. We try to contact authors of affected software if necessary. Please tell us if you think this list is wrong or incomplete, the experience for users of the same client seem to differ.
• If you find any bug you think could be related to the upgrade, please don't hesitate to contact us in MUC room jabber@conf.ne­tlab.cz (web interface).
• There is still some delay during which the messages can be lost in the worst case scenario.

Advantages

• You will now find out in a matter of a few minutes that your buddy has some connectivity problems and is offline
• When your connection breaks, you don't have to worry about hanging online for thirty minutes and losing messages anymore

Roster versioning

Other stuff

For some reason, the x64 build was broken. Let me know if it works again.

Another fix is related to the servers that use ping functionality to determine if the client is alive. In the previous build, there was no answer to the ping request, so the client was disconnected after specific idle time.

Download

Download x64