Ignite Realtime Blog

New open source plugins with enterprise features are now available

dombiak_gaston — Tue, 13 May 2008 23:52:15 GMT

It took us some time but we finally made it. The Enterprise Edition plugin has been broken into smaller open source plugins as mentioned in the Turning Openfire Enterprise into an open source product blog post.

The new plugins can be found here:

Monitoring Service (released on Apr 24, 2008)
Fastpath Service (released on Apr 24, 2008)
Clustering Plugin (released on May 6, 2008)
Client Control (released on May 13, 2008)

With these new plugins the total number of official open source plugins is now 17. If we add the clustering plugin that is commercial and the 3 beta plugins that includes the popular Red5 plugin the total number of plugins comes up to 21. Finally, more plugins can be found in the Non-Jive Openfire Plugins document.

Enjoy,

The Openfire Team

Open-Even-More-Fire 3.5.1 Released!

jadestorm — Fri, 25 Apr 2008 02:22:16 GMT

We are pleased to announce the release of Openfire 3.5.1, now with even more openness! This release represents the first stage of the Enterprise plugin split into open source plugins. We're very excited to be able to provide these to everyone for free, and seeing what the community does with them, both in terms of contributed code and use case scenarios. So lets talk about some specifics.

New Plugins!

Monitoring: Adds support for server statistics and chat archiving and reports.
Fastpath: Support for managed queued chat requests, such as a support team might use.

These are the first two pieces of the open sourced Enterprise plugin. Client management is coming very soon, as is clustering. SparkWeb will also be released tomorrow as a separate product. So you might be wondering, hey, why is there an Openfire Enterprise 3.5.1? Well, due to the lack of all of the plugins being available right now, we've provide 3.5.1 for existing enterprise customers to make use of. It includes some important clustering fixes though! (as will the clustering plugin when it is release)

Important, Seriously, Pay Attention, Read This

If you install the Monitoring and/or Fastpath plugin, make absolute sure that you read the readme first! There are included instructions for how to migrate your database from the Enterprise plugin to the new plugin database tables. If you have ever run the Enterprise plugin or the old Fastpath plugin before it was integrated with Enterprise, make sure you don't forget this or you will be unhappy!

Big Connection Manager Improvements

The connection managers have been updated to bring HTTP binding up to date and a couple of library upgrades that include a number of improvements. It is important to note though that the conf/manager.xml file has been updated and you will need to update yours as well. The new http binding section that you will need to add is described here.

Ok Fine, Where Do I Get It?

You can download Openfire 3.5.1 here.
You can see the entire changelog here.
You can view the documentation for 3.5.1 here.
Plugins can be downloaded from the admin console or here.

Openfire is Lookin' Hot!

jadestorm — Tue, 08 Apr 2008 00:40:18 GMT

As you may have already seen, Openfire 3.5.0 was released today alongside it's good friend Clearspace 2.0! We are excited to put out this release as it strolls alongside a number of new announcements, new features, and is sporting a brand new outfit in the form of a new look and feel for the admin interface.

Now, in light of the announcements regarding the Enterprise plugin becoming open source, you may be wondering why you can see an updated Enterprise plugin available. We are providing this plugin for our existing enterprise customers until the separate split-up plugins are released. Those of you waiting for the open source releases, please stay tuned!

For our Clearspace customers, this new version of Openfire integrates at a much more intense level than before. Instead of simply providing presence to Clearspace, and requiring you to point both Clearspace and Openfire at something like LDAP to have the same login setup, you can now have Openfire speak directly to Clearspace. It will pull it's users and groups, as well as pass authentication through Clearspace. Setup is a breeze, as you have one screen of setup in Clearspace and one screen of setup in Openfire and you are done. And we're not stopping there. Future releases will include even more integrations between the two!

Is Clearspace integration the only new thing in Openfire 3.5.0? Of course not! We've now got the ability to disable accounts, security audit logs for admin events, easy to take advantage of invisibility, and did I mention the pretty new admin interface? We went over a lot of these new features in a previous blog post, so I won't bore you with a complete rehash of all of them.

One word of warning, due to the nature of CSS not wanting to easily refresh itself, you may need to shift-reload in your browser for the new admin console to look correct. And don't forget to update your plugins after upgrading to 3.5.0! Some of them are affected by API changes! (specifically: User Search, IM Gateway, MOTD, and SIP)

