We’re planning on migrating the community back-end for Igniterealtime.org from Jive Forums to Clearspace on Wednesday. I’m pretty excited about the change, but it will require a couple of hours of downtime on the site. I’ll post a more specific outage estimate in the forums as Wednesday approaches. If you’re interested in getting a preview of what the updated site will look like, check out http://beta.igniterealtime.org.
OSCON 2007 is wrapping up and it was a great conference. Yesterday I gave a talk about Jingle, an extension to XMPP (Jabber) that’s primarily used for VoIP. The slides are available on Slideshare (including a link to download the Powerpoint).
I wanted to let everyone know that Jive Software just launched a beta of Jivespace, our new developer community on dev.jivesoftware.com
This is the place where developers can collaborate around Clearspace, Clearspace X, and Jive Forums products. You will also notice that the Community tab takes you to an area for collaboration that is powered by our Clearspace X product. This developer environment is currently in Beta, so you may notice a few minor issues. Feel free to point them out in the Jivespace Lounge, and we will fix them as soon as we can!
This new developer community does not impact Ignite Realtime in any way. Collaboration on real time communication / XMPP related products will continue on igniterealtime.org, and there are no plans to change this. Jivespace just gives developers a place to collaborate on Jive Software’s other products.
The login information is integrated with our Jive store and Support forums on jivesoftware.com, so existing Jive login information (but not Ignite Realtime logins) should work on the new Jivespace site.
We’re making progress on the migration of the community from forums to Clearspace X. A beta version of the Ignite site using the new platform is available at beta.igniterealtime.org. Clearspace carries forward the discussion functionality, while also giving us blogging and wiki document features. The beta site is using a copy of the forums data from a couple of weeks back. Please poke around and feel free to post test data, then give us your feedback. When we do the final migration, it will be using the most recent real content.
Want to come to Portland for XMPP Devcon or OSCON without spending money on travel? Have a cheap boss who won’t foot the bill?
If you want Jive Software to pay for your travel, you just need to win the OSCON Trip Give-A-Way Contest by creating the best blog entry about how Clearspace, Jive Forums, Openfire and/or Spark have helped your organization. Your blog should be entertaining and creative while describing how you’ve used Jive software to make your organization better in some way.
All of the details and fine print can be found on the Jive Talks blog.
Like many other people I tend to use instant messaging on a lot of different workstations: at home, at work, on my notebook and sometimes from abroad using the Jeti Applet. With the current generation of mobile phones, even these devices offer decent support for IM.
This all works very well with one major drawback: the history of my chats is spread around different machines (or completely lost when using web based or mobile clients) and whenever I need to look up something it’s more often than not unavailable on the machine I am currently working on. This situation reminds me of the old days before I switched my email store to a central IMAP server and used POP3 for email download. With Instant Messaging becoming more and more important I feel the need for a similar central archive for my IM chats.
For Openfire there are some archiving features available in the enterprise edition and a few external open source plugins with similar goals. They are logging messages as they pass the server and provide a web interface for message retrieval.
This is already an improvement but still a bit off the solution I am dreaming of. I would really like to have the message archive integrated within my Jabber client just like they are now with the only difference being that the messages are retrieved from the server instead of the local filesystem.
It turned out that I am not alone with that vision. There is XEP-0136: Message Archiving a proposed XMPP extension for server side message archiving. The XEP supports configuration of which messages to archive, automatic and manual archving, encryption and message retrival.
Support for XEP-0136 by servers and clients is still in a very early stage, although the first version of XEP-0136 appeared three years ago. To overcome the hen and egg problem I’ve started working on “Open Archive” which already implements the basic features:
- Automatic Message Archiving
- Message Retrieval
So what’s next?
Well we must add support for XEP-0136 to the clients. A good point to start is Spark.
And of course we will add the missing features, manual archiving and preferences are on the agenda for upcoming releases.
Finally, XEP-0136 currently does not specify how to perform a server side search in the archive. Open Archive already supports searching but due to that limitation only through the Web UI. So we will start a discussion within the XMPP community on how this feature can be standardized and made available to clients.
Open Archive is available under GPL v2: Try it.
Jive Software has been providing free collaboration software to open source projects for a while, and we are now expanding this program to other software developer user groups (JUGs, etc.) We have also simplified the application making it easier for open source projects and user groups to get a free license.
The free license can be used with Clearspace, Clearspace X, and Jive Forums for use in open source projects and developer user groups. This is our way of supporting software developers working for non-commercial purposes. Collaboration is a critical part of most software development projects. Many developers devote time and energy to projects without any commercial compensation, and we want them to have tools that make it easier for them to collaborate. This is not a free trial. The licenses are free for as long as the project wants to use the software.
To qualify for a free developer license:
- The project or group must be related to software development.
- It must be primarily non-commercial.
- Open source projects must use an OSI approved open source license, have a publicly accessible code base, and have a publicly accessible application.
- User groups must have a public community.
- Note: non-profit or non-commercial projects unrelated to software development are not eligible for the free developer licenses.
Use our new, simplified online forms to apply:
I hope to see a bunch of projects take us up on this offer!
We (Jive Software) launched Clearspace X just about one month ago, our external community software product that combines discussions, wiki documents and blogging. [As an aside, we provide free Clearspace X licenses to Open Source projects.] So, why aren’t we using it here on igniterealtime.org yet? There’s lots of good excuses, but we’ve been hard at work on the migration and it will happen soon. What will the change to Clearspace X mean?
- The same discussions functionality we have with Jive Forums, but with an updated UI.
- Migration of the blog engine to the Clearspace platform (this will be fairly transparent).
- A rich new set of functionality around wiki documents. We’re already planning lots of great content.
We’re looking forward to the new features and to getting your feedback on them. I’ll post more migration details in the forums soon.
You may remember me asking for everyone’s help a few months back to vote for Openfire. We’re entered in the Enterprise Open Source Reader’s Choice Award in the “Best Open Source Product” category. The deadline for voting is May 31, which is just one week away. If you haven’t already voted, please visit the site to cast your vote. Note that the voting process started before the rename of the server, which is why you’ll see the old Wildfire name.
The good news is that we’re in the lead position with 198 votes. But other projects aren’t far behind and I’d be thrilled to solidify our lead and hit at least 250 votes. Thanks for your help!
After this many years, most web developers have become a little numb to how much Microsoft Internet Explorer is holding back the web. We whine about it, we drop by Position Is Everything to find the appropriate hack to use, and we go about our business. Recently, working on SparkWeb has really brought the issue back into focus for me.
Shortly before SparkWeb 1.0 came out, we realized that it wasn’t working in Internet Explorer 7… sometimes. There was no discernible pattern to the failures; some were on XP, some on Vista, some were one sub-version of 7, some were another. After a great deal of painstaking debugging I eventually tracked down the problem. XML support (and by extension the XMLHTTPRequest feature used in “ajax”) in Internet Explorer is provided by a system library, rather than built directly into the application. This wouldn’t be too bad, except different versions are installed on different systems. Currently MSXML3 and 6 are the best choices. 3 is incredibly widely deployed, and 6 is the latest and greatest. We chose 6… IE7 chose 3. Boom.
[Graph courtesy of Alan Foreman]
That issue is fixed now, but it reminded me again of just what we’re missing. Here’s a brief list of stuff that works in the big 3 (Mozilla, Safari, Opera), but not in IE6, and in many cases not in IE7:
- position: fixed
Useful for making navigation bars and such always available so users don’t have to scroll back up to them. Also allows for things like Eric Meyer’s beautiful ComplexSpiral design. This is fixed in IE7.
Part of the in-progress CSS3 specification, but still pretty well supported these days. It allows for painless rounded corners, without the crazy hacks we use now.
I’m slightly skeptical of the usefulness of this one, but it’s a pretty big deal to some people. IE will not accept XHTML unless it’s told that it’s HTML instead of XML. This leads to pages that have subtle hard-to-find bugs when switched over to real XML parsing.
This one “works” in IE6, but only through ActiveX. If the user has ActiveX disabled (say, for security reasons, as Microsoft did in IE7) then it will stop working. This is fixed in IE7.
- CSS child selectors
Generally useful in all sorts of layouts
- Translucent PNG images
Again, hugely useful. There’s a hack to allow them in IE6, but it can break a bunch of other things… as we found out when trying to use it in SparkWeb. Even in IE7 there are a number of nasty bugs involving this functionality.
- :hover on anything other than links
Useful for popup menus, button hover effects, tooltips, and any number of other things. This is fixed in IE7.
Basically every major browser gets this one wrong in some ways. I’ve found it’s best to just forget that the possibility exists and use inline styles instead.
- SVG and canvas
This is just a selection of major issues, there are many many smaller issues, many issues that have slipped my mind, and many places where IE isn’t the only browser messing up. Microsoft claims that they will be making a big push to catch up on compliance with modern web standards in Internet Explorer 8. Even if that’s true though, the legacy of stagnation from five years of IE6 will be difficult and time consuming to overcome.
However, there is some hope; People like Dean Edwards, Jack Slocum, the Prototype team, and many others are building libraries to work around browser issues and provide a common platform to build web applications on. Also, the newly re-formed HTML working group is pushing forward towards HTML5 with some wonderful people involved, including key participants from Apple, Google, Opera, Microsoft, and Mozilla. Unlike previous web standards efforts, the HTML process is open to anyone who’s interested. Ian Hickson has instructions on joining the process here
Have you made your reservations to attend XMPP DevCon and the O’Reilly Open Source Convention (OSCON) this July in Portland, OR? It may seem a bit early to be thinking about conferences in late July, but hotels will fill up quickly in Portland with so many events converging around OSCON (July 23-27). Not only are we planning DevCon for July 23-24, but Ubuntu Live will also be in town July 22-24.
Roughly twice a year, the XMPP community holds a DevCon event to discuss protocol changes, do interop testing, and to socialize in real life. The last event was in Belgium along with Fosdem in February. The February meeting included discussions about certification programs, file transfer issues, Jingle, protocol developments, end to end encryption support (extensions), personal event pubsub, message archiving, and more.
Discussion topics for DevCon in July will likely include continued discussion on many of the topics above plus spim prevention, simultaneous XML editing (for whiteboarding etc.), clarifications to rfc3920bis, and more. Any developers working on XMPP servers, clients, code libraries, or related applications are welcome to attend. Since many of you in the Ignite Realtime community fit into this group, it would be great to see you attend DevCon.
Jive Software will, of course, be out in full force for XMPP DevCon and OSCON, since they are right in our hometown of Portland, OR. At OSCON, I will be on a panel discussing the Art of Community and Matt Tucker will be leading a session called Jingle: Cutting Edge Open Source VoIP. Matt is also planning some cool stuff for DevCon. Last year during OSCON, we held a great party, BeerForge, and we plan to do something similar again this year!
We hope to see many Ignite Realtime community members at these events! It is a great way to meet some of the people face to face that we collaborate with over email, IM, and other online environments.
I don’t usually get annoyed by other blog entries in the XMPP blogosphere, but this one got my goat a bit: the claim that ejabberd is the most popular XMPP server (according to ohloh). Not only that, but their previous blog entry crowed about passing the 120,000 download mark. So, I thought it was time to set the record straight:
- Openfire is now the most popular XMPP server according to ohloh. Why the sudden change? Easy; I read the ohloh FAQ, which states that popularity is based on Yahoo page ranking. The Openfire project page on ohloh linked to a deep page in the ignite site (something that people would never link to). I simply copied ejabberd and made the page link be the main website. Sure enough, we’re now the top server listing.
- Openfire just passed 827,753 downloads.
- The igniterealtime.org discussion forums have 53,348 messages, compared to 4025 on the ejabberd site.
Anyway, my apologies for the pissing match, but we have to be willing to step up when directly called out. I do think it’s a great thing that there seems to be such vitality in the XMPP world.
Late last week we (Jive Software) released version 1.1 of Clearspace, our commercial community and team collaboration product which includes blogging, discussions and wiki documents. As an aside, we offer free Clearspace licenses to Open Source projects and it’s also free for teams of up to five people.
This release builds on the Openfire integration that shipped with version 1.0. One great new feature is the ability to see real-time presence information for users (pictured on the right).
On the back-end, Clearspace connects to Openfire using the external component protocol, then is able to query for presence data using a set of ad-hoc commands. Although we’re still polishing up a lot of things about the way the integration works, Clearspace serves as a great model for how a web application can leverage XMPP for presence and messaging.
The unification of Openfire and Clearspace is a trend you’ll see us continue strongly for two reasons:
- Real-time features will be an important way that we differentiate Clearspace from competitors (the “secret sauce”). We believe it should be easy and seamless for a user to move between real-time and non real-time collaboration and have many innovative features planned to make that possible.
- Unification is an important way to leverage the Open Source investments we’ve made in Openfire and Spark. Yes, we still believe that a hybrid Open Source strategy is good for both business and the community (see our philosophy). One of our not so secret hopes is that our commitment to Open Source and open standards will be enough to convince you to try out Clearspace at your company as an alternative to Microsoft’s clumsy Sharepoint product. Or, consider Clearspace as a replacement for the wiki that started with good intentions but quickly grew into an unmanageable rat’s nest. You know it’s gotten bad when the engineers are frustrated and the business folks won’t touch it with a ten-foot pole.
Ok, enough advertising. But we’re pretty proud of the release and it’s hard for me to reign in my enthusiasm.
I’ve recently run into a number of innovative sites and products that use Openfire.
IMified provides tools like task management, reminders and todo’s through IM bots on AIM, MSN, and XMPP/GTalk. They’ve just released an API that will make it easy to write bots that work across all major IM networks. Openfire powers their XMPP back-end.
Mosoto is a real-time collaboration application for Facebook that includes chat along with file and music sharing. They’re one of the premier implementors of the Facebook API and have a slick Flash client UI. The service is now in Alpha, but should mature and grow quickly (especially given the size of the Facebook userbase). They use both Openfire and the XIFF Flash API.
Finally, we were told at the Web 2.0 conference that the chat feature on Justin.tv is powered by Openfire. I haven’t had a chance to to verify that yet, but if true, it’s cool that we’re part of such an interesting social experiment. If you haven’t seen the site yet, Justin wears a portable camera 24×7 that streams a live video feed to the website. I personally can’t imagine broadcasting my life, but I have to respect the social commentary. In a world where we’re always connected and available through cellphones and IM, this guy is really always connected and available… to the entire world.
These three examples are part of a broader trend: I think that XMPP will become a critical piece of infrastructure for a large number of next-generation web efforts, including Google. Recent protocol advances like BOSH (XMPP for web pages), Jingle (voice and video) and PEP (advanced presence features) will only further help drive adoption.
The engineering team at Jive Software is growing fast (btw, we’re hiring!). I thought it might be interesting to talk about some of the engineering process changes we’re making to cope with that growth, especially since they directly affect product releases. First, a bit of history. We’ve always had a fairly agile development process — lots of iterations, tools like unit tests and continuous integration, etc. But, we’ve consistently had a lot of pain around our current process:
- Not enough time for QA. It’s always scheduled, but gets squeezed due to lack of time. For example, the “official” QA time period for the Spark 2.5.0 release got crunched down to almost nothing.
- Stress when we don’t need it. The stress is caused by having to cram a ton of work into a short period of time to make internally set product release dates. It’s also caused by scheduling extra features into releases at the last minute and by having to do emergency patch releases due to bugs we missed. We like working really hard, but there should be a way to do that without excessive stress.
- Unpredictable release dates. The bigger a release is, the harder it is to make accurate work effort estimates. That means that dates slip and that it’s hard to communicate to the outside world exactly when a release will ship.
So, there are some clear problems that we want to fix. The trick for us was to come up with a process that fixes those problems but that’s still light-weight enough to avoid a huge administrative burden. We’re now experimenting with a strict release train model for Spark and Smack. Assuming it goes well, the same model will be applied across all our products, including Clearspace. A visual summary of the model is below (click the image for a larger version):
The key points to this model:
- We put out a new release every three weeks (although each release will have gone through a nine week process total).
- Three weeks before each development cycle is reserved for product management; three weeks after each development cycle is reserved for QA. But notice that all three processes are all happening at the same time.
There are all sorts of subtleties to the system like how to deal with new features that take more than three weeks of engineering time, but so far everything is going quite well.
The start of the three week cycle is always on a Monday, and we have a big meeting to determine exactly which features will go into the release. Product management has already done the work of prioritizing the features so we just need to choose exactly what we’re going to work on and come up with the plan about how to get it done over the next three weeks. On the second and third Mondays during each cycle we go through more detailed updates than in our SCRUM meetings to see what’s on track and what’s not.
At the end of the cycle, we:
- Do the product release coming out of QA on Thursday.
- On Friday, finish all development and create a branch (”spark_2_5_2_branch” for example).
- Switch the builds in our continuous integration environment, TeamCity. The new branch becomes the “stable” release of the product and trunk becomes “development”.
- Release a beta version out of the new branch. In other words, the world generally always sees a stable official product release and a beta release that will become official in three weeks.
There’s way more that I could talk about with this process (including some of the potential drawbacks), but I’ll save that for future blog entries. Things we’re jazzed about so far include solid release dates, having a better process in place to deal with new feature requests and bug reports, more stable quality in each release, and always having a place to check in new feature development (trunk). We’re still early on in the new system, but we’ll all know how exactly how well this works in the next two months. Of course, we’d love your feedback as time goes on about how well you think we’re doing.
As the lead developer of the web-based version of a voice trading system used world-wide by some of the largest financial organizations, I have learned one or two things about web-based VoIP applications. When we designed our trading application, web-based VoIP was not ready for the 99% reliability and quality demanded for financial transactions. We therefore decided to keep the voice on a regular telephone (POTS) and used the web browser to handle the real-time signaling and associated data using a push method called pushlet.
My work on the Red5 plugin for Openfire is a personal attempt to investigate alternative communication technologies and get involved in the open source community. I could not have picked a better place than the Igniterealtime community. It will be interesting to see what happens when Adobe release their own VoIP enabled Flash client, but until then Flash and Red5 in my opinion is still the best way to do web-based VoIP applications.
The telephone landscape is changing. It’s less about exclusive voice communication and more about real-time collaboration where voice is just one of the many communication channels used to do effective collaboration. I believe presence is a very important ingredient that brings intelligence to finding the right channel to communicate with one or many contacts in real time. This is a vision that I share with Jive Software and that why I endorse and work with Openfire on a personal basis. The plugin approach on both server and client is a very smart idea and has enabled me to integrate Flash and Red5 with Spark and Openfire with little or no effort. Implementing HTTP-binding in Openfire was icing on the cake and enabled me to add audio and video to a web-based client like JWChat with relative ease.
This brings me to the purpose of this blog.
At the moment, Spark users get a choice of SIP, Jingle and Red5 for voice. These features enable Spark to make calls to SIP phones, XMPP users and web-based XMPP users. SparkWeb does not do VOIP yet, but that will change when Jingle supports a web-compatible transport.
Web-based XMPP users could not call SIP phones until now.
I have designed a gateway (audio bridge) which converts red5 calls to and from SIP. I have now implemented a version for Windows XP/2k3 using Asteriskwin32. The basic engine is an ActiveX component written in Visual Basic and the source code is open. To solve the problem of transcoding the proprietary Nellymoser codec to SIP, I have used 8 pairs of virtual soundcards provided by a commercial product called VAC (Virtual Audio cable). It is very popular and has been used on other projects to bridge Skype for example.
I now have tight integration between Openfire, Red5 and Asterisk and this has lead to a new version of the Red5 plugin which can control the red5Gateway and implement some interesting ideas. For example, the gateway makes it possible to make every user and group JID become a public SIP address. The gateway will route and convert all SIP calls for email@example.com to a red5 call. In reverse, if you make a Red5 call to an extension nnnnnn, the gateway will convert it to SIP and pass it on to your configured SIP service provider to route. In the case of group@example, Asterisk is used to hold the caller in a queue while every group member is called until someone answers.
Red5 gateway support is disabled by default on the Red5 plugin, as it is an optional component and is not part of the red5.war file. I am in the process of creating a hosted server to demo it over the next few weeks. If your Openfire runs on Windows and you are interested in trying it before then, send me an email and I will send you the link and documentation as soon as I finish writing it.
In the meantime, enjoy the latest version of the red5 plugin 0.0.7 which is now compatible with Openfire 3.3.0 and Spark 2.5.1. It has the latest Red5 server code: 0.6RC3. I tried to downgrade it to java5, but it was incompatible with Openfire, so I gave up trying . I have added support for viewing vcard avatars. I will add the ability to upload images in the next release so you will need Spark to upload the photographs/images for now. As I use jwchat5 myself, I have made the chat UI much like Pandion style, which I like. I only got one bug report from the previous release and have fixed it.
A big thanks to everyone at Igniterealtime, especially the folks at Jive who have added Red5 support duties to their already busy day jobs.
As always, all feedback positive or negative helps to motivate an open-source development and influence product design. The current version 0.0.7 is still far from 1.0.0, so please keep the comments coming.
The Spark Skinning Service has been a hot topic here at Jive for the past couple of weeks. The service is not yet ready to serve up customized builds of Spark 2.5 (it will be ready late May) and it turns out that one small change to the service will make it much easier to keep the Skinning Service up to date with the latest Spark release. What’s the change? Removing the ability to change the color of Spark. So in the interest of staying in sync with Spark releases, we’ll be removing this functionality.
We have also decided to stop selling Spark Skinning as a stand-alone service. Instead, it will only be available as part of Openfire Enterprise Edition. Current customers of Spark Skinning will not be affected. If you have a subscription to the service already it will continue to work until the current subscription runs out, and there is an upgrade path to Openfire Enterprise to keep the functionality after that time.
Spark Skinning is being phased out as a stand-alone service for a couple of reasons. First and foremost, the changes to Openfire Enterprise pricing substantially lower the barrier for small deployments while maintaining value-based prices for larger deployments. The second reason is that the amount of administration required to keep two sets of Spark Skinning accounts functioning smoothly became too onerous. Simplifying to a single account type will help considerably.
As always, let me know if you have any thoughts about Spark Skinning or these changes.
Earlier today, LG (IT2000) passed Gato to become the top point earner in the ignite community forums. It’s the first time ever that an outside community member has jumped ahead of Jive Software engineers, which is a pretty impressive feat. With a current score of 3475 and 5 to 10 points per question answer, that’s a lot of people he’s helped out — especially considering that not everyone remembers to award points.
So in the spirit of Ali G, all of us at Jive Software want to offer mad props to LG.
As many of you may have noticed. the IM Gateway plugin version 1.0 was released alongside Wildfire 3.2.3. (sorry guys, I can’t call it Openfire until the official release is 3.3.0 ) The release was quite a step for me as I’ve never actually released a 1.0 of anything! Typically I’ll take the attitude of having to get everything perfect before I can release a 1.0. One of the things that Jive helped me realize is that I could label some of the problem children (Yahoo, ICQ) support as experimental and basically release a 1.0 with good solid support for the rest of the protocols. That hadn’t occured to me before and I’m quite glad to see 1.0 out. Amazingly enough, there haven’t been a lot of bug reports. I hope that everyone who is using it is enjoying it.
I must admit that pushing Yahoo and ICQ support to the side “hurt” a little. However the library I’m using for Yahoo isn’t particularly stable and the ICQ support in joscar isn’t entirely golden either, and I didn’t want to see the release drawn out way into the future. I am pleased to say that the Yahoo library is getting some love as we speak and there’s been improvements to the ICQ support submitted to the joscar team and I’m working on a couple of other improvements. I would consider myself highly familiar with the OSCAR (AIM and ICQ) protocol itself, but not at all for Yahoo. (I’m referring to the low level details of how the protocol itself works, in theory the libraries I use ought to hide the details from me) As it turns out, I’m getting more familiar with the MSN protocol as I ended up taking over as lead developer of Java-JML. Thankfully, I’ve got some help on that front as well. It’s always nice to see help coming in from many angles!
So what’s coming next? Well, my highest priority is to get ICQ fixed up. Once the Yahoo library improvements come about, I’ll be aiming to solidify that as well. Of overall new features, I’m waffling between groupchat and file transfer. Groupchat is now the most voted for feature for the plugin. File transfer, on the other hand, is something I’ve never had an opportunity to get involved in, so generally I’m interested in learning how it works by diving into it. Buddy icons are also highly voted for. Such a seemingly pointless/unimportant feature, but I’m with you all; it’s one of the features that gives me the biggest joy to see in a chat client. They’re just so cute. ;D
Why did I title this Looking Throught The Fiery Gate? Well.. it’s a gateway plugin.. it’s in Openfire/Wildfire… yeah.
There have been a lot of questions about Asterisk-IM since the new voice features were added to Spark and Openfire. I’m happy to report that there are now four interested developers who are going to be stabilizing Asterisk-IM, adding new features and making sure those features work well with the other voice-related functionality in Spark and Openfire. There is plenty to do at the moment, but I wanted to find out what everyone wants to see from the plugin.
What would you like to see from the Asterisk-IM plugin once the existing features have been stabilized?