“Why should I use XMPP?” is a question we get asked a lot. Our answer is often technically-focussed, as there are plenty of reasons XMPP might be the right choice, or we might explain about the benefits of a federated approach – where everyone can run their own server and control their own data. Either way, the fact it is an ‘open standard’ never ceases to be mentioned.
Open standards have many advantages over proprietary formats (too many to list in one blog post) but one in particular is that it gives you the choices and control about how you access your data and services.
For example (get ready for the analogies) imagine you are an individual accessing someone else’s XMPP service. Because XMPP is built on open standards, you get to choose what applications you use to connect to their system; for example, a mobile phone provider does not mandate that to use their services you must use a specific handset – the choice is yours). Your provider may have one that they prefer, or offer, but there are myriad other XMPP applications – the choice remains yours and you can make that choice based on your individual preferences and requirements.
Even better, if a new project implements a better XMPP client than the one you are currently using, firstly, that project is able to do so, and secondly – you are free to start using it! Back to our phone analogy, imagine if a new mobile handset came out that was even better than the one you had chosen, and you could just pop your sim card out of the old phone and straight into the new one… no hassle, but a much better service for you.
And if you have particular needs not being met by existing clients, you are freely able to implement your own or to extend any of the open source options to meet those requirements. The power is all yours.
This is a critically important difference between open standards (like XMPP) and access to proprietary systems – if you use a proprietary system, the operator is in control of how you access the service; and on a whim they could choose to shut down your choice of third-party clients. Using our phone analogy, this is like your mobile service provider controlling which handsets you can use, and on a whim deciding that they have 1 choice and only than handset can be used from now on. In this situation you might find yourself unable to access your data in a useful way. A proprietary system may also release a new version of the client that you don’t like or that doesn’t run on your systems; if they force upgrades you may no longer be able to access the systems or your data. As you can see, the choice isn’t really yours.
Alternatively, imagine you are an organisation running an internal service. You might choose to use a cloud provider, in which case the advantages of choosing a vendor using open standards is the same as above. You might also want to apply organisational policies to your internal service; here again, open standards like XMPP are a good choice. They ensure that you can choose the client you need, not the client the vendor of a proprietary system wants you to use. An open-standards system even ensures (with the ability to export your data) the option to migrate from one server provider to another using mechanisms defined for XMPP servers. When its your systems, it should be your choice.
These advantages also apply to third-party developers – developing for XMPP gives you a level playing field and you’re free to implement your client, server, library, or component according to the standards; you don’t run the risk of being locked out of the systems for which you’re developing, either by unpublished protocol changes or by legal action. And if you think the protocols can be better, you can even contribute to the open standards process and make improvements you need.
Using open standards matters whenever your choices are important to you, be it today or tomorrow. And that is why you should use XMPP.
In this Boxcar Developer Push Workshop, Mickaël Rémond explains how to integrate mobile push notifications using Boxcar Developer Platform.
Boxcar Platform covers Apple, Google and Amazon push.
Some thinking on how we are approaching 2015.More Incremental Advances
In 2012 we set our sights on designing the best way to build messaging
Today Buddycloud is being added to more and more apps customers apps. This is good. But not good enough: in 2015 we’re doubling down on making incremental changes to the Buddycloud-stack that help with reliability and scalability.
We’ll also be spending more time on the open specification process that powers Buddycloud so that others can build their own messaging products.Stay Lean and Flexible
We’re fortunate to have a revenue stream from existing Buddycloud customers. And we’re humbled by their trust in our open communication mission.
Each Buddycloud customer has slightly different needs. And this is helping us make sure we keep the Buddycloud stack flexible enough to cover general use cases.Improve on Our Competition
Yes, there are other messaging systems out there.
But we notice developers want something that does what it says it will do. Reliably. And with the added benefit of being able to run on-premises and federate with other sites. No other commercial messaging stacks do this.Focus on Product Not Sales
We’re a tech team that sees our engineering selling itself - weekend hacking projects becoming enterprise messaging systems.
Boring unsexy, no big launch parties, self funded. And no sales team, just good product selling itself with word-of-mouth.
And that’s our plan for 2015.
Sébastien Luquet introduces our prototype for geolocalized push notifications with Boxcar Beacon. The prototype has been built on top of Estimote beacons.
Talk is followed by a live demo.
It’s a week until the XMPP Summit in Brussels, which I won’t be able to attend. However, I do have some thoughts about two of the subjects that are on the agenda that I wanted to share.
Carbons/MAM and e2e-encryption seem to be moving in two completely opposite directions: MAM wants to store messages server-side, while e2e protocols like OTR want to ensure those stored messages are useless. But I don’t think they’d have to be mutually exclusive. I think it would be possible to find a solution that unifies the two concepts.Background
Many chat services nowadays offer synchronizing the most recent messages between all devices. Given the choice between something that is more secure and something that does synchronize, I fear many people will choose the convenience of synchronization.
So far, everything that I’ve looked at fails on at least one of the following:
With Carbons/MAM you get 1, but if you turn on OTR, you only get 2 and 3. I could go into detail about a number of other services, but the bottom line is: nothing currently offers all 3. Yet I still think it is possible to make a protocol that does. TextSecure does seem to be working on it, but as far as I know, it’s not possible yet.Goals
Lets make it a little bit more clear what it is that I think we should aim to achieve:
I prefer an easy to use over a maximally secure solution: I want users with no idea of what e2e encryption is or why they would want it to be using this opportunistically, without being bothered by it. There are enough ways to achieve good security for people who know what they’re doing, I want to give a (lower) level of security to everyone. For example, manually copying a private key to all your devices is not an acceptable solution. Of course this means the server can tamper with the encrypted chats, but I’d rather have a protocol where the server needs to actively tamper with communications than something where the server can quietly log everything.Proposal
The following is just an incomplete suggestion of how this could be implemented:
Why Axolotl, and not OTR?
Axolotl handles sending messages to offline devices better and the cryptographic primitives used are more modern.
Why not draft-miller-xmpp-e2e?
Of course this is still far from a concrete specification, but I am convinced it is possible to do. Instead of half the XMPP world working on history synchronization and the other half working on breaking that, lets look for a unified solution.
Since I took on the role of Openfire project lead, the Openfire developers have been working amazingly hard across almost every part of the server's code, with a view to making a new release we can all be really proud of.
After a huge amount of work, the Openfire team is really excited to announce we've reached a beta state with the 3.10.0 release, available from http://www.igniterealtime.org/downloads/beta.jsp
This release aims to improve security and stability over the current 3.9.3 stable release, provides a set of important new protocol extensions, and modernizes the XMPP core protocol support - in short, this is going to be the release we wanted to make.
While this is a beta release, we're not recommending it for critical production use; however this is running on igniterealtime.org itself and developer sites, and we'd appreciate people trying it out in non-critical production cases.
We're hoping it'll reach full release rapidly, and we'll be welcoming experiences of anyone deploying so we can add that last polish. Having dealt with the last remaining blocking bug, we're expecting this to move to a final stable release within a week or two.
Caleb James DeLisles, from XWiki, introduces CryptPad at SeaBeyond 2014 conference.
CryptPad is a zero knowledge realtime collaborative editor, inspired by Bitcoin mechanisms.
Content is encrypted so only people who have the CryptPad link can access and read the content.
You can test it on Cryptpad
Here is the recording of Christophe Romain’s talk on the WebSockets feature we are adding in our Boxcar Developer Push platform:
The 17th XSF Summit is approaching!
On January 29th and 30th 2015, just before FOSDEM2015. members of the XMPP community will be gathering at the Cisco offices in Diegem, Brussels to talk about all things XMPP.
Our agenda is evolving but so far includes:
To keep up to date with Summit plans, please visit the wiki page for Summit 17 . If you intend to come along to the Summit, please join the firstname.lastname@example.org discussion list and post with your participation request.
Jérôme Sautret introduced what it is like to deploy ejabberd SaaS service and how it integrates with your own back-end.
It happens this is the most advanced and scalable way to date to deploy an XMPP messaging service and it integrate directly with your own data.
The Ignite Realtime community is happy to announce the first beta version of the upcoming Smack version 4.1. Smack is an open source XMPP client library written in Java with multi-runtime support. It can be used with Java SE and Android runtimes. If you haven't done already now is the ideal time to grab Smack 4.1.0-beta1 and try it out. Compared to the alpha versions of 4.1 the API is considered stable and API changes are unlikely to happen.
Everyone is invited to test beta1 in his projects. The community forum awaits your feedback and bug reports. Although the beta version has proven reliable so far, please only use it productive after intensive testing.
An incomplete list of API changes can be found in the Smack 4.1 Readme and Upgrade Guide. Please consult the Readme before using Smack 4.1.
We had a great SeaBeyond conference in past December. It was really great to meet our users, who are developers building innovative products on top of our technologies.
During the conference we have shown what ProcessOne is working on and preparing to release in the next months. We gathered lot of feedback and are feeling energized to start 2015. Thank you all for joining us !
As promised, we will publish videos of the talks and interviews of developers present at the conference in the coming days. We talked about XMPP, ejabberd, ejabberd SaaS, Boxcar, push notifications, beacons, smartwatches. We hope to have great material for you to enjoy.
In the meantime, if you could not join us at the conference, here is a short video that will give you an idea of the atmosphere at the event.
#IoTDayStockholm is coordinating several schedules from events in different time zones and will be having workshops creating XMPP IoT enabled devices. These will be open to interact with, to read and write values over the secure XMPP network.
Greetings all. Baring any significant community protest, the subversion server for Igniterealtime will be shutdown on 1 January 2015. All of the active and still relevant repositories have been migrated (with commit histories hopefully in-tact) to our Github presence.
The following Ignite subversion repositories were not migrated due to them likely no longer being relevant
Some of the migrated repositories to Github have not seen development in a number of years. We are certainly interested to hear of any community members that may wish to revitalize any of these projects:
When the subversion service is shutdown, a copy of the repos will be maintained offline in case anything comes up in the future necessitating its revival. Github has been an awesome platform to collaborate on for our active projects that migrated a number of months ago. Hopefully this change helps breathe some life into the older Igniterealtime projects!
We’re pleased to announce the last release of ejabberd for 2014 !
Thanks to contributors, this release includes great improvements and opens road to 2015.
ejabberd Community 14.12 includes many bugfixes, and a few new features:
– New module mod_client_state implements XEP-0352: Client State Indication
– New module mod_fail2ban to ban IPs that show malicious signs
– New option store_empty_body in mod_offline
– New option disable_sasl_mechanisms
– Improve option resend_on_timeout to support if_offline
Improvements mainly cover:
– More robust offline server
– Better charset support in XMLRPC
– Some PEP issues fixed
As usual, the release is tagged in the Git source code repository on github
The source package and binary installers are available at ProcessOne
If you suspect you found a bug, search or fill a bug report in Jira