This has been a very exciting day for us here at Jive and we hope exciting for you as well!

You can download Openfire 3.5.0 here.
You can see the entire changelog here.
You can view the documentation for 3.5.0 here.
Plugins can be downloaded from the admin console or here.

Turning Openfire Enterprise into an open source product

dombiak_gaston — Mon, 07 Apr 2008 20:25:50 GMT

We're in the process of making the Openfire Enterprise module Open Source (see Matt's blog). The Enterprise module provided several areas of functionality that were available as a single plugin. A quick list:

Reporting - a dashboard with statistics about server load, user sessions, chats, groupchats, etc. and support for executing reports.
Chat archiving - support for tracking conversations taking place on the server. Both one-to-one and groupchat conversations can be archived.
SparkWeb client - the web-based version of the successful Spark client.
Clustering - support for running several machines hosting the same domain. Thus adding fail-over and better scalability of the server.
Client control - controls whether certain features are available or not in the Spark client (e.g. file transfer, broadcast, groupchat, etc.). Moreover, it is also possible to specify which clients can connect to the server, push new versions of the Spark client and populate rosters with groupchat bookmarks.
Fastpath - provides rich web-based click-to-chat functionality with support for requests to the best available operator in queues. It's ideal for web-based realtime helpdesks.

Turning a commercial product into an open source product implies more effort that one would initially estimate. Therefore, we are going to break this process in two stages. During the first stage we will offer several plugins that will include the features listed above (with the exception of clustering). Our clustering solution relies on a commercial product and will not be made Open Source. The output of the first phase will be:

Reporting and Chat transcripts plugin - this plugin will include the reporting and chat transcript functionalities
SparkWeb - SparkWeb will be available as a separate project and not as an Openfire plugin
Client Control plugin - the ability to manage clients will be available as an Openfire plugin
Fastpath plugin - the Fastpath application will be composed of an Openfire plugin and the WebChat plugin. The webchat.war plugin can be deployed to Openfire as a plugin or can be deployed to your application server (e.g. Tomcat) of choice.

The second stage of this process will include:

Reporting and chat archiving - This functionality was available as a plugin in stage one. For stage two we will evaluate making it part of the server itself.

Stage one is planned for April 27th, 2008. That means that two weeks from now we will have most of the functionality included in the enterprise edition available as open source plugins. No clear date has been assigned to stage two but it should take place a few months after stage one.

Openfire Enterprise is becoming Open Source

matt — Mon, 07 Apr 2008 16:13:46 GMT

I'm happy to announce that we're making most of Openfire Enterprise Open Source! First, a bit of context: for the past couple of years, one way that we (Jive Software) have monetized our Open Source work on Openfire and the other projects on igniterealtime.org has been through Openfire Enterprise. Openfire Enterprise addresses the Enterprise Instant Messaging (EIM) market by adding rich reporting, archiving, and control features on top of Openfire. Since we released Clearspace last year, Jive has become super-focused on social collaboration and communities. That's pretty different than the EIM market and it's become increasingly difficult for us to serve both markets with our limited resources. Instead, we want to focus our Openfire work on real-time social and collaborative features and monetize our Open Source efforts through Clearspace integrations.

Existing Customers

Discontinuing a commercial product is always a difficult decision and one of our biggest concerns is not leaving existing customers in a lurch. We'll continue to provide support for Openfire Enterprise through existing support contracts and believe that making the Enterprise components Open Source is the best possible outcome for customers given the options. We remain strongly committed to the Openfire project and are pretty excited about what's coming in the future.

A Few Details

Gato will have a follow-up blog post with a lot more details about what we're releasing as Open Source and how, but I wanted to highlight two items. Sparkweb is our flex-based web client based on XIFF and will become Open Source. The client is already very feature rich and polished, and we're actively making many code improvements to it, as it's a shared code base with the real-time client features we're building into Clearspace. Second, the clustering functionality in Enterprise will not be made Open Source. Part of the reason for this is that we use a third-party commercial library for clustering that can't be Open-sourced.

Let's Go Get 'em

One of our hopes with this move is that the last possible objection to deploying XMPP-based instant messaging at every organization in the world is now removed. Now, everyone will have access to an open standards solution that satisfies all the needs of IT departments... for free. We think that's great news for the community and getting our technology deployed even more widely is good for Jive Software as well. We hope you'll join us in spreading the word.

