Skip navigation
All Places > Ignite Realtime Blog
1 2 3 Previous Next

Ignite Realtime Blog

263 posts

For over a decade, the Jive Software collaborative software has provided our community with a feature rich home for forums, documents, blog posts, and other things.  Due to decreased involvement by Jive in Ignite Realtime, sale of Jive Software to Aurea, and other issues "clouding" the future of our Jive cloud instance of this forum, it is time to migrate content to a new platform.

 

The new platform chosen is the open-source Discourse and you can find our instance here: https://discourse.igniterealtime.org

 

You can find some technical details on the work being done within our Jira instance: INFRA-12

 

Migration Timeline

     The intention is to make this current forum instance go into a read-only state very soon (next day or so).  This will allow for some time to double check the fidelity of the content migration as more users test things out.  Hopefully there are no show-stopping bugs with the Discourse instance that would cause us to revert back

 

Your usernames may have changed

     Account details were migrated to the Discourse instance, but there was not a one-to-one conversion of usernames due to some issues I won't expound upon here.  Your email address did directly translate, so when you first attempt to log into Discourse, you will need to reset your password by providing a valid email address used by the current forum instance.  We also plan to support Google Authenticator usage, so you can simply use your google account to log in.  If you have any doubts that the current account information is correct with regards to your email address, please feel free to directly email me  akrherz@gmail.com or stop by our web-based group-chat.

     Once you have initially logged in, you should be able to update your account settings and change your username to whatever you wish to use for future logins.

 

 

What will happen to community website links?

     The plan is to setup a transparent HTTP forwarding of most legacy community website URIs into the proper location within Discourse.  So our migration should not break the web

 

What about RSS feeds, blog feeds, planetjabber, etc?

     Indeed, there are some issues to be worked out yet with exactly how we will handle blogs, etc within Discourse.  If you are a Discourse expert and want to help out, certainly let us know!  There will be a period of whack-a-mole as we workout how this update impacts users and our software, for example the feed of content found on the Openfire Admin Console.

 

 

Wait, I don't like how feature X is setup within Discourse?

     Please let us know your thoughts, this is certainly the time to make changes.  Something may be currently setup in a matter that is just the default or something that just hasn't been looked into yet.  I certainly do not consider myself an expert with Discourse, with this being my first instance setup!

 

 

I would like to thank Alameyo, wroot, Flow, benjamin and others for their help with getting Discourse up and running.  And of course, a big thanks to Surevine for their current sponsorship of Ignite Realtime's Amazon Web Services presence.

 

In Closing

     I am very thankful to Jive Software for their more than generous support of Ignite Realtime over the years.  While the amount of source code written by Jive over the past few years has stopped for Ignite projects, their financial support of Ignite Realtime's servers and internet hosting remained steadfast. Speaking for Matt Tucker here, I believe his vision was for Ignite Realtime to mature and become more self sustaining.  Recently, a major step toward that goal was taken with the establishment of the Ignite Realtime Foundation and our migration to Amazon Web Services.

 

 

Thank you for reading this and your patience as issues are worked out with this migration.

Flow

Smack 4.2.1 released

Posted by Flow Champion Aug 14, 2017

I've tagged and released Smack 4.2.1 to Maven Central. We decided to omit the smack-omemo* in this release packages as the API is not yet stable. Paul is currently working on encrypted Jingle Transports as part of his GSOC project which also involves OMEMO, and we probably will make some API changes to the existing OMEMO API because of that. As always daily snapshot builds are available from igniterealtime.org/repo.

The Ignite Realtime Community is proud to announce the 4.1.5 release of Openfire.  This release signifies our continuing effort to produce stable 4.1 series releases while work continues on the next major release.  A changelog denoting 18 resolved issues is available and you can download the release builds from our website.  There was one change that we decided not to ship with this release.  Work was done to produce 64bit windows installers, but complications exist when you attempt to upgrade previously installed 32bit versions.  We hope to iron out those issues prior to releasing 4.1.6 or even 4.2.0, depending on which comes first If testing this functionality interests you, please stop by our chatroom and let us know!

 

