Planet Jabber

Process One: TextOne for iPhone, with photo sharing!

Nicolas Vérité — Thu, 02 Sep 2010 08:51:36 +0000

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

Thiago Rocha Camargo: Yet about Google Call

Thiago Camargo (noreply@blogger.com) — Tue, 31 Aug 2010 19:59:58 +0000

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.

Thiago Rocha Camargo: Google Call over Jingle with a SIP Gateway on their XMPP Server

Thiago Camargo (noreply@blogger.com) — Fri, 27 Aug 2010 07:54:33 +0000

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:

Ignite Realtime Blog: Openfire 3.7.0 beta has been released!

Ignite Realtime Blog (communityadmin@igniterealtime.org) — Thu, 26 Aug 2010 21:05:39 +0000

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.

Ignite Realtime Blog: The State of the Ignite Realtime Community

Ignite Realtime Blog (communityadmin@igniterealtime.org) — Thu, 26 Aug 2010 18:00:26 +0000

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!

Google Talkabout: Call phones from Gmail

Jason (noreply@blogger.com) — Thu, 26 Aug 2010 17:52:27 +0000

(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

Thiago Rocha Camargo: Google Call on GMail

Thiago Camargo (noreply@blogger.com) — Wed, 25 Aug 2010 18:39:55 +0000

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.

Ignite Realtime Blog: XIFF 3.0.0 has been released!

Ignite Realtime Blog (communityadmin@igniterealtime.org) — Tue, 24 Aug 2010 20:24:20 +0000

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!

Dave Cridland: Violating Layers

dwd — Tue, 24 Aug 2010 08:29:07 +0000

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:

In abstract terms, the layers exist, and are reusable. Thus generic TLS and SASL libraries can, and do, exist, and applications can use them.
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).

Remko Tronçon: Swift 1.0-beta6 released

Remko Tronçon — Mon, 23 Aug 2010 19:54:58 +0000

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.

Ignite Realtime Blog: Tinder 1.2.2 has been released

Ignite Realtime Blog (communityadmin@igniterealtime.org) — Sun, 22 Aug 2010 06:39:56 +0000

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

Peter Saint-Andre: Administrivia

stpeter — Fri, 20 Aug 2010 03:23:28 +0000

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…

Google Talkabout: Use Linux? Now you can video chat too

Jason (noreply@blogger.com) — Fri, 20 Aug 2010 00:55:01 +0000