Openfire Success Story: Saving Lives with Instant Messaging

dawn — Sun, 23 Mar 2008 17:42:00 GMT

Most every day, the United States is impacted by high impact weather events. These events range from hurricanes to tornadoes to winter storms. The National Weather Service (NWS) is tasked with forecasting and warning about these high impact events to save lives and protect property. The process of alerting and mitigating these high impact events involves the close collaboration of partners in the broadcast media who are federally mandated to relay weather alerts to the public, and emergency management who organize and respond to weather threats. Historically, these groups have operated on islands during weather events with one way communication systems providing data.

Starting in 2000, some parts of the country started experimenting with Instant Messaging technologies to bridge these islands during high impact weather. At the time, these involved the use of proprietary protocols and clients in an ad-hoc manner. In 2005, a group of interested parties in Iowa started looking for a scalable, secure, and open source / standards system that could provide the level of flexibility necessary to support the real time collaboration of broadcast media, the NWS, and emergency management. This effort was called IEMChat.

After a perusal of IM technologies, IEMChat implemented XMPP and choose the Openfire server to power the project. Openfire's ease of installation, functional administrative console, stability, and active support community has provided the foundation for the IEMChat project to flourish. In a short 2 years, IEMChat's use has spread to over half of the country with 85+ NWS offices, 450+ broadcast media outlets, and hundreds of local emergency managers participating. IEMChat has been put to use in recent high impact weather events such as the Super Tuesday tornado outbreak that ravaged the states of Arkansas, Tennessee, Kentucky and other states.

Daryl Herzmann, IEMChat's primary developer who is based at Iowa State University, says that Openfire has made the project possible. “Openfire provides us a robust and stable XMPP feature set supported by a fantastic community on Igniterealtime.org. The developers' active support on the web forums and weekly chat has been outstanding and shown their commitment to improve Openfire to meet the needs of the community.”

A huge thank you to Daryl for all of his contributions to the Ignite Realtime community and for providing us with details about this great Openfire success story!

Openfire 3.5.0 Release Candidate 1 Now Available

jadestorm — Wed, 12 Mar 2008 02:13:09 GMT

We are pleased to announce the availability of Openfire 3.5.0 RC1 off of the beta downloads page, along with Openfire Enterprise 3.5.0 RC1 off of the beta plugins page. The official release is slated for late March or early April, depending on when the official release date of Clearspace 2.0 is. There are a number of new features and bug fixes in this release. A couple of the highlights are as follows:

New Security Features

3.5.0 includes two new improvements to the overall security of Openfire. One is a new lock out manager, which allows administrators to lock out (disable) accounts, thereby preventing them from logging in. This can be for a period of time, or "forever". Another new security feature is a new auditor for actions performed in the admin console. This will allow you to keep track of what has changed in your server's configuration, and who performed the change.

For more information, see: Big Brother In 3.5.0

Invisibility

3.5.0 includes the ability to connect without sending an available presence. This provides an easy means for being "invisible" to other XMPP users, and visible specifically to those you intend on speaking to. This support needs to be built into clients or programs that you might be using to be of direct use, but the capabilities are now available!

For more information, see: Playing Casper in 3.5.0

Clearspace Integration Improvements

Clearspace 2.0 and Openfire 3.5.0 can now work together harmoniously to share users, groups, vcards, presence, and various other functionality. Not only that, but Clearspace and Openfire will configure their integration in a semi-automatic mode, where you provide a minimal configuration of Openfire and Clearspace and they take care of the rest! You will see a new option during initial setup where you can choose Clearspace integration that will lead you through the steps. Please note that Clearspace 2.0 or higher is required for this integration to function properly!

For more information, see: Clearspace 2.0 Public Beta

Performance Improvements

A number of improvements have been made to the overall performance of Openfire in 3.5.0. An important index was added to one of the database tables that improves roster loading speed by a large degree. The networking framework used for external component connections has also been replaced with MINA, drastically improving the performance of external component connections.

Fixed Double-Byte Character Problems

3.5.0 includes fixes for double-byte characters not being handled correctly. This should solve a number of problems with messages that include chinese characters, or other double-byte character encodings.

SparkWeb Enhancements

SparkWeb 3.5.0 includes a number of reliability improvements, especially with http binding, and also improved support for MUC functionality, such as moderation controls (kick/ban/etc).