Important to know: Openfire now automatically installs the service. On the last step of the installer you will have an option whether to start it or not (it will also open the browser pointing to Admin Console, if you chose to start it). You shouldn't run the launcher, if the service is started. Documentation is updated accordingly. If you already have older service running, stop it before upgrading.

 

The following table denotes release artifact sha1sums and some github download statistics for the 4.1.4 release of that particular file.

OSsha1sumFilenameVersion 4.1.4 Downloads
Linux RPM (32bit JRE)b3d7b9672d480f767eb83161d892a40fcb9d2e8bopenfire-4.1.5-1.i686.rpm2,624
Linux RPM (No JRE)d283b5095042a986bbb75338bc22ed7d8ee2847dopenfire-4.1.5-1.noarch.rpm2,095
Linux RPM (64bit JRE)1d0f4d40e7a56d8f097addb53258f3d30cd091f5openfire-4.1.5-1.x86_64.rpm7,598
Linux .deb2c0111af8526dabe8d01ea91e0ed4672ec3652a0openfire_4.1.5_all.deb15,123
Mac OSf08c7d9b0be246d99b5ec1702ca7b42747767d51openfire_4_1_5.dmg3,577
Windows EXE21cfa9becc8513a9622135e0fcd671e80111063aopenfire_4_1_5.exe33,178
Binary (tar.gz)ecc172b615e3b75500bd1fe353a6c41713dcdd57openfire_4_1_5.tar.gz5,532
Binary (zip)4c4d4825c086052caa2fd06dfbe150ad85bba582openfire_4_1_5.zip8,449
Source (tar.gz)281dbc1857dbfd49010b595a8acd9d8945ff3902openfire_src_4_1_5.tar.gz1,149
Source (zip)9c8f9f8d2e8d5d4f2af711df4c5526fde62c5fb4openfire_src_4_1_5.zip3,898

 

As a reminder, our development of Openfire happens on Github and we have an active MUC development chat hosted at open_chat@conference.igniterealtime.org.  We are always looking for more folks to pitch in with testing, fixing bugs, and development of new features.  Please consider helping out!

 

As always, please report any issues in the Community Forums and thanks for using Openfire!

This blogpost doubles as a GSoC update, as well as a version release blog post.

 

OMEMO Clownfish logo.
OMEMO Clownfish logo (conversations.im)

 

I have the honour to announce the upcoming release of Smack! Version 4.2.1 brings among bug fixes and additional features like Explicit Message Encryption (XEP-0380) and Message Processing Hints (XEP-0334) support for OMEMO Multi-End-Message-and-Object encryption (XEP-0384). The OMEMO protocol was developed by Andreas Straub for the Conversations messenger (also as a Google Summer of Code project) in 2015. Since then it got quite popular and drew a lot of attention for XMPP in the media. My hope is that my efforts to develop an easy to use Smack module will result in an even broader adoption.

 

The new Smack release is available from the Maven snapshot repository.

 

OMEMO is a protocol for multi-end to multi-end encrypted communication, which utilizes the so called Double Ratchet algorithm. It fulfills amongst the basic requirements of encrypted communication (confidentiality, authenticity and integrity) also the properties of deniability and forward secrecy as well as future secrecy. Smacks implementation brings support for encrypted single and group chats including identity management and session renegotiation.

 

Current implementations (as well as this one) are based upon the libsignal library developed by OpenWhisperSystems for their popular Signal (formerly TextSecure) messenger. Smack's OMEMO support is structured in two modules. There is smack-omemo (APL licensed), which contains the logic specified in the XEP, as well as some basic cryptographic code. The other module smack-omemo-signal (GPLv3 licensed) implements some abstract methods defined by smack-omemo and encapsulates all function calls to libsignal.

 

Currently smack-omemo-signal is the only module available that implements the double ratchet functionality, but there has been a lot of discussion on the XMPP Standards Foundations mailing list regarding the use of alternative (more permissively licensed) libraries for OMEMO (like for example Olm, a double ratchet implementation from our friends over at the [matrix] project). So once there is a new specification that enables the use of other libraries, it should be pretty easy to write another module for smack-omemo enabling OMEMO support for clients that are not GPLv3 compatible as well.

 

