Feed aggregator

Monal IM: Don’t upgrade to Monal 2.9.2

Planet Jabber - Wed, 2016-11-09 03:06

Xcode 8 and iOS 10 have introduced a change that breaks a deprecated feature  Monal uses to maintain connectivity. Do not update to 2.9.2, the app does not run in the background anymore. I will submit a build soon that will hopefully get the app working again.

Categories: Jabber

Tigase Blog: Tigase on Raspberry Pi

Planet Jabber - Tue, 2016-11-08 20:34

Tigase XMPP Server is a Java-based XMPP communications software. Because Java is nearly ubiquitous, and not platform specific, the hardware that Tigase can run on is wide and varied.

Categories: Jabber

Prosodical Thoughts: Prosody 0.9.11 released

Planet Jabber - Thu, 2016-11-03 20:26

We are pleased to announce a new minor release from our stable branch.

This release contains a whole bunch of bug fixes, a brief summary of them follows:

  • HTTP parser: Improve buffering of incoming HTTP data and add size limits (#603)
  • sessionmanager: Fix for an issue which caused people to be kicked from conferences if mod_smacks was enabled (#648)
  • Dependencies: Workaround for compatibility with LuaSec 0.6 (#749)
  • MUC: Accept missing form as "instant room" request (#377)
  • C2S: Fix issues with destroying disconnected connections (#590, #641)
  • mod_privacy: Fix selection of the top resource(s) (#694)
  • mod_presence: Make sure both users get each others presence after adding each other (#673)
  • mod_http_files: Fix traceback when serving a non-wildcard path (#611)
  • mod_http_files: Preserve a trailing slash in paths (#639)
  • util.datamanager: Fix error handling (#632)
  • net.server_event: Fix internal socket API to allow writing from socket.ondrain callback (#661)
  • net.server_event: Fix timeout (commit)
  • net.server_event: Fix traceback due to write during TLS handshake (commit)
  • net.server_event: Fix buffer length check (commit)

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

Categories: Jabber

yaxim: Registration Repaired

Planet Jabber - Wed, 2016-11-02 11:28

In the last three months, it was not possible to register new accounts on yax.im. This issue has been resolved now.

On 2016-07-27, the service was upgraded to the experimental prosody 0.10 branch, to allow support for XEP-0313: Message Archive Management and for its better MUC implementation.

Unfortunately, the upgrade also introduced prosody bug #724, where a logic error causes new user registrations to fail, except for spammer accounts. Because the yax.im admin was not aware of this and failed to see the signs of stagnation as well as angry user reports, it took over three months to find and fix the issue. Sorry!

The good news is: yax.im is accepting new users again! If you are running yaxim and your registration attempt has failed, please uninstall & reinstall the app or clear the app data to perform a new registration.

Categories: Jabber

Daniel Pocock: FOSDEM 2017 Real-Time Communications Call for Participation

Planet Jabber - Wed, 2016-10-26 06:39

FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2017 takes place 4-5 February 2017 in Brussels, Belgium.

This email contains information about:

  • Real-Time communications dev-room and lounge,
  • speaking opportunities,
  • volunteering in the dev-room and lounge,
  • related events around FOSDEM, including the XMPP summit,
  • social events (the legendary FOSDEM Beer Night and Saturday night dinners provide endless networking opportunities),
  • the Planet aggregation sites for RTC blogs
Call for participation - Real Time Communications (RTC)

The Real-Time dev-room and Real-Time lounge is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, peer-to-peer, privacy and encryption. The dev-room is a successor to the previous XMPP and telephony dev-rooms. We are looking for speakers for the dev-room and volunteers and participants for the tables in the Real-Time lounge.

The dev-room is only on Saturday, 4 February 2017. The lounge will be present for both days.

To discuss the dev-room and lounge, please join the FSFE-sponsored Free RTC mailing list.

To be kept aware of major developments in Free RTC, without being on the discussion list, please join the Free-RTC Announce list.

Speaking opportunities

Note: if you used FOSDEM Pentabarf before, please use the same account/username

Real-Time Communications dev-room: deadline 23:59 UTC on 17 November. Please use the Pentabarf system to submit a talk proposal for the dev-room. On the "General" tab, please look for the "Track" option and choose "Real-Time devroom". Link to talk submission.

Other dev-rooms and lightning talks: some speakers may find their topic is in the scope of more than one dev-room. It is encouraged to apply to more than one dev-room and also consider proposing a lightning talk, but please be kind enough to tell us if you do this by filling out the notes in the form.

You can find the full list of dev-rooms on this page and apply for a lightning talk at https://fosdem.org/submit

Main track: the deadline for main track presentations is 23:59 UTC 31 October. Leading developers in the Real-Time Communications field are encouraged to consider submitting a presentation to the main track.

First-time speaking?

FOSDEM dev-rooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the dev-room administrators personally if you would like to ask any questions about it.

Submission guidelines

The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:

  • the purpose of your talk
  • any other talk applications (dev-rooms, lightning talks, main track)
  • availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes, presentations aimed at developers of free and open source software about RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the dev-room administrators. As the two previous dev-rooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate.

Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used.

Volunteers needed

To make the dev-room and lounge run successfully, we are looking for volunteers:

  • FOSDEM provides video recording equipment and live streaming, volunteers are needed to assist in this
  • organizing one or more restaurant bookings (dependending upon number of participants) for the evening of Saturday, 4 February
  • participation in the Real-Time lounge
  • helping attract sponsorship funds for the dev-room to pay for the Saturday night dinner and any other expenses
  • circulating this Call for Participation (text version) to other mailing lists

See the mailing list discussion for more details about volunteering.

Related events - XMPP and RTC summits

The XMPP Standards Foundation (XSF) has traditionally held a summit in the days before FOSDEM. There is discussion about a similar summit taking place on 2 and 3 February 2017. XMPP Summit web site - please join the mailing list for details.

We are also considering a more general RTC or telephony summit, potentially in collaboration with the XMPP summit. Please join the Free-RTC mailing list and send an email if you would be interested in participating, sponsoring or hosting such an event.

Social events and dinners

The traditional FOSDEM beer night occurs on Friday, 3 February.

On Saturday night, there are usually dinners associated with each of the dev-rooms. Most restaurants in Brussels are not so large so these dinners have space constraints and reservations are essential. Please subscribe to the Free-RTC mailing list for further details about the Saturday night dinner options and how you can register for a seat.

Spread the word and discuss

If you know of any mailing lists where this CfP would be relevant, please forward this email (text version). If this dev-room excites you, please blog or microblog about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your blog to the planet site administrators:

Planet site Admin contact All projects Free-RTC Planet (http://planet.freertc.org) contact planet@freertc.org XMPP Planet Jabber (http://planet.jabber.org) contact ralphm@ik.nu SIP Planet SIP (http://planet.sip5060.net) contact planet@sip5060.net SIP (Español) Planet SIP-es (http://planet.sip5060.net/es/) contact planet@sip5060.net

Please also link to the Planet sites from your own blog or web site as this helps everybody in the free real-time communications community.


For any private queries, contact us directly using the address fosdem-rtc-admin@freertc.org and for any other queries please ask on the Free-RTC mailing list.

The dev-room administration team:

Categories: Jabber

Florian Schmaus: Designing a DNSSEC application API

Planet Jabber - Wed, 2016-10-26 00:00
Posted on October 26, 2016 Tags: dnssec, xmpp

I’m intending to apply a patch adding DNSSEC support to Smack, a XMPP client library, in the near feature. And since DNSSEC support in application protocol libraries is still uncommon, I thought it might be a good idea to share the principles how the API was designed.


DNSSEC authenticates DNS answers, positive and negative ones. This means that if a DNS response secured by DNSSEC turns out to be authentic, then you can be sure that the domain either exists, and that the returned resource records (RRs) are the ones the domain owner authorized, or that the domain does not exists and that nobody tried to fake its non existence.

The tricky part is that an application using DNSSEC can not determine whether a domain uses DNSSEC, does not use DNSSEC or if someone downgraded your DNS query using DNSSEC to a response without DNSSEC.


I like to keep APIs I design as simple as possible to use for the user. Thus Smack’s DNSSEC API simply extends the already existing ConnectionConfiguration used to – you guessed it – configure XMPP connections by a single method:

ConnectionConfiguration.setDnssecMode(DnssecMode dnssecMode);

where DnssecMode is an enum defined as follows:

enum DnssecMode { disabled, needsDnssec, needsDnssecAndDane, }

The user simply calls config.setDnssecMode(DnssecMode.needsDnssec) and Smack will only connect to an XMPP service if all involved DNS resource recordes could be verified using DNSSEC.

You may noticed the ...AndDane variant of the enum. If this mode is used, then Smack will not only require DNSSEC, but also require DANE (RFC 6598) in order to verify the service’s TLS certificate.

Desiging for a good UI and UX The Issue

The issue with the DnssecMode API exposed by Smack is that an application should never have to ask the end-user if it’s XMPP account is secured by DNSSEC. There should be no questionare, checkbox or whatever about this feature. The best UI regarding a option is if there is none, i.e., if it just works out of the box.

A possible solution

So what should applications do? The answer is simple and similar to “HTTP Strict Transport Security” (HSTS, RFC 6797) used for HTTP(S) connections. Instead of asking the user if DNSSEC is available, they should check for DNSSEC support on every connection attempt. Once DNSSEC support has been discovered, the application uses the needsDnssec mode for all future connection attempts.

An analysis

Of course this scheme is not without drawbacks. First, it is possible that an attacker downgrades the DNS responses to non-DNSSEC. Depending on where the attacker sits in the path between the user and its service, this may always be possible for the attacker or only if the user’s device uses a certain network. The downgrade attack also becomes impossible with this scheme after the application was at least once able to connect to the service using DNSSEC.

Furthermore, if the user’s service needs to drop DNSSEC support for whatever reason (technical, political, …), then the user possible gets a message that the connection failed because something named “DNSSEC” was not avaialble. As with most security concepts, it is hard for the average user to asses situation and take the approbiate action. Of course, the application could ask the user to contact the service provider and ask if DNSSEC was indeed disabled before continuing the connection attempt.

But ideally, service providers would never drop DNSSEC support and the application would simply start a new connection attempt after a failed one caused by the lack of DNSSEC. This is similar to how most applications would (or should) treat a STARTTLS downgrade attack: Simply retry until the demanded security gurantees are fullfiled. Then the user doesn’t have to deal with technical error messages.

Note that the exact same scheme can be used with the needsDnssecAndDane mode. Once DNSSEC and a TLSA RR has been discovered for the service and was successfully used to verify the TLS connection, the application should always use the needsDnssecAndDane mode.

Why not in Smack?

The attentive reader may wonder why I did not implement the described mechanism in Smack, instead of having the application deal with it. I’d really love to do so, but Smack has no API and mechanism for saving a connection state to persistent storage. This would be required for the described scheme. Such a mechanism planned to come with Smack 4.3 though.

Categories: Jabber

Ignite Realtime Blog: Starting the Ignite Realtime Foundation

Planet Jabber - Fri, 2016-10-21 13:39

A few months ago, I wrote about the relocation of our community. The bits and bolts that power our community have since been migrated, and all is running wel. During that progress, we had a couple of awkward moments along the lines of: "to whom will Jive transfer ownership of the DNS records for Ignite?" We started discussing that topic, and concluded that it would be good to have a legal entity to represent our community.


We've been working on a plan ever since, that today, I'd like to share with you. We're planning to start a foundation, the Ignite Realtime Foundation. Its objective: to promote, support and advance development of software in the Ignite Realtime Open Source community.


If you're interested in this effort, have questions, or want to contribute in effort or resources, please reach out. We've set up a new chat room at irf@conference.igniterealtime.org that we use for discussions on the subject.

Categories: Jabber

Daniel Pocock: Choosing smartcards, readers and hardware for the Outreachy project

Planet Jabber - Thu, 2016-10-20 07:25

One of the projects proposed for this round of Outreachy is the PGP / PKI Clean Room live image.

Interns, and anybody who decides to start using the project (it is already functional for command line users) need to decide about purchasing various pieces of hardware, including a smart card, a smart card reader and a suitably secure computer to run the clean room image. It may also be desirable to purchase some additional accessories, such as a hardware random number generator.

If you have any specific suggestions for hardware or can help arrange any donations of hardware for Outreachy interns, please come and join us in the pki-clean-room mailing list or consider adding ideas on the PGP / PKI clean room wiki.

Choice of smart card

For standard PGP use, the OpenPGP card provides a good choice.

For X.509 use cases, such as VPN access, there are a range of choices. I recently obtained one of the SmartCard HSM cards, Card Contact were kind enough to provide me with a free sample. An interesting feature of this card is Elliptic Curve (ECC) support. More potential cards are listed on the OpenSC page here.

Choice of card reader

The technical factors to consider are most easily explained with a table:

On disk Smartcard reader without PIN-pad Smartcard reader with PIN-pad Software Free/open Mostly free/open, Proprietary firmware in reader Key extraction Possible Not generally possible Passphrase compromise attack vectors Hardware or software keyloggers, phishing, user error (unsophisticated attackers) Exploiting firmware bugs over USB (only sophisticated attackers) Other factors No hardware Small, USB key form-factor Largest form factor

Some are shortlisted on the GnuPG wiki and there has been recent discussion of that list on the GnuPG-users mailing list.

Choice of computer to run the clean room environment

There are a wide array of devices to choose from. Here are some principles that come to mind:

  • Prefer devices without any built-in wireless communications interfaces, or where those interfaces can be removed
  • Even better if there is no wired networking either
  • Particularly concerned users may also want to avoid devices with opaque micro-code/firmware
  • Small devices (laptops) that can be stored away easily in a locked cabinet or safe to prevent tampering
  • No hard disks required
  • Having built-in SD card readers or the ability to add them easily
SD cards and SD card readers

The SD cards are used to store the master private key, used to sign the certificates/keys on the smart cards. Multiple copies are kept.

It is a good idea to use SD cards from different vendors, preferably not manufactured in the same batch, to minimize the risk that they all fail at the same time.

For convenience, it would be desirable to use a multi-card reader:

although the software experience will be much the same if lots of individual card readers or USB flash drives are used.

Other devices

One additional idea that comes to mind is a hardware random number generator (TRNG), such as the FST-01.

Can you help with ideas or donations?

If you have any specific suggestions for hardware or can help arrange any donations of hardware for Outreachy interns, please come and join us in the pki-clean-room mailing list or consider adding ideas on the PGP / PKI clean room wiki.

Categories: Jabber

XMPP Radar Newsletter #15

ProcessOne Blogs - Tue, 2016-10-18 09:29
Here are the links we found most interesting in September: ejabberd 16.09 released We are happy to introduce our new ejabberd release, ejabberd 16.09. As usual it includes many bug fixes and improvements. But most of all, it includes excellent student work done for Google Summer of Code program. Thanks to Anna Mukharram and Gabriel […]
Categories: People

ProcessOne: XMPP Radar Newsletter #15

Planet Jabber - Tue, 2016-10-18 09:29

Here are the links we found most interesting in September:

ejabberd 16.09 released

We are happy to introduce our new ejabberd release, ejabberd 16.09. As usual it includes many bug fixes and improvements. But most of all, it includes excellent student work done for Google Summer of Code program. Thanks to Anna Mukharram and Gabriel Gatu for their contributions.

Designing a modern messaging service with ejabberd

In this video, Mickaël Rémond summarises important principles developers need to be aware of when building their own modern XMPP messaging platform. The video was recorded at ejabberd Advanced Erlang Workshop in Paris.

Jesse Kline: Google gives the world another video conferencing app that won’t let you talk to all your friends

What if the world’s multitude of telephone networks weren’t compatible with one another — if the average Canadian household needed to have three telephone lines, one to talk to Telus customers in Western Canada, another to connect with Bell customers in the east and a third to chat with family in the U.S.?

XMPP chat plugin for Unreal Engine 4

Descendent Studios announced the open-source release of several Unreal Engine 4 plugins they developed for their games, including XMPP chat support.

SAP to invest $2.2B to expand its Internet of Things business

With Gartner Inc. expecting enterprise investment in connected devices and related technologies to reach $1.4 trillion per year by 2020, it’s no surprise that IT vendors are so enthusiastic about the trend.

An open source approach to securing The Internet of Things

At the IoT Evolution 2016 conference in Las Vegas, a group of industry experts gathered to discuss security for the Internet of Things, with a focus on embedded devices.

7 surprising facts about open rates for push notifications

Tapjoy, the mobile marketing company, has come up with seven surprising facts about the open rates for push notifications. Push notifications are a common way to get users to pay attention to an app.

Categories: Jabber

ProcessOne: XMPP Radar Newsletter #14

Planet Jabber - Tue, 2016-10-18 09:19

Here are the links we found interesting in August:

ejabberd 16.08

This new release is the culmination of several months of work to improve your experience using ejabberd. It contains as usual a lot of small bug fixes and some enhancements.

Phishing Campaign Uses XMPP to Exfiltrate Compromised Data

Cyber-criminals dabbling in phishing campaigns are experimenting with a new method of exfiltrating data from phishing websites, relying on the Jabber service to send data to their XMPP accounts, according to a report shared with Softpedia by PhishLabs.

Data Finds Pictures Boost Direct Response Rates for Push Notifications 56%

Ahead of the final release of Apple’s iOS 10 and its support for Rich Notifications – where images, video, audio, GIFs and interactive buttons are embedded directly within push notifications – Urban Airship revealed initial performance analysis of similar big picture style notifications on Android.

The Chat Room Roots of Social Reality in VR

In an interview at Code Conference earlier this summer, Facebook CTO Mike Schroepfer took a moment to wax poetic about the possibilities of virtual reality. The prospect of virtual reality conference calls might seem incredibly futuristic, if not dystopic. But the idea of meeting in a virtual place to just, you know, hang, dates back to the early aughts.

Is IoT Security a Ticking Time Bomb?

Ready or not, the Internet of Things (IoT) is here. No longer just a buzz term, it’ll continue to grow at an unprecedented pace over the next few years. History shows that most fast-growth technology solutions focus on solving business problems first; security is an afterthought.

Skyscanner and Skype: world’s first group chat travel bot

Planning trips with a group of friends can sometimes be a tricky task, so to make life a little easier Skyscanner joined forces with Skype to build the first travel search chat bot for the Skype platform. This new tool is the first to offer interaction in a group chat setting.

Categories: Jabber

Peter Saint-Andre: Chocolate Bark

Planet Jabber - Sat, 2016-10-15 00:00
Because I love dark chocolate and almonds, I decided to start making my own chocolate bark. Turns out it's very easy and also delicious. Here's how I do it.
Categories: Jabber

Peter Saint-Andre: Ethics and Politics Revisited

Planet Jabber - Fri, 2016-10-14 00:00
The continuing disclosure of disgraceful conduct (past and present) by the atrocious candidates nominated for President by both the Democrats and the Republicans has led me to reflect further on the relationship between ethics and politics. In particular, if I care about character and ethical principles then it seems incumbent upon me to cast my vote for the candidate with the greatest personal integrity. Not the lesser of two evils - why would align myself with evil? - but the most reasonable, honest, principled person on the ballot. This year for President that person is Gary Johnson. He also happens to be a moderate libertarian, which is how I've described myself for a number of years. If I can find the time over the next few weeks, I will write in more depth about the importance of a moderate libertarian approach to the future of American politics.
Categories: Jabber

Daniel Pocock: Outreachy and GSoC 2017 opportunities in Multimedia Real-Time Communication

Planet Jabber - Tue, 2016-10-11 18:53

I've proposed Free Real-Time Communication as a topic in Outreachy this year. The topic will also be promoted as part of GSoC 2017.

If you are interested in helping as either an intern or mentor, please follow the instructions there to make contact.

Even if you can't participate, if you have the opportunity to promote the topic in a university or any other environment where potential interns will see it, please do so as this makes a big difference to the success of these programs.

The project could involve anything related to SIP, XMPP, WebRTC or peer-to-peer real-time communication, as long as it emphasizes a specific feature or benefit for the Debian community. If other Outreachy organizations would also like to have a Free RTC project for their community, then this could also be jointly mentored.

Categories: Jabber

Erlang Solutions: MongooseIM 2.0.0beta2: the power of an XMPP platform, with the simplicity of a REST API

Planet Jabber - Tue, 2016-10-11 02:47

We are thrilled to announce the MongooseIM platform version 2.0.0beta2. MongooseIM platform 2.0.0beta2 is about one massive change: a REST API, both for backend integration, and for client/server development. This is a major step towards the game-changing version 2.0.0, which will be released in the coming weeks. MongooseIM 2.0.0 will tremendously lower the barrier of entry to our platform for most developers worldwide.

REST API for backend integration

Following popular and obvious demand, MongooseIM now implements a new REST API, for backend integration.

Integration problem for backend developers and DevOps

The MongooseIM platform is mostly used in very large and complex infrastructures, in various types of data centers (cloud, bare metal, or hybrid). In that context, there is always a high need for tight integration and coupling between the MongooseIM platform, and the full ecosystem in the data center.

For most backend developers, as well as for DevOps, this is very difficult as such an integration requires understanding the powerful hooks system in the core of MongooseIM server or the command line interface, and how they relate to the purpose of the infrastructure.

It was thus very difficult to develop interconnected pieces of architectures.

The obvious solution: a REST API

Since most techies use modern REST APIs these days, this was the obvious and natural choice, and our customers and prospects confirmed and supported this thinking.

The MongooseIM platform now offers a very simple backend REST API:

  • management: users and sessions
  • messaging:
    • send one-to-one messages
    • send group chat messages (both MUC and MUC light)
    • retrieve users’ message history

The documentation is simply the de facto standard: Swagger. With Swagger, it is even more handy, as many code generators can help build code from scratch, with little human customisation. This doc is supporting the Open API Specification. Check out the backend REST API of MongooseIM.

Ease of development and maintenance, plus consistency in infrastructure

As a result, it is now much easier for backend developers to write code against MongooseIM, and maintain it. Also it is much easier for DevOps to interconnect MongooseIM with other servers. Overall, CTOs will be thrilled to have a more consistent set of backends that all discuss over REST APIs, for a seamless infrastructure maintenance experience.


The list of methods made available today is quite narrow, and it is on purpose: we will extend the MongooseIM REST API methods to answer your needs.

REST API for the clients developers

This part may sound less understandable, maybe a bit “revolutionary” and unorthodox for an XMPP platform. To be honest, we thought a lot about it, and hesitated for a long time. But our customers and prospects have sent the signal loud and clear.

Putting it simply: we are not breaking out of XMPP! We are offering the power of an XMPP platform to REST API developers worldwide!

Let us walk you through this thinking.

The problem with XMPP and XML

The MongooseIM platform is based on the XMPP protocol and philosophy. And XMPP is awesome. It is an open standards protocol, backed by both the XSF and the IETF, offering high flexibility and outstanding extensibility. It is always surprising in many ways, as mature features often reveal themselves as highly efficient in modern and contemporary contexts.

XMPP has evolved a lot over the years, to the point that it can look complex and too massive for a lot of developers. As a result, it might seem discouraging to learn so much for most developers.

Additionally, XMPP relies on XML, which is not very trendy, to say the least. The crowds massively prefer JSON these days. We won’t argue here.

As a result, a large audience of developers do not like XMPP nor XML anymore. The consequence for business owners and recruiters is that it has become difficult and painful to find good (and available) XMPP developers. It would be a missed opportunity, as the MongooseIM platform is highly performant and flexible.

The REST API solution for client/server developers

The MongooseIM platform now implements a very simple REST API for client-side developers, with JSON format.

The current implementation covers a minimal set of use cases:

  • authentication
  • send one-to-one messages
  • retrieve message history

In other words, we have created a REST API interface to the MongooseIM platform, by removing all the complexities of XMPP, and by switching from XML to JSON. We have kept only the bare minimal: all you need to quickstart a highly efficient application, with a flexible and powerful backend that will scale to millions.

The documentation is also available on Swagger: check out the client REST API of MongooseIM.

Lowering the barrier of entry to MongooseIM

This client/server REST API with JSON format allows most client-side developers to access the power and massive scalability of MongooseIM, yet maintaining a very simple and efficient codebase on the client.

It is now possible to build massively scalable chat system with the MongooseIM platform, yet keeping a very fast time-to-market, with minimal initial developers investment, virtually no learning curve, and lowering the risk of developer turnover.

It is especially true for applications builders who want to add chat (instant messaging features) in their multi-screen apps, for higher and sustainable acquisition, retention, and engagement.


Please send your needs and pain points, in order to grow further the feature set. That way it will be easier for your apps to sustain your growth.

We are even planning a custom hosting solution, and a standard SaaS. Please contact us for more information.

MongooseIM = XMPP + REST API

A simple REST API with JSON format might sound antagonist to XMPP. Our client-side REST API is an addition to XMPP in MongooseIM. Messaging features will all remain available using the XMPP protocol, and more and more will be available through our REST API.

In other words, we keep the powerful XMPP protocol, we just add a simple client/server REST API for more developers and simpler coding.

Documentation additions

A lot of developers, devops, sysadmins, and CTOs just have difficulties understanding how things work at a high level. As MongooseIM has quite a different architecture than the more classical web applications, there was indeed some explanations due here on the high-level architecture.

We added explanations and schemas for some key concepts, such a transient vs persistent data, nodes joining or leaving a cluster, RDBMS vs NOSQL data storage.

We also created a few new documentation pages to explain the basics on some of the clustering considerations, and also detailed to global architectures, like multi-datacenter setups for very large deployments.

Our contributions to the ecosystem (outside the scope of the MongooseIM server) were not clear, they are documented now. We contribute to both open standards, and open source software, whether we maintain it, or it is maintained by friends. For example, we contribute to XMPPFramework for iOS, and Smack for Android. We now offer a consistent set of features over MongooseIM server, Smack, and XMPPFramework: a given feature we support is available and tested on the three.

Please read our draft roadmap, offering enhanced visibility over where the MongooseIM platform is going next. Feel free to comment on it, and influence the journey!

Many thanks to our contributors on the MongooseIM server

During this development cycle, we received some code contributions to server. Special thanks to our contributors: @bernardd, @igors, @arkdro

Our contributions to the ecosystem

We have again contributed to XMPPFramework for iOS, Smack for Android, and Movim.

Many thanks to Florian Schmaus (Smack @Flowdalic), Chris Ballinger (XMPPFramework @chrisballinger), and Timothée Jaussoin (Movim @edhelas) for the strong support in our contributions with their kindness, availability, openness, and guidance.

Call for tests and comments: REST API, PubSub, MUC light

This 2.0.0beta2 will be our last beta before 2.0.0, so this is a call for tests, all comments welcome. We encourage everyone to play with the REST API on both backend and clients, but also MongooseIM 2.0.0beta1’s PubSub and MUC light.

Upcoming 2.0.0

With all your feedback, we will release the full, final 2.0.0 in the coming weeks, roughly with the same featureset, with the obvious additional bugfixes and polishing.

This is the last beta before the 2.0.0 version that will be available in the coming weeks. Please feel free to download MongooseIM 2.0.0beta2 and test it extensively. Some rough edges have already been fixed, and we encourage to report any further inconvenience.

We will not add any big new feature before our 2.1.x series, as after the 2.0.0 release we will enter maintenance mode, with bug fixing and optimisations, with probable 2.0.1 and 2.0.2 versions.

Get the fresh news!

Meanwhile, get our fresh news: subscribe our announcement mailing list.

Categories: Jabber

Daniel Pocock: DVD-based Clean Room for PGP and PKI

Planet Jabber - Mon, 2016-10-10 19:25

There is increasing interest in computer security these days and more and more people are using some form of PKI, whether it is signing Git tags, signing packages for a GNU/Linux distribution or just signing your emails.

There are also more home networks and small offices who require their own in-house Certificate Authority (CA) to issue TLS certificates for VPN users (e.g. StrongSWAN) or IP telephony.

Back in April, I started discussing the PGP Clean Room idea (debian-devel discussion and gnupg-users discussion), created a wiki page and started development of a script to build the clean room ISO using live-build on Debian.

Keeping the master keys completely offline and putting subkeys onto smart cards and other devices dramatically lowers the risk of mistakes and security breaches. Using a read-only DVD to operate the clean-room makes it convenient and harder to tamper with.

Trying it out in VirtualBox

It is fairly easy to clone the Git repository, run the script to create the ISO and boot it in VirtualBox to see what is inside:

At the moment, it contains a number of packages likely to be useful in a PKI clean room, including GnuPG, smartcard drivers, the lightweight pki utility from StrongSWAN and OpenSSL.

I've been trying it out with an SPR-532, one of the GnuPG-supported smartcard readers with a pin-pad and the OpenPGP card.

Ready to use today

More confident users will be able to build the ISO and use it immediately by operating all the utilities from the command line. For example, you should be able to fully configure PGP smart cards by following this blog from Simon Josefsson.

The ISO includes some useful scripts, for example, create-raid will quickly partition and RAID a set of SD cards to store your master key-pair offline.

Getting involved

To make PGP accessible to a wider user-base and more convenient for those who don't use GnuPG frequently enough to remember all the command line options, it would be interesting to create a GUI, possibly using python-newt to create a similar look-and-feel to popular text-based installer and system administration tools.

If you are keen on this project and would like to discuss it further, please come and join the new pki-clean-room mailing list and feel free to ask questions or share your thoughts about it.

One way to proceed may be to recruit an Outreachy or GSoC intern to develop the UI. Before they can get started, it would be necessary to more thoroughly document workflow requirements.

Categories: Jabber

Mathieu Pasquet: Poezio 0.10

Planet Jabber - Sun, 2016-10-09 16:32

Originally the next version on the roadmap was 1.0, but I don’t feel like giving a 1.0 tag to the current state of things; so, without further ado: I am pleased to announce that poezio 0.10 has just been released!

Poezio is a terminal-based XMPP client which aims to replicate the feeling of terminal-based IRC clients such as irssi or weechat; to this end, poezio originally only supported multi-user chats.

What's new Performance

Link Mauve spent a sizeable chunk of time to make poezio faster, which makes it nicer and lighter to use in low-powered environments with many contacts and many rooms with many people in it.

A lot of time was spent profiling and cursing python, then writing micro(or not-so-micro)-optimizations. His final goal is to make everything cythonizable, to get even better performance. Thanks a lot to him!

Stream Management (XEP-0198)

Together with fixing the slixmpp plugin for XEP-0198, it was implemented in poezio. It is not enabled by default because it adds overhead and isn’t useful in most poezio use cases (i.e. long-running sessions in a tmux window somewhere on a server), but it can be easily enabled through a config option.

Stream Management (which requires server support) allows a client to restore a session after a disconnection, as long as the server has a sufficiently high timeout value configured. It also allows for more reliability inside a stream, by having acks and sequence numbers interlaced with the stream of normal activity. If sequence numbers don’t match, the entity which sent the missing messages will send it again.

Carbons enabled

It was an oversight, but a big one; carbon copies (XEP-0280) are now enabled by default in poezio 0.10. Carbons allow for a more seamless transition in a multi-device environment by replicating messages sent and received to each device connected.

Commented-out config file

A mistake again; because the options in the config file were uncommented by default, there was no way of checking if a value was there only because it was a default; so there was no way to update default values after someone ran poezio once. Well, there is still no way, but because the options are now commented out, new users will get the default values updates if they didn’t explictly set something else.

The poezio -c command is however available to see which options in your config files differ from the default.

poezio_logs script

Poezio log files adopted a log format close to the mcabber one a long time ago. However, reading logs within poezio is sub-par at best; and while there are plans to remedy to this, it’s still good to be able to read logs without having the custom format cruft around.

So the poezio_logs tool takes a log file path as a parameter and outputs the cleaned-up result to stdout, with some coloration. It can take parameters to remove color, timestamps, or info messages as well.

HTTP Verification (XEP-0070)

The surprise of this release is the arrival of an HTTP Verification tab, which implements XEP-0070 to authenticate HTTP requests using only your JID.

A mediawiki plugin is in the writings, and a wordpress plugin already exists. Because components such as this one talk HTTP, there is no need to add any kind of XMPP support in the application that needs an identity validation; just enter your JID, accept the request on your client, and voilà.

New warning prompt

The previous way of handling a certificate change was really inconvenient, so with HTTP verification implemented, it was easy to just re-use the same tab with a different color scheme in order to have an more user-friendly way to interact (especially since we moved from SHA-1 to SHA-512, which increased the size of the hash by a lot).

Fun with message corrections

It’s more abuse of the protocol than anything else, but since we like writing funny plugins, here are two new ones:

  • marquee, to replicate the behavior of the <marquee/> tag by moving text from left to right in a loop, all in the same message using corrections
  • dice, to roll a number of unicode dice for a time interval, once again using message corrections.
Client State Indication

CSI (XEP-0352) is a mobile-oriented extension that requires both client and server support, and lets the client tell the server that it’s "off" (for example, a mobile client while the screen is off and the phone is in the pocket).

It surprisingly applies well to poezio, thanks to the screen_detach plugin, which is either in attached or detached state.

Toggling this active or inactive state leaves the server free to enable a number of filters to reduce data transfer between the client and server. For example, it could filter all presences received while the client was off.

A "csi" plugin was also added with explicit commands to set or unset that status.


VCard-Temp (XEP-0054) support is still a desirable thing, and this version adds a plugin to view vcard information from remote entities. It’s still a little rough because it only implements a subset of the elements in a vcard, and re-uses a poezio tab that wasn’t designed for readonly data, but it’s getting there.

Of course, once vcard-temp is really done, vcard4 (XEP-0292) support is next.

Bits of Binary

While we still have no real file transfer abilities, we now have a Bits of Binary (XEP-0231) plugin, which allows for small in-band file transfers between clients. Considering stream bandwidth is often limited to a few kilobytes per second for good reasons, it should be used sparingly, but it’s perfect for sending small files.

And many more

Of course, there are many more commits for new features or bug fixes, with a big refactor that removed an ugly python path manipulation hack, minor UI fixes that save some screen space and provide better consistency with themes, no instant reconnect loops on specific error conditions, etc… You can check the CHANGELOG or the git history for more reasons to upgrade.


Just like 0.9, poezio 0.10 depends on slixmpp, which requires aiodns and pyasn1, and can make use of cython (in which case libidn will be required, as well as its headers during the compilation).


Beside myself (mathieui), louiz’, and Link Mauve, I want to thanks the other contributors, eijebong, Lasse Aagren, Frédéric Meynadier, Nicolas Braud-Santoni, Lancelot SIX, Luke Marlin, for their contributed features and fixes.

I also want to thank all users/testers that report bug and suggestions for improvements, either through constructive remarks on the chatroom or bug reports.


As always, if you notice an unreported bug still unfixed in latest master, please report it, thank you.

Categories: Jabber

Tigase Blog: XEP-0084 Support Added

Planet Jabber - Fri, 2016-10-07 00:53

User Avatar Support Added

Categories: Jabber

Mathieu Pasquet: slixmpp v1.2

Planet Jabber - Sun, 2016-10-02 16:22

Exactly one year after the release of slixmpp 1.1, it is time to announce the release of slixmpp version 1.2.

slixmpp is an asyncio-based python (3.4+) library for XMPP, started from the SleekXMPP sources.

Notable changes
  • Link Mauve put a huge focus on performance and micro-optimizations, while also modernizing the codebase (deprecated aliases, etc)
  • New XEPs plugins: XEP-0070, XEP-0256, XEP-0333, XEP-0334, XEP-0352
  • Fixed the XEP-0198 plugin.
  • Fixed legacy SSL
  • Updated documentation
  • More fixes (tracebacks, or more subtle errors due to asyncio)

Thanks to all the contributors (listed in the README) for this release!

Categories: Jabber

Ignite Realtime Blog: Spark 2.8.1 Released

Planet Jabber - Sat, 2016-10-01 14:42

The Ignite Realtime community has just released Spark 2.8.1 and it can be downloaded from Ignite Realtime: Downloads .


This is a bugfix release for 2.8.0, which has introduced a huge overhaul and created a few new issues. Many users had problems with login after upgrading to 2.8.0. This won't change with 2.8.1. It is not a bug, but rather an incorrect setup. Admittedly, this was introduced because of lack of security check in older Spark\Smack versions. But we can't leave Spark blind to bad or forged certificates (in the age of security breaches and moving all the web to TLS). So, if you have this problems, please read Login issues since Spark 2.8.0 . 2.8.1 is introducing an option "Disable certificate hostname verification (not recommended)" in the Advanced settings of the Login screen. If you can't fix your setup or want a temporary workaround, you can use it. But be warned, that you will make yourself (or your users) less secure. 2.8.0 also introduced new setting "Accept all certificates" in the same place. It was enabled by default for those upgrading from 2.7.7. It automatically accepts self-signed and some other incorrect certificates (expired, etc.). This was done to make 2.8.0 backwards compatible, if you were using self-signed certificates provided by Openfire. This setting will stay enabled after 2.8.1 update. But there is a plan to make it disabled by default for new installations in 2.8.2 version.


For a complete list of changes please check Spark Changelog


As usually we encourage new developers to join Spark project and provide patches. Those familiar with Smack can join the development easier, as we are now using the latest version. Patches can be attached in the forums or submitted as PRs on GitHub.


Here are the contributors to this release (besides myself):

nicoben (Nico Ben) · GitHub  updated Italian translation

speedy  added option to login with not matching certificate's hostname, fixed showing incorrect errors when logging in and empty profile fields issue

Alexander198961 (Aleksander Kovtunenko) · GitHub  fixed links opening in KDE environment

Guus der Kinderen  fixed various parts of Spark to behave correctly or log errors


Important information for SSO (Single Sign On) users, if they are using SRV records: SSO (Single Sign On) configuration changes since Spark 2.8.0

[SIP phone] SIP plugin is not working since the Smack 4 update.

[Voice Chat] Jingle (PC to PC) calls are not working at this point.

[Linux] Flashing plugin is not working on Linux systems.


Here are sha1 checksums for the downloads:

7ab1df8764529b8bfc070b259878470ccbd7640c spark_2_8_1.dmg

bbd029caeb12fc4d9ea6e87b37a5f0377c6a1c29  spark_2_8_1.exe

41b485146393a38966b2eecb832c795b0f0915a8  spark_2_8_1_online.exe

6c68f083d2e6e303e679b614f10536e4563d272c  spark_2_8_1.tar.gz

751721d241d880d9b7772038ec030230b4ccbb38  spark-2.8.1.rpm

c264ccb4e16b401a1814c43342f31a0a3cf36cc6  spark-2.8.1.src.rpm

91a6dfaaf63ca96a5c69b4eb825d2539adffc1b1  spark_2.8.1.deb

Categories: Jabber
Syndicate content