New Admin Console Look and Feel

3.5.0 sports a brand new look and feel for it's administrative console. Those who have used Clearspace before will be familiar with it, as it's mirrored in concept and general look after Clearspace's administrative console. The new menu layout is much less cluttered than before, and should involve a lot less scrolling down the page to find what you want. Warning: Due to changes in the CSS files, and browsers wanting to hold onto CSS files for dear life in their caches, you will likely need to hit shift-reload on your browser when visiting the new admin console.

And more!

You can view the full changelog here.
You can view the updated documentation (javadocs et al) here.
Plugin updates required for Openfire 3.5.0 are available on the betaplugins page.
The specific plugins that need to be updated are:

IM Gateway
User Search
Enterprise
MOTD
SIP

Happy testing and please let us know of any issues you run into by posting in the Openfire support forum!

Thanks!
-The Openfire Team

Release date for 3.5.0 moved

jadestorm — Tue, 04 Mar 2008 18:06:20 GMT

Our original release date for Openfire 3.5.0 was slated for this Thursday, March 6th. However, it is important that this release be available alongside Clearspace 2.0, whose release date is slated for the end of March or early April. As a result, we will be holding off the Openfire 3.5.0 release until it can be released at the same time as Clearspace 2.0. We're very excited about the improvements in the ease of integration between Openfire and Clearspace, as well as the number of other new features and fixes coming in 3.5.0, and we believe it will be worth the wait! =) None-the-less, we apologize for the delay!

Openfire is flying off the virtual shelves!

jadestorm — Fri, 29 Feb 2008 15:17:00 GMT

We are very pleased to announce that Openfire has breeched one million downloads (not including downloads not from our site)!

We couldn't have done it without you all, the Ignite Realtime community! (well of course not, we needed -someone- to download it ) It's always fun to watch a milestone come and go, and take a moment to reflect, so I thought I would take a little bit to talk about Openfire's history, and even a little about my own personal history with it.

When I first found what is now called Openfire, it was somewhere in early 2006. At the time it was called Jive Messenger and I was the lead developer of PyAIMt and PyICQt and was told that my transports didn't work well with Jive Messenger. It wasn't long before I 'fell in love with' Jive Messenger and around the middle of 2006, I began work on the IM Gateway plugin.

Not long after, I watched Jive Messenger turn into Wildfire, run into a naming conflict, and then turn into Openfire. As it turned out, Openfire became probably the most appropriate name, as it better reflected the open nature of the product, and was really catchy!

So approximately two years after I first became aware of Openfire, we've hit one million downloads! That's pretty impressive for a server product! Over those two years we've witnessed so many milestones in the world of XMPP. One might even call it a "boom time" for XMPP at this point. So lets all have a drink to Openfire's one millionth download, and to XMPP everywhere! And also, we at Jive will be having a virtual toast to the Ignite Realtime community, and thank you for all of your involvement! Happy road to two million!

Big Brother In 3.5.0

jadestorm — Wed, 27 Feb 2008 23:55:11 GMT

In Openfire 3.5.0, we have added two new features to address security concerns! One of these features is security auditing. We've had packet auditing in Openfire for quite some time now, but that only addresses communication amongst users of your Openfire server. What the security auditing functionality provides is logging of administrative activities performed via the Admin Console. Any action you perform that changes the server's configuration, adds, removes, or edits users and groups, or any number of things, will be logged into the security auditor database. On top of that, we've implemented this via provider functionality just like the user providers. What this means is that if you have a custom place you'd like to be logging audit events, or perhaps wanted to write some sort of sms event triggering implementation, you can do that and plug it into the existing infrastructure.

Beyond the security auditing, we have implemented the ability to lock out (disable) accounts. By default, you can lock out accounts for certain periods of time, use delayed starts, or lock them out until manually unlocked. You will find the option to lock out a user while viewing their account in the admin console. Just like with the security auditor, the implementation uses a provider, so that you can implement whatever source you might have for disabled accounts.

The APIs should be pretty flexible and enable developers to build whatever solutions they might need around these two concepts! I will be posting some more details in the Openfire Dev forum in the near future to go over some of the details and other API improvements. We hope that you will enjoy the new functionality when 3.5.0 is released!

Playing Casper in Openfire 3.5.0

dombiak_gaston — Tue, 19 Feb 2008 20:39:59 GMT