Smack’s OMEMO modules are my first bigger contribution to a free software project and started as part of my bachelors thesis. I’m quite happy with the outcome

 

Smack Logo
Also Smack has a new Logo!

 

That was a lot of talking about OMEMO. Now comes the second functioning of this blog post, my GSoC update.

 

My project of implementing Jingle File Transfer (XEP-0234) for Smack is going relatively well. I'm stuck at some points where there are ambiguities in the XEP or things I don't know yet, but most of the time I find another construction site where I can continue my work. Currently I'm implementing stanza providers and elements needed for file transfer. Along the way I steadily create Junit tests to keep the code coverage at a high level. Already it pays off when there are fiddly changes in the element structure. I already got file transfer over Jingle IBB working.

 

It’s a real pleasure to learn all the tools I never used before like code coverage reports or mocking and I think Flow does a good job introducing me to them one by one.

 

That’s all for now. Happy hacking

The Ignite Realtime Community is proud to announce the 4.1.4 release of Openfire. This release signifies our continued effort to have a stable 4.1 release series while work progresses on the next major release.  A changelog exists denoting our 14 resolved issues and you can download the release builds from our website.  The following table contains a reference of release build files, their associated sha1sums and the number of times the previous release for that build type was downloaded.

OSsha1sumFilenameVersion 4.1.3 Downloads
Linux RPM (32bit JRE)8846cd55047d9871ef9357568e0c1a9f43c41652openfire-4.1.4-1.i686.rpm3,293
Linux RPM (No JRE)61a89afb66d74d523addbd238bf0c008ffada8aaopenfire-4.1.4-1.noarch.rpm2,249
Linux RPM (64bit JRE)8f370c7e9dfe530f7d05d93122ca72b9b563c92copenfire-4.1.4-1.x86_64.rpm12,142
Linux .deb83bf090c07daeacb59a97ddade1cd76c1dbb3030openfire_4.1.4_all.deb15,714
Mac OS37664eee2235748653ce070e873e5064a8e49bedopenfire_4_1_4.dmg4,095
Windows EXE1f417e66ec7ec729ff60cada797d112267370826openfire_4_1_4.exe43,598
Binary (tar.gz)6c8c262fbcc00c84bf86aab3787485e619757cc0openfire_4_1_4.tar.gz7,377
Binary (zip)25763a8273a5d7a66e322b3515c38dfa6c52dc6bopenfire_4_1_4.zip17,892
Source (tar.gz)680aad9967cef70ba609bb82854b9f991c8cd9c5openfire_src_4_1_4.tar.gz1,872
Source (zip)656ca8c2fe4679f340682e33e1042d6ae00f9ed3openfire_src_4_1_4.zip6,273

 

As a reminder, our development of Openfire happens on Github and we have an active MUC development chat hosted at  open_chat@conference.igniterealtime.org. We are always looking for more folks interested in helping out, so please consider pitching in!

 

As always, please report any issues in the Community Forums and thanks for using Openfire!

Flow

Smack 4.2.0 released

Posted by Flow Champion Mar 20, 2017

Around two years ago, on 2015-03-29 to be precise, Smack 4.1.0 was tagged and released. A few days ago I've tagged and released Smack 4.2.0 to Maven Central. The 4.2.0 release marks a milestone for Smack, but before I got into the exciting new features, I'd like to thank the various contributors:

 

$ git shortlog -sn 4.1.0..4.2.0

   459  Florian Schmaus

     8  Fernando Ramirez

     3  Anno van Vliet

     3  Tibo-lg

     3  damencho

     3  ramabit

     2  Andrey Starodubtsev

     2  Vyacheslav Blinov

     2  stawny

     1  Andrey Prokopenko

     1  Craig

     1  Daniel Hintze

     1  Dave Cridland

     1  David Black

     1  Dmitry Deshevoy

     1  Grigory Fedorov

     1  Hugues Bruant

     1  Ishan Khanna

     1  TheHaf

     1  Tomas Nosek

     1  Tomáš Havlas

     1  UltimateZero

     1  Vaibhav

     1  meisterfuu

     1  rohanag12

     1  vfite

 