(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

Process One: Tsung 1.3.3 has been released

Marek Foss — Thu, 19 Aug 2010 16:29:32 +0000

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

Peter Saint-Andre: The Value of Friendship

stpeter — Wed, 18 Aug 2010 03:26:35 +0000

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!

Tobias Markmann: GSoC '10: Final Report

Tobias Markmann — Tue, 17 Aug 2010 10:58:33 +0000

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.

Peter Saint-Andre: A Book Idea

stpeter — Fri, 13 Aug 2010 02:33:20 +0000

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…

Tobias Markmann: GSoC '10: New Join Dialog Finished

Tobias Markmann — Sun, 08 Aug 2010 14:36:47 +0000

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.

Tobias Markmann: libidn vs. ICU benchmark in string prepping

Tobias Markmann — Sat, 07 Aug 2010 22:41:02 +0000

Due to Waqas's asking for months now I've finally got around and made some benchmarks on two string prepping libraries. The one being libidn, as far as I know most XMPP servers use this and the other being ICU by IBM.

libidn is LGPL licensed and ICU is MIT licensed.

Current XMPP standard says that every JID must be string prepped so if you don't want to cache because of memory reasons your string prepping routines are called quite often. It turns out ICU is much faster than libidn. For this benchmark I tested a couple of strings and let them go through nameprep, resourceprep and nodeprep profiles via string prepping.

The result is that ICU is about 60 times faster in string prepping. Version of libidn being 1.15 and of ICU being 4.2.0.1.

The source code package of the benchmark is attached to this node. It falls under GPLv3 license.

Dave Cridland: In Memoriam Google Wave

dwd — Thu, 05 Aug 2010 09:38:43 +0000

So. Farewell
Then
Google Wave.

Interesting
research project.

And much-hyped product.

Yes. You popularized
Operational Transform.

Yet ignored
the practical problems,

Of fork lift upgrades.

[Guest post by E. J. Thribb, (17½)]

Dave Cridland: iPhone4, IMAP, Lemonade, and more

dwd — Wed, 04 Aug 2010 10:04:45 +0000

The blog post that we did at Isode, IMAP Enhancements in iPhone OS Update (iOS 4), a little while ago, sketched over the surface of why Lemonade is still quite a handy thing (and perhaps explains why not only Apple, but Nokia, too, are still developing new Lemonade functionality).

Take ESEARCH. This was my first RFC, so perhaps I’m biased, but in the “old days”, it was aimed as a simple domain-specific compression mechanism to allow clients to obtain the same results as SEARCH itself but in a more compact form. We then threw in some additional magic, like MIN, MAX, and COUNT.

Now these days – unless you’re roaming at €3/MB, anyway – the numbers of bytes on the wire just isn’t that interesting. Until recently, when I upgraded my DSL line, my phone had more bandwidth than my workstation. Moreover, my phone is flat-rate (whereas now, my DSL isn’t, quite).

But what my workstation does have over my phone is that my phone does not have effectively unlimited power. If it’s pulling data at top-rate, it’ll last about 4.5 hours – a long time for a phone, too, but it’s an E71 with a chunky 1500mAh battery.

The way to avoid this drain isn’t just to not send data at full rate – sadly, that’s not nearly enough. You need to avoid sending data very much at all, and moreover, you want to keep packet sizes under 128 octets if even remotely possible, to keep the radio in the much cheaper FACH, rather than more expensive DCH, modes.

And that’s where ESEARCH comes in. By using a very effective domain-specific compression, then a large number of results can be transferred in a very small space – often, in fact, enough to fit in under 128 octets, if you’re lucky.

In fact, much of Lemonade works well like this – IDLE can send notifications about new mail and flag changes in a small amount of space, letting the device bring the radio up to fetch the content for many notifications all at once when it’s convenient. CONDSTORE and QRESYNC help to allow a full resync of a mailbox to squeeze in under the thresholds.

Although many of the design criteria were a bit different to the criteria for effective use of 3G, it turns out they’re sufficiently compatible that Lemonade is not only as relevant as it ever was for mobile email, it’s actually gaining importance fast. And, of course, that shows in the increased support in devices.

Alexander Gnauck: a short MatriX development update

gnauck — Wed, 04 Aug 2010 10:01:55 +0000

there were no blog posts for a while because I was too very busy with coding.
I released MatriX 1.3 for .NET some days ago. This release includes many new features.
To name only some of the latest updates:

SASL EXTERNAL
SASL SCRAM-SHA-1
file tranfer control
XPath filering
roster versioning
…..

Yesterday I successfully compiled and tested MatriX on Windows Phone 7. MatriX for Windows Phone will be the next product to complete the MatriX series released very soon.
If you plan to develop XMPP apps for WP7 or need a XMPP layer for WP7 feel free to contact me.

Process One: ejabberd 2.1.5 and exmpp 0.9.5 bugfix releases

Jérôme Sautret — Tue, 03 Aug 2010 15:44:29 +0000

We are pleased to announce the bugfix releases ejabberd 2.1.5 and exmpp 0.9.5.

Regarding ejabberd 2.1.5:

The main changes are:

Erlang/OTP R12 support fixed
Erlang/OTP R14A support added
OpenSSL 0.9.8 or higher is required
BOSH: New optional connection attribute process-delay
C2S: Don't ask for client certificate when using TLS
C2S: Inform client that SSL session caching is disabled
CTL: Fix problem when FIREWALL_WINDOW options for erl kernel were used
CTL: Some systems delete the lock dir; in such case don't use Flock at all
Caps: Support all the hash functions required by XEP-0115
Config: Fix typo in --enable-transient_supervisors
Config: New configure option: --enable-nif
Extauth: Support parallel script running
MUC: Allow admins to see private rooms in disco
ODBC: Correct handling of SQL boolean types
ODBC: Discard too old queued requests (the caller has already got a timeout)
ODBC: Fixes wrong SQL escaping when --enable-full-xml is set
ODBC: Use ets instead of asking supervisor in ejabberd_odbc_sup:get_pids/1
Pubsub: Enforce disco features results
S2S: When logging s2s out connection attempt or success, log if TLS is used
Shared Rosters: When account is deleted, delete also member of stored rosters

Release Notes

Check the Release Notes for a more complete list of changes:
http://www.process-one.net/en/ejabberd/release_notes/release_note_ejabberd_2.1.5

If you upgrade from ejabberd 2.0.5 or older, read carefully the release notes of ejabberd 2.1.0 too, because there were several changes in the installation path and the configuration options.

Links

The list of solved tickets since previous version is available on ProcessOne bug tracker:
http://redir.process-one.net/ejabberd-2.1.5

ejabberd 2.1.5 is available as source code package and binary installers for Linux 32 bits, 64 bits, Mac OS X Intel, and Windows:
http://www.process-one.net/en/ejabberd/downloads

Regarding exmpp 0.9.5:

Brief summary of changes:

Add method to retrieve underling connection properties
Configurable Zlib support
Fix BOSH that didn't work
Modify exmpp_component to use exmpp_socket instead of exmpp_tcp
Negotiate zlib compression before OR after SASL
Raise requirement to Erlang/OTP R12B-5
Replace calls to OTP module ssl_pkix with public_key
STARTTLS support
Session enhancements
Stream compression support for session

Links

exmpp home page:

http://support.process-one.net/doc/display/EXMPP/ or easier to remember: http://exmpp.org/.

Download exmpp 0.9.5 source code package from:

http://download.process-one.net/exmpp/

You can also check the ProcessOne Labs page:

http://www.process-one.net/en/labs/

Tobias Markmann: GSoC '10: New MUC Join Dialog

Tobias Markmann — Fri, 30 Jul 2010 21:41:41 +0000

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

I've designed a new dialog for Psi which should ease the process of joining a room. The new dialog's features include:

all sources of existing rooms in a single dialog
allow entering a JID of a room manually
select multiple rooms from server room list, history and bookmarks and join them at once

Currently I'm hammering out the last couple of models for the server room list and bookmarks/history views. To round up this small post, here a screenshot of the dialog:

Tigase Blog: The longest running XMPP service

kobit — Tue, 27 Jul 2010 18:56:52 +0000

I wonder what is the longest running XMPP service without a restart.

I watch a few servers running Tigase but then I restart them from time to time for software update with new features or bug fixes.

One of them is im.flosoft.biz which runs on quite old Celeron 1.33GHz machine with 200MB memory. Serves approximately 800 online users and works well for 75 days already without a restart. This is a development version of the Tigase 5.1.0 branch but indeed, Florian pushes me to release it as another stable version.

I have found however an absolute winner in this 'competition'. The last time I checked it earlier today the Tigase uptime time was: 657 days, 6 hours, 53 mins, 21 secs. This is a service running on MS Windows machine for online gaming website and most of the user connections are web clients connecting via Bosh. It is still running and working well!

I have also received a few other reports from people successfully running Tigase, as they say for 2 years without restart. If you have any specific data, number of days, the software version, please add a comment to this article. I would like to hear about your experience with long-running Tigase server.