The next major release of Openfire is going to be 3.5.0 and it will be released on March 6th. Daniel and I are very happy with this new release since it has lots of new features and improvements. Today I will explain how you can be connected but invisible to all or some users. This has been a very popular request in Openfire and in XMPP in general.

A few XMPP extensions were created for invisibility using different strategies (and may be goals). Some of them focused only in blocking your presence to other users while others were blocking incoming/outgoing presences, messages and IQ stanzas. But they have something in common that jeopardized their success. In a nutshell, they not only required server side changes but also client side changes thus making it hard for a user to find a server and a client that supports them.

As of Openfire 3.5.0 there is a very easy way to be invisible and at the same time be able to maintain a one-to-one chat, a group chat or appear visible to the users of your choice or gateways of your choice. The best part of it is that we are not relying on any XMPP extension but just using the XMPP RFC core.

Usually XMPP clients follow these steps while logging in:

Connect to the XMPP server
Secure the connection with TLS
Authenticate with the server using SASL
Send available presence to the server indicating that the client is now publicly available (e.g. <presence><priority>1</priority></presence>)
Request their roster

The forth step is actually optional so if clients do not send an available presence then they will be connected to the server but will not appear available/online to other users. Unavailable users cannot get messages from other users unless they made available to them.

When the user decides to appear as online to someone in particular he can send an available presence to that user (e.g. <presence to='joe@myserver.com/Spark><priority>1</priority></presence>). Being available to a user means that the user will see you online and you can now chat with that user.

Users that are publicly unavailable can also join a room and have a groupchat. However, if the room is not anonymous (i.e. real JIDs are sent to room occupants) then the other users will know that you are connected and chatting. But probably you won't care about that unless you wanted to chat without anyone knowing that you are you.

Currently our Spark and Sparkweb clients are not able to join in invisible mode but implementing invisibility this way should be a lot less work for clients than implementing some XMPP extension.

Installers, Installers, Everywhere!

jadestorm — Thu, 17 Jan 2008 15:09:43 GMT

One of the things you may have noticed that appeared in the 3.4.3 release of Openfire is a couple of new installers, and some improvements to existing installers. Oddly enough, building installers can be one of the more difficult tasks a developer has. Simply putting out a tarball or zip file is easy, but it's not exactly the most pleasant thing to deal with from an administrator perspective. In the process of creating installers, you often find yourself fighting with differing standards between OS distributions, or different architectures altogether. That said, typically once you have created the installer, there's not much to do with it after, so it's generally a one time cost, so to speak, and the benefits far outweigh the time spent!

In an effort to make Openfire as easy to install as possible, we added official Debian and Solaris packages. Yes, I am aware the Solaris package is listed under Linux right now, but please ignore that for now. Are we stopping there? Not really. I'm not yet sure what other OS's we might be providing packages for at this point. FreeBSD is about the only other one I've seen a request for and there's a well maintained port (net-im/openfire) of Openfire already.

What we are investigating now is providing hosted repositories for the packages. Specifically, I'm looking at a Yum and APT repository at the moment. This would allow system administrators to point their repository configs at our repositories and be able to easily keep up to date. We are still working out the logistics of this, so stay tuned!

We're also investigating getting Openfire into more distributions. In other words, instead of having to come to our site to get Openfire, perhaps you could install it from a central Debian repository, or an extras cd, or something of that nature. There are a couple of possibilities in the works on that front, and a couple more I'd like to pursue.

So hopefully in the near future, it will be as easy as ever to get rolling with Openfire!

Your Certificate Survival Kit

dombiak_gaston — Sat, 01 Dec 2007 00:28:02 GMT

Many years ago when I started adding certificates management to Openfire I couldn't stop thinking how complex the certificate management topic was. Moreover, I thought that the lack of information regarding certificates management was on purpose as a way to keep them "secure".

Even though I do not consider myself an expert in security and certificates in particular, I think I finally understood the different ways certificates can be created, signed by Certificate Authorities (CA) and finally be imported into your application. Basically there are two ways for this to be achieved and fortunately the XMPP Federation through its CA services supports both of them.

Create your certificate and ask a CA to sign it

In this case you will create a certificate from the admin console of Openfire and then ask Openfire to create a Certificate Signing Request (CSR) that is sent to the CA. The Certificate Authorities (CA) usually has a web site that you can use to paste the CSR. If you are using the XMPP Federation services, choose the menu option Server Certificate (Without CSR generation). After the CA verified the certificate data and the data of the certificate issuer you will get a signed certificate that you will need to import into Openfire from the admin console.

The CA creates a certificate for you and signs it

In this case almost the entire process happens in the CA web site and administrators will need to import the signed certificated into Openfire. If you are using the XMPP Federation services, choose the menu option Server Certificate (With CSR generation) and then provide a pass phrase to create the certificate and its private key. After the data was validated you will receive a signed certificate. The last step to import the new certificate into Openfire is to paste the pass phrase, private key and signed certificate in the import certificate page in Openfire and voila.

As of Openfire 3.4.2 you will be able to choose the certificate management option that best fits you and follow the entire process from the admin console. You will be able to say bye bye to the cumbersome command line tools. If you are using Openfire 3.4.1 or older then only the first option is supported.

Jivin' Gateways and More!

jadestorm — Sun, 11 Nov 2007 18:25:04 GMT

You may or may not already be aware that I have been a full time member of the Jive family for a couple of weeks now! It's been quite interesting to see how different it is from my previous job in a university setting. It's been a lot of fun already and it's really exciting to have turned my favorite hobby into a career. =) My coworkers are great and I almost find myself wondering why I didn't do this earlier.

So what am I going to be doing? Well, the development of the IM Gateway plugin is part of my job now. We'll be setting solid goals and release dates instead of it being dependent entirely on my free time. That and Openfire are my main focuses. I'm really excited about playing a more direct role in Openfire development! One of my first tasks will be to improve the unix installers for Openfire. They have been lacking love for a while now and I have a strong unix background to bring to the table. In one of the next releases of Openfire we'll have improved packages, unix scripts, and better support for more operating system distributions. Overall, good things to come! =)

You may have heard that I have taken over as lead developer of Spark. It's been a long time since I have been involved in client development and I actually miss it. My very first XMPP related project was a client. Now, as you've heard from the Ignite Realtime post preceding this one, Spark is a low priority. My focus with it in terms of work with Jive is bug fixes, maintenance, and paying customer requirements. Beyond that, I'll likely be working on it on my own time when I need a change of pace. I am a Mac user primarily, so you may see more Mac focused fixes at first. If nothing else I'm going to make sure Spark is something I enjoy using, which coincides to a lot of things that the community has reported/requested anyway. I highly encourage folk who are interested to submit patches! The only caveat is that for patches of any size, I'll need you to sign contributor agreements, if you haven't already.

Now, since I'm involved in more than just the IM Gateway plugin now, I can't keep up with the forums as much as I did before. I try to spend some time each day looking over the forums, but with more than just the single forum, it's too much to keep up with entirely. Dawn is working hard on coming up with good ways to involve the community more and try to make sure things don't get missed! She has been speaking on this in the Jive Lounge, so please visit the lounge and contribute if you have some thoughts!

Anyway, I wanted to make sure folk understood that my role has changed and wave hi from within Jive! =) Any questions?