I can not remember when Smack had so many contributors. Thanks everyone and keep the contributions coming.

 

The notable changes to Smack 4.2 include support for DNSSEC (thanks to a previous MiniDNS GSOC project), JIDs as first class citizens by using JXMPP's JID API, and tons of other improvements, new features and bug fixes. You can read more in the Smack 4.2 Readme and Upgrade Guide and the Smack's JIRA release notes.

 

Last but not least, thanks to Bilal Siddiq, Smack now has a logo.

 

Ever wanted to contribute to open source? Are you interested in XMPP/DNS/DNSSEC? Google gives students the chance to work on open source projects and get paid for it as part of Google's Summer of Code 2017. The XSF acts as umbrella organization for projects like Smack and MiniDNS [4]. Feel free to contact me in the gsoc@muc.xmpp.org if you are interested in participating or if you want to discuss your own Smack/MiniDNS related project ideas.

Chrome version 57 makes a breaking change to webrtc that breaks Openfire Meetings. For details, read this.

You can apply a work-around by using the meetings settings admin web page to force a "negotiate" rtcpMuxPolicy as shown in the screen shot below.

 

ofmeet.jpg

 

Otherwise, upgrade to version 0.3.29 from github here.

 

The 0.4.x branch is now up-to-date with the latest Jitsi code including the mobile Jitsi-Meet applications for iPhone and Android. It can be previewed from here. It is still work in progress. If you test it with the mobile app, enter the full URL of your Jitsi-Meet application (https://<your-server>:7443/ofmeet/jitsi-meet/<room name>) and ensure your Openfire allows anonymous xmpp connections.

For many years now, Google is orchestrating its "Summer of Code" program. GSoC aims to bring student developers into the open source community, during the summer holidays.

 

As it did before, the XMPP Standards Foundation (XSF) will act as an umbrella organisation for this years edition of GSoC. The Ignite Realtime community is open to accept students under this umbrella.

 

If you're a student and interested in working on one of our projects as part of GSoC, you should get in contact! We've prepared a number of teaser tasks as well as project ideas, all of which are available in the XSF wiki.

I have added Kaiwa XMPP web client to the Chat API plugin. I hope to extend it with the audio/video conferencing stuff from Openfire Meetings later on.

kaiwa2.jpg

First time you use it (https://your_server:7443/apps), you will get a prompt to enter your Openfire username/password. It works best with the websocket plugin.

 

**UPDATE**

This plugin is broken with the latest Openfire 4.1.4 version as the websocket it depends on has a show stopping issue with External SASL authentication. Until we can source a solution, I suggest you use Openfire 4.1.3 and below.

Daryl Herzmann

Openfire 4.1.3 Release

Posted by Daryl Herzmann Champion Feb 24, 2017

The Ignite Realtime Community is pleased to announce the 4.1.3 release of Openfire.  This release signifies our continued effort to have a stable 4.1 release series while work progresses on the next major release.  This release hopefully resolves the roster group issues noticed in Openfire since the 4.1.0 release.

 

You can find our release builds here and this is a listing of sha1sums and an accounting of previous version downloads.

OS
sha1sum
FilenameVersion 4.1.2 Downloads
Linux RPM (32bit JRE)

2b84acd3dbe6648ec4b08c81d912405d2ba78d5b

openfire-4.1.3-1.i686.rpm459
Linux RPM (No JRE)b18f1b51bf131b7aff90af92fd4c7dce79ca2d51openfire-4.1.3-1.noarch.rpm335
Linux RPM (64bit JRE)d9c52cd0029feb5e8b916410cea55d654f56b54b openfire-4.1.3-1.x86_64.rpm1413
Linux .debda7ea0c5bd48c519b4b4a10a5af9160d77dce30bopenfire_4.1.3_all.deb2440
Mac OSa76aa1612fa8066d76bab191f6fb7885b62c4195 openfire_4_1_3.dmg506
Windows EXE12110eaa952c2bb9f0142aa5ecd67bde399ce5beopenfire_4_1_3.exe5104
Binary (tar.gz)163c4f21bf34528fe3909e5be405d156911874feopenfire_4_1_3.tar.gz1066
Binary (zip)fde35bc78d875ceb83d9c39be7d2f1a71c9c640aopenfire_4_1_3.zip1147
Source (tar.gz)f270729ee6c7c530a7e927d728da7f136ff136f7openfire_src_4_1_3.tar.gz206
Source (zip)a04a712c0a9a73acc4c6f4b8b3fbd812528d65b2openfire_src_4_1_3.zip687

 

As a reminder, our development of Openfire happens on Github and we have an active MUC development chat hosted at  open_chat@conference.igniterealtime.org. We are always looking for more folks interested in helping out, so please consider pitching in!

 

As always, please report any issues in the Community Forums and thanks for using Openfire!

Most of our projects have a long history. This certainly goes for Spark, which was created over ten years ago. Although many of you are actively using Spark today, it is beginning to show its age. This is something that we have been planning to address for a while now.

 

Spark was created around the same time that the Kyoto protocol went into effect, Pluto got demoted to the status of 'dwarf planet' and Italy won the FIFA world cup in Germany. Thereabouts.

 

Comment.jpgSince then, source code development tooling has improved a lot. Today, the Spark project is struggling to find active contributors. We believe that one of the reasons for this is that it's pretty hard for developers (especially those that are used to work with modern tooling) to get started with our project. We have been working on that. First, we moved all of our projects from our old Subversion repository to Github. We have noticed that this dramatically improved the accessibility of our code. Second, Smack 4 happened, bringing the backbone of Spark back up-to-date.

 

Now, we are addressing the structure of the project itself. We will restructure the project as a Apache Maven project. This will bring a good deal of predictable structure to the project, which has many benefits. One of these is that the project will integrate easily with various development tools.

 

Moving Spark from its existent Ant-based structure to a Maven structure is no small task. There is no one right way of doing this. We have given it a shot and have created a structure that we think is very workable. Before committing to this structure, we would very much invite others to have a look, and comment on what we've done. The reasoning behind this is simple: once we've committed to a particular structure, it will be disruptive to change it. If we want to apply improvements, we should do so now.

 

Please, review our new project structure, and let us know what you think. You can find the new structure in the SPARK-1791_Maven branch on Github.

 

Ask yourselves: does this structure help me? Is it easier to compile the source code? Can I integrate it with my IDE of choice without too much trouble? Can I create new plugins? Does the new structure introduce a problem that needs to be addressed before committing? Can it be improved? We welcome all feedback!

Dele Olajide

Openfire Chat API

Posted by Dele Olajide Champion Feb 18, 2017

I am trying to build a new web based client for Openfire to replace the outdated and abandoned Flash-based Sparkweb. The project is called Pade (A Yoruba word for Meeting) and my first step was to decide on my web client API.

 

Representational state transfer (REST) has now become the standard for abstracting request/response type web services into an API. When it is combined with Server Sent Events (otherwise known as Event Source), the result is a fresh new way of providing two-way real-time communication between web clients and a server using synchronous requests/responses (IQ) with REST and asynchronous evening (Message, Presence) with SSE. The really cool feature of SSE is the automatic re-connection by the web browser.

 

The Rest API plugin by Redor is brilliant . It allows you to administer Openfire via a RESTful API. Most of the common functions we do from the Openfire admin console web application can now be automated and integrated into server-side Java plugins or client-side web applications with ease. After spending hours inside the code and extending it for use at work to manage all the telephony entities we use with our Openlink XEP from the various commercial plugins we develop, it became clear that REST+SSE is the way forward for web-based real time messaging. Don't take my work for it. Read what the folks at erlang-solutions.com have to say.

 

As my first step towards implementing Pade, I have built a Chat API plugin by extending the REST API plugin with SSE and Jetty web authentication taken from the Openfire meetings plugin. The plugin now runs on the HTTP-BIND (7070/7443) port instead of the admin (9090/9091) port. It authenticates you as an Openfire user once and reuses the authentication for REST,  SSE and XMPP bosh/websockets. It supports everything you can do with the REST API plus Bookmarks and SIP Accounts as an admin user. It then enables you as a normal user to handle presence, chat, groupchat, contacts and users with just a handful of REST requests and SSE events.

 

Documentation can be found on GitHub Wiki pages

Daryl Herzmann

Openfire 4.1.2 Release

Posted by Daryl Herzmann Champion Feb 18, 2017

The Ignite Realtime Community is pleased to announce the availability of version 4.1.2 of Openfire. This release signifies our ongoing effort to produce a stable 4.1 series while effort is made on new features and functionality in Openfire 4.2.  You can find a release changelog denoting the 13 Jira issues resolved in this release.  If you had issues with inconsistent appearance of groups, do please test this release to see if those issues are now resolved. You can download the release from our website here and the sha1sum's for the available artifacts are as follows.

 

OSsha1sumFilenameVersion 4.1.1 Downloads [1]
Linux RPM (32bit JRE bundled)c2f12c3ec6ba2f64388279f106f2749272c9504copenfire-4.1.2-1.i686.rpm1290
Linux RPM (no JRE)226a7f1138fda7c456523bf80e6140e020fd5a74openfire-4.1.2-1.noarch.rpm965
Linux RPM (64bit JRE bundled)6892ec82e1435b6cbf23da1ba1efb9d94122d8a6openfire-4.1.2-1.x86_64.rpm3805
Linux .debc205eefe136fe0481e498668f258a0bc724a7080openfire_4.1.2_all.deb7311
Mac OS dmgb9570c78854c226714c23001997119e503e0aaabopenfire_4_1_2.dmg1207
Windows EXEdba34e78456f03bbd0de5a5cf94730c433d75c20openfire_4_1_2.exe19798
Binary (tar.tgz)cf4676f1e8c8a04999f6e9c97d859c8bbff35c4eopenfire_4_1_2.tar.gz2622
Binary (zip)0f4624f2c387c00373c717a52ed442741ceb0e93openfire_4_1_2.zip3058
Source (tar.gz)9b1efd5090ff37e4faca6d460b20ec40a4c40a53openfire_src_4_1_2.tar.gz408
Source (zip)b32c39ec84ad04acf46881b682919ef41fab3be4openfire_src_4_1_2.zip1371

 

[1] We recently migrated to storing our release artifacts on Github and thanks to their API, we can get metrics on how many times the artifact was downloaded.

 

As a reminder, our development of Openfire happens on Github and we have an active MUC development chat hosted at open_chat@conference.igniterealtime.org . We are always looking for more folks interested in helping out, so please consider pitching in!

 

As always, please report any issues in the Community Forums and thanks for using Openfire!

Flow

Smack 4.2.0-rc3 released

Posted by Flow Champion Feb 11, 2017

I've just released Smack 4.2.0-rc3 to Maven Central. Smack 4.2.0 is scheduled to be released early Q2 2017, according to Smack's release life cycle. And right now, it looks like the train is right on time.

I am happy to announce that we are bringing back one of our older projects from the grave: the Asterisk-IM project! This project was started in 2005 by Jive Software, and can be used to integrate the Asterisk platform in Openfire. Due to a lack of manpower over the last few years, development stalled. No longer!

 

We have found the most excellent Marcelo Terres willing and able to take on the reigns as project lead for the project! Simultaneously a code contribution by Ron Arts brought back compatibility of the Asterisk-IM source code with both recent versions of Openfire, as well as Asterisk 13 - but more on that later, from Marcelo.

 

I am more than confident that the project is in good hands with Marcelo. Not only has Marcelo been a active manager of the primarily Brazilian-based Openfire community, he is heavily involved in the Asterisk project, going as far as to speaking on AstriCon 2016.

 

As of now, we restored references to the project in our Ignite Realtime community. There is some more work to be done: downloads still point to an older release, and we might be lacking a bit of project infrastructure (such as an issue tracker, dedicated community forum, etc), but I'll leave that to Marcelo to put in place as he sees fit.

 

Marcelo, thanks for doing this! I'm excited to have you on board (as far as you weren't already)!

Filter Blog

By date: By tag: