Agregador de noticias

ProcessOne: Bridging Push and Chat to build a Mobile only Chat Support Service

Planet Jabber - 28 January, 2015 - 11:23

Mickaël Rémond introduces how push and XMPP chat can work together to build a seamless, mobile only chat support service.

Chat support on mobile is a powerful way to engage with your true mobile users and have a real conversation with them.

This platform leverages two core skills of ProcessOne: XMPP and Push expertise.

The XMPP Standards Foundation: It’s all about choices and control

Planet Jabber - 26 January, 2015 - 13:39

“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.

ProcessOne: Adding Push to Mobile App with Boxcar Developer Push – SeaBeyond 2014 Video

Planet Jabber - 26 January, 2015 - 10:53

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.

Fanout Blog: Building a realtime API in Django

Planet Jabber - 25 January, 2015 - 05:49
Django is an awesome framework for building web services using the Python language. However, it is not well-suited for handling long-lived connections, which are needed for realtime data push. In this article we'll explain how to pair Django with Fanout to reach realtime nirvana.


buddycloud: The Buddycloud plan for 2015

Planet Jabber - 23 January, 2015 - 15:32

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.

ProcessOne: Beacons and Real Time Services with Boxcar – SeaBeyond 2014

Planet Jabber - 23 January, 2015 - 12:56

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.

Thijs Alkemade: Multi-end to multi-end encryption

Planet Jabber - 23 January, 2015 - 08:48

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.


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:

  1. History synchronization.
  2. e2e-encrypted one-to-one chats.
  3. Forward-secrecy.

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.


Lets make it a little bit more clear what it is that I think we should aim to achieve:

  1. History synchronization: Every message I receive should go to every device I have. Every message I send should also become visible on every other device I have. When a device has been offline (for a reasonable amount of time), it should receive all the messages I sent and received since it went offline (up to some practical limit).
  2. Messages I send should be e2e-encrypted over every path they take (to each device of the recipient, to each other device I have).
  3. The encryption should be forward-secret: obtaining any long-term private key should not allow the decryption of past messages. Of course we will have to compromise on forward-secrecy a bit, as devices that are offline should still be able to decrypt messages when they come back online. This means whatever is stored to that device’s disk is enough to decrypt all incoming messages while it was offline. However, the stored data should only allow decryption of as few as possible other messages.

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.


The following is just an incomplete suggestion of how this could be implemented:

  • I use Axolotl (the TextSecure protocol) to set up sessions between every device I have and every device the recipient of my message has, and among every pair of my own devices.
  • When encrypting a message, the message is first encrypted and authenticated using new, random keys. Then, for every device that should be able to decrypt it, I add an encrypted header that encrypts the keys I’ve just generated. The header also contains the extra data needed for Axolotl (for example, to update the ratchet).
  • The (normal) Carbons extension will make sure this message is delivered to everyone that can decrypt it.
  • Storing messages in MAM is fine and requires no changes to MAM, a device that was offline and comes back online can decrypt all new messages as it saved its Axolotl keys.
  • Even if the MAM archive expires messages after a number of days/weeks/etc. this can still work. Axolotl can detect and recover from missing messages.
  • This does need something that publishes the list of devices someone has, with their public keys (and maybe some “pre-keys”, as TextSecure has). I think PEP could work here, but I haven’t checked.
Some fake FAQs

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?

  • Forward-secrecy is completely unspecified by the current version of the draft.
  • There are no “sessions”, messages are encrypted individually. So, there is no protection against an attacker dropping some of the messages.

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.

Fanout Blog: Bayeux / Faye compatibility

Planet Jabber - 21 January, 2015 - 19:17
Bayeux is one of the few standard protocols for publish-subscribe messaging on the web. Today we announce Bayeux compatibility in the realtime push service. When you publish JSON objects through our service, they can be received by any Bayeux-compatible client library, such as Faye.


Ignite Realtime Blog: Openfire 3.10.0 Beta

Planet Jabber - 21 January, 2015 - 16:59

Hey everyone,


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


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 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.



ProcessOne: CryptPad introduction – SeaBeyond 2014 Video

Planet Jabber - 21 January, 2015 - 09:54

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

ProcessOne: Web Push Notifications with Websockets – SeaBeyond 2014 Video

Planet Jabber - 19 January, 2015 - 10:44

Here is the recording of Christophe Romain’s talk on the WebSockets feature we are adding in our Boxcar Developer Push platform:

The XMPP Standards Foundation: XMPP Summit 17

Planet Jabber - 16 January, 2015 - 12:16

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:

  • XMPP-IoT, Current state of the IoT XEPs
  • Editor team automation sprint
  • e2e encryption & OTR
  • The state of UPNP and their XMPP cloud project (and us as liaisons)
  • Relation/Liaison to W3C interest group on the Web of Things: charter
  • XEP-0322 EXI: Update on/upstreaming of implementation, comments

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 discussion list and post with your participation request.


ProcessOne: Developing for ejabberd SaaS – SeaBeyond 2014 video

Planet Jabber - 15 January, 2015 - 08:49

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.

Enjoy !

Ignite Realtime Blog: Smack 4.1.0-beta1 available

Planet Jabber - 14 January, 2015 - 13:17

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.


Release highlights include support for XEP-198 Stream Management (disabled per default), improved multi-threading performance, improved MUC API and support for SCRAM SHA-1.


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.


As always, Smack 4.1.0-beta1 is available from Maven Central.

ProcessOne: SeaBeyond 2014 Summary

Planet Jabber - 13 January, 2015 - 09:33

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.

The XMPP Standards Foundation: XMPP on the Global Internet of Things Day

Planet Jabber - 8 January, 2015 - 09:14

The 9th of april is the Global IoT day  (Internet of Things day)  on the site and on events and meetups around the world are celebrating and connecting live devices.

#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.

look here for the  schedule here and many details on

Peter Saint-Andre: Monadnock Valley Press Annual Report 2014

Planet Jabber - 2 January, 2015 - 00:00
Unfortunately, 2014 was another slow year at the Monadnock Valley Press, the public-domain website and small-scale publishing house I run on the side. Back in January of last year I changed jobs, so I was just as busy as ever (perhaps even more so).

Peter Saint-Andre: Notes Toward The Upland Farm

Planet Jabber - 24 December, 2014 - 00:00
Four months ago on August 24th, I made the following notes in my journal as a rough outline of my planned book on Thoreau, now tentatively entitled The Upland Farm: Thoreau on the Art of Living (since there's already a book entitled Walking With Thoreau). Although in my previous thematic exploration I had envisioned the book as a set of four seasonal walks, at the moment I am pondering a journal entry for each month, along with one poem for each season. Here are the notes...

Ignite Realtime Blog: Discontinue Igniterealtime subversion server, migration to Github

Planet Jabber - 17 December, 2014 - 16:00

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

  • kraken
  • transports
  • wildfire


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!

ejabberd: ejabberd 14.12

Planet Jabber News - 17 December, 2014 - 14:36

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

read more

Distribuir contenido