Openfire Unleashed

dombiak_gaston — Thu, 01 Nov 2007 00:06:32 GMT

Openfire is the award-winning instant messaging server known for its simplicity, elegance, performance and extensibility. With each new major release, scalability has been improved; however, being able to scale a lot without redundancy or high availability poses a risk to every connected user if the single server goes down.

After many months of work that risk is now part of the history. Openfire Enterprise 3.4.0 provides support for clustering. Clustering will let you run Openfire on several machines serving the same XMPP domain. Clustering can be enabled with just one click from the admin console. Machines running Openfire Enterprise will automatically meet between them to form a cluster. With clustering you not only get high availability but also improved scalability. In our internal load tests, we got more than half a million concurrent connections sending lots of packets in a cluster of just 2 nodes.

Another nice addition to Openfire Enterprise is SparkWeb. Users can now connect to the server and chat from your website. Read the SparkWeb: Next Generation blog post for more information.

On the open source side we also have excellent news. More than 30 new features and more than 30 bugs were fixed. Personal Eventing via Pubsub was added so you can now publish your geo-location, music you are listening to and let subscribers be alerted. From the admin console you can manage users roster. Moreover, it is now possible to retrieve photos from LDAP and use them as users avatars. The complete set of changes can be found here.

You can download Openfire from here. Openfire Enterprise can be downloaded from here.

Enjoy,

Openfire Team