Agregador de noticias

Erlang Solutions: Welcome to the third generation of Instant Messaging! Part 2/2

Planet Jabber - Hace 9 horas 51 mins

CC by-sa, Creative Commons Attribution-ShareAlike 4.0 international

This is the second and last part of my “Welcome to the third generation of Instant Messaging!” post, you can read part 1 here.

The first generation was lead by ICQ and followed by all its clones and is characterised by multi-window desktop software, with through sporadic internet connection, all centered around the concept of ‘presence’.

The second generation was triggered by the multi-touch smartphone revolution and includes was lead by WhatsApp and followed by all its clones, with the main focus on making chats less synchronous.

This is the third generation.

3rd generation: group messaging

The group messaging revolution began around 2015-2016, with the advent of Slack and HipChat. Other services in the third generation are Zulip, Otalk, Kaiwa, Mattermost, Let's Chat, Rocket.Chat. Since the third genration revolution is still ongoing, observing and understanding what is happening is much harder. We don’t yet have any strong long-term feedback, and the race is ongoing. But again, a new generation, a new disruption is evolving.

a. Continuous computing experience

The context evolved once again. Mobile have overtaken sales of other forms of computer. People use smartphones as their first (sometimes only) device. But, overall, the smartphone revolution calmed down a little. Many companies now practice “BYOD” (“Bring Your Own Device”), allowing employees to use their personal smartphone and laptop for work. People generally use a laptop at work, a tablet on the couch, and a smartphone on their commute, coffee pause, and lunch break, not to mention parties, family dinners and toilet breaks.

b. Presence makes a shy comeback, but remains a secondary feature

We learned that in the 2nd generation presence was missed by users when removed from apps, or still used as a secondary feature. When it comes to presence, there is continuity between 2nd and 3rd generation, but with a slight come back: although presence does not always comes as a central feature, it is only one click or tap away.

c. Mobile AND desktop in the real world

The 3rd generation IMs come in different flavors: the app is available on one or two (or more) mobile platforms and on one or two (or more) desktop platforms. These software pieces may not come with feature parity due to all these apps’ lifecycles, but the overall user experience is mostly there already. On desktop, software is often available in the web browser. And when it comes as desktop software, it is often just the web app that is delivered into a packaged software working on web technologies.

d. Single window mode, for simplicity, and flat design

All the 2nd generation IMs that now provide some desktop experience offer single window software. Not because of the web technologies they are based on, just because multi-window is far too complex for massive user bases.

The responsive design of the few desktop apps and websites of the 2nd generation has been generalised, and consequently brought about the 3rd generation. If you resize your desktop app window to a tiny size, you have a UX close to that of the mobile app (minus multi touch input), when you resize it to average size, you get a tablet-like experience, and when you really enlarge it, you have the full blown desktop experience.

Flat design is the default of the 3rd generation, whether it is done in Apple style, Material design by Google, Metro-style by Microsoft. This is a minimalist UI design genre or language, getting away from the skeuomorphic paradigm, that immitates previous generations’ interfaces. Even 2nd generation apps are now phasing out non-flat design.

e. Group chat is the main core feature

Group apps of the 3rd generation IM naturally prioritise group chats, or at least do not relegate them as a secondary feature. Conceptually, in group apps, the chat rooms or channels are not just an extension of one-to-one chats, but rather one-to-one chats are a downsized version of group chats. That is one very small technical difference from 2nd generation that makes for a totally different user experience.

Other more obvious differences are groups having persistent files and links and stars/favorites, and room/channel notifications. And let’s not forget full text search, but more on that in a bit.

Some may argue that the 3rd generation IM is a return to what IRC was: a group chat at the core. Indeed, but it undeniable that the 3rd generation IM is much more user-friendly and technologically advanced than IRC clients.

f. Continuous devices synchronisation

The 3rd generation is multi-device by default, by nature, and because it is an extension of the 2nd generation which was mostly mobile-only (at least at the beginning), as it completes the devices’ scope with desktop apps. The idea is to offer continuous flow, not only with message sync, but also with unread and file sync, outside the app.

The 3rd generation is still as asynchronous as the 2nd generation, but it adds email notifications. These are slightly delayed notifications (non real-time), for when you can’t participate in conversations. These emails tell you what you have missed, via a bulk of messages at a time. It might not seem like much, but it fills a gap and underlines the missing parts of asynchronicity.

g. Persistence of in-chat files

In-chat media files have stayed and the 3rd generation brought some improvement, with persistent files directories, often materialised in sidebars. This is an advancement over the in-app galleries of the 2nd generation, which only allowed you to scroll through pictures.

The Ffile transfer of the old days might be missing now, for file exchanges in fire-and-forget mode (out-of-chat propose+accept UX), with no archive, and no search. The common workaround is using external, third party file sync services such as DropBox, Box, Google Drive.

h. Voice and video: stagnation or regression

Since 3rd generation apps focus on groups, multi-party VoIP is the target, the Holy Grail that the 2nd generation has not achieved. This is very difficult to achieve, which may be why implementors are taking their time. The goal might be not to disappoint high expectations.

i. Specificities: full text search, stars, integrations’ craze, ChatBots

One of the most prominent - if not the most prominent - features of 3rd generation is full text search of messages and file. One can finally search old messages and conversations, same as you can do with emails. In a multi-device context that can be very useful, for example when you recall the general idea of a conversation but not all the details. Some seek to monetise the archive, by limiting a free user’s searches.

One can also star/favorite or pin almost everything! It started shyly in the 2nd generation, but the 3rd generalised it. Starred/favourited content generally features in sidebars, sometimes adding unnecessary clutter to the overall appearence and UX.

After group focus and search, the integrations’ craze is possibly the most important trait of the 3rd generation. Integrations are hooks or links to third party apps and services. They help fill the gap between these apps and the chat system. It helps avoiding disruptions between chat and other apps: team mabers always have to switch between apps, now they have all in one place and in real-time. It increases retention and engagement on the chat app.

ChatBots are also becoming huge, since they can help with some serious tasks, and even with some fun, unproductive (ahem procrastination) ones, and the underlying AI is evolving rapidly.

Integrations and ChatBots are tightly linked to the ChatOps movement. ChatOps is “everything of the business process on chat”. Integrations and ChatBots progress and refine together, enabling more team fluidity.

Integrations are huge, not only because everybody jumps on the bandwagon, but also because it enables apps become a real marketplace. The 3rd generation IMs are generally selling subscriptions for teams (with free tier), and integrations and ChatBots enlarge their capacity to monetise.

Summary

The third generation made the IM a continuous flow between all your devices, where nothing is ever missed. 3rd generation IM defining traits include: group chat first, full text search, email notifications, integrations and ChatBots.

As it is an ongoing process, the usages will refe during the coming period.

Generation 2.5: specialisation, segmentation

While the 2nd and 3rd generation IMs want to reach the mass market, some 2nd generation apps have chosen more specialised markets. This is the generation 2.5, which sits between generation 2 and generation 3.

Ephemeral messaging

Ephemeral messaging is about self-destructing messages. These could be photo-only or photo-first apps, but also disapearing text messages. Snapchat is the best known example.

Secure messaging

Encryption is at the core. Sometimes, expected features such as multi-device are missing. Encryption is evolving so fast that some apps become obsolete rapidly. Recent, highly publicised concerns surrounding privacy and transparancy will not be resolved quickly, easily or on a supra-national basis.

Mesh networks

Mesh networks use no central servers, rather using mostly the cell network, bluetooth, and wifi. They are used for co-located and synchronous events such as festivals or protests.

Side notes

Here are some general observations, that might not obviously fit in one generation or another.

Account creation and contact management are features that have evolved a lot. And there is no clear pattern shaping up that enables the discerning of a general directions tied to a specific generation.

Message receipts (such as sent, received, read/seen) appeared around the 2nd generation as these imitate the SMS experience, but then disappeared from the 3rd generation. They may yet make a comeback as auditability is clearly important in corporate and regulatory contexts.

Speaking about monetization: the 1st generation was all around ads, and interestingly enough around avatars in Asia. The 2nd generation is about gathering user data for big data and profiling/targetting, and interestingly enough around mobile-local-social marketplaces in eastern countries. The 3rd generation is about building subscription platforms, with integrations and ChatBots marketplaces.

Another interesting trend are the apps adding IM to their core functionnalities, despite not being IM apps. Indeed some apps add basic to complete IM features, in order to generate acquisition, engagement, and retention. To give an example, IM is a helper for the main focus of photo sharing and dating apps.

The adoption and social impact of IM is different: the 1st generation was about reaching a mass market, and is now dead (some zombie apps are still walking around). The 2nd was about the generalisation of IM with an initial focus on mobile, but still with disjointed networks, and incompatible apps. The 3rd generation will probably not take over the 2nd generation since the focus is on groups and collaboration. So 2nd and 3rd generations are here to co-exist for a while, and will probably feed off each other in features and usages. Of course the 3rd generation is still in its infancy, so expect more to come at a fast pace.

As usages and technologies evolve with upcoming generations of users, the experience will continue to evolve rapidly and massively.

Most of these apps offer absolutely not interoperation: you have to create an account to chat with a contact with that app. Of course, the only open standards protocol XMPP enables federation, much like email does: you can send a message to a contact on another service.

Expect some more third generation features to land in the next version of MongooseIM (source code).

Summary table   1st gen: 1998-2008 2nd gen: 2009-2014 3rd gen: 2015-... Most valuable feature Presence and instant chats Always-on mobilility Group collaboration Synchronicity Synchronous Asynchronous Continuous Examples ICQ, Yahho!Messenger, AIM, MSN, Gadu-Gadu, QQ, NateOn WeChat, LINE, WhatsApp, Google Talk/Hangouts, KakaoTalk, Viber Slack, HipChat, Otalk, Kaiwa, Zulip, Mattermost, Let's Chat, Rocket.Chat New features Gadgets Message actions, mentions, stickers Full text search, persistency, integrations Platform Desktop-only Mobile-only, mobile-first Mobile AND laptop Windowing mode Dual-window Full screen Single-window Presence Presence-based Presence is secondary Presence is secondary Group chat Secondary Secondary Central Multiple end points Multi-client Multi-device, account-based Multi-device, account-based Media File transfer (propos+accept) In-chat media In-chat media, with list of media and search Voice Secondary Important Secondary Status Dead Alive and still growing New and growing fast Monetisation Ads Users are the product Subscriptions, integrations Tell us what you think

This was a brief walk through: we over-summarised, and skipped a lot of aspects. Maybe you have spotted some lacking subjects, or you have different observations? Please comment below!

You are always welcome to subscribe to the MongooseIM announcement mailing-list more articles and news about the world of IM.

Fanout Blog: Building a realtime API with RethinkDB

Planet Jabber - 25 April, 2016 - 20:32

RethinkDB is a modern NoSQL database that makes it easy to build realtime web services. One of its standout features is called Changefeeds. Applications can query tables for ongoing changes, and RethinkDB will push any changes to applications as they happen. The Changefeeds feature is interesting for many reasons:

  • You don’t need a separate message queue to wake up workers that operate on new data.
  • Database writes made from anywhere will propagate out as changes. Use the RethinkDB dashboard to muck with data? Run a migration script? Listeners will hear about it.
  • Filtering/squashing of change events within RethinkDB. In many cases it may be easier to filter events using ReQL than using a message queue and filtering workers.

This makes RethinkDB a compelling part of a realtime web service stack. In this article, we’ll describe how to use RethinkDB to implement a leaderboard API with realtime updates. Emphasis on API. Unlike other leaderboard examples you may have seen elsewhere, the focus here will be to create a clean API definition and use RethinkDB as part of the implementation. If you’re not sure what it means for an API to have realtime capabilities, check out this guide.

We’ll use the following components to build the leaderboard API:

Since the server app targets Heroku, we’ll be using environment variables for configuration and foreman for local testing.

Read on to see how it’s done. You can also look at the source.

...

Daniel Pocock: LinuxWochen, MiniDebConf Vienna and Linux Presentation Day

Planet Jabber - 24 April, 2016 - 06:23

Over the coming week, there are a vast number of free software events taking place around the world.

I'll be at the LinuxWochen Vienna and MiniDebConf Vienna, the events run over four days from Thursday, 28 April to Sunday, 1 May.

At MiniDebConf Vienna, I'll be giving a talk on Saturday (schedule not finalized yet) about our progress with free Real-Time Communications (RTC) and welcoming 13 new GSoC students (and their mentors) working on this topic under the Debian umbrella.

On Sunday, Iain Learmonth and I will be collaborating on a workshop/demonstration on Software Defined Radio from the perspective of ham radio and the Debian Ham Radio Pure Blend. If you want to be an active participant, an easy way to get involved is to bring an RTL-SDR dongle. It is highly recommended that instead of buying any cheap generic dongle, you buy one with a high quality temperature compensated crystal oscillator (TXCO), such as those promoted by RTL-SDR.com.

Saturday, 30 April is also Linux Presentation Day in many places. There is an event in Switzerland organized by the local local FSFE group in Basel.

DebConf16 is only a couple of months away now, Registration is still open and the team are keenly looking for additional sponsors. Sponsors are a vital part of such a large event, if your employer or any other organization you know benefits from Debian, please encourage them to contribute.

Florian Schmaus: Alpha release of MiniDNS DNSSEC

Planet Jabber - 22 April, 2016 - 00:00
Posted on April 22, 2016 Tags: dns, xmpp Introduction

Rene just tagged MiniDNS 0.2.0-alpha3 and pushed it to Maven Central. This release includes experimental support for DNSSEC.

About MiniDNS

MiniDNS is an open-source and highly portable DNS resolver written in Java for Android and Java SE runtimes. MiniDNS aims to be lightweight and modular, which makes it different from similar projects like dnsjava.

It is triple licensed. Users can choose the license terms they like from: Apache License 2.0, LGPL 2.1 and WTFPL.

The fastest way to get familiar with MiniDNS is by playing around with its built-in Read-Evaluate-Print-Loop (REPL). Pleaes note that proper support for CNAME / DNAME is not yet implemented.

DNSSEC

The new DNSSEC (DNS Security Extensions) support was added through a Google Summer of Code (GSOC) project in 2015 under the umbrella of the XMPP Standards Foundation (XSF). We would like to thank our skilled student Marvin and Google for making this possible.

DNSSEC has multiple benefits, it not only allows the verification of DNS responses (data origin authentication), but also helps making protocols like HTTP, SMTP, IMAP and XMPP more secure by using DANE.

Multiple open source projects already expressed interested in MiniDNS’s DNSSEC feature: Also Smack, the XMPP client library for Android and Java SE I maintain, will provide experimental support for DANE using MiniDNS soon. Daniel, the author of the popular Android XMPP client Conversations, already a MiniDNS user, also expressed interest in adding support for DANE. And last but not least, Vincent and Dominik of OpenKeychain fame are looking forward to adding support for the OPENPGPKEY record as defined in draft-ietf-dane-openpgpkey.

Other projects are of course welcome as well. But please contact me before using the DNSSEC features of MiniDNS: Again, this is highly experimental code. I will keep you updated about the current state of MiniDNS in this very blog.

Help Wanted

The MiniDNS code has not yet received an extensive security review. As an understaffed open source project without any funding, we don’t have the necessary resources to pay for such a review.

But even if we had the funds, we first need to find someone capable of actually performing such a review. Maybe you know someone or how to help?

Feel free to contact me if you want to help.

Future Release Highlight: Support for the Kitchen Sink RR

With DNSSEC support in the ‘master’ branch, the only killer feature missing is support for the Kitchen Sink Resource Record (KS RR). The KS RR allows “to put complex, bulky, and/or obscurely structured data into the Domain Name System (DNS)”. Combined with DNSSEC this allows signing arbitrary data of any size, allowing for a broad range of possible use cases. Unlike most other pending features in open source projects, we are able to give an exact date when this feature will arrive: 2017-04-01. Stay tuned.

Tigase Blog: Tigase Client Library v3.1.0 Released!

Planet Jabber - 21 April, 2016 - 23:19

Tigase JaXMPP v3.1.0 has been released! Please review the change notes below to see what has changed since our last release.

New Features

Erlang Solutions: Welcome to the third generation of Instant Messaging! Part 1/2

Planet Jabber - 20 April, 2016 - 16:52

CC by-sa, Creative Commons Attribution-ShareAlike 4.0 international

Real-time, synchronous text messaging has come a long way!

In the “old days” (some would call that pre-history), the concept was simple - we used Talk on Unix to log in to a machine remotely and chat with another local user on that machine. There were no chat rooms, authentication, authorisation or basic encryption that seem so obvious, ubiquitous and indispensable today.

Then IRC came as an open standard, introducing multi-party chat rooms as a main feature. Different flavors of non-standard extensions, and disjointed networks soon followed. One of the most irritating issues was (and still is) the infamous netsplits. The sum of all IRC networks now only totals fewer than a stable 1 million users worldwide.

This era was very diverse and laid the ground for future developments; however the concept introduced in this period was just that of "chat". The next step - moving to actual Instant Messaging - is where our journey really begins.

1st generation: instant messengers, ICQ-like

The instant messenger revolution started around 1998 and 1999 with ICQ as the very first successful player. Then Yahoo!Messenger, AIM and MSN/WLM followed, as well as Gadu-Gadu, QQ, NateOn, LiveJournal, MySpaceIM, Google Talk, and many more, including the only open standard, XMPP or Jabber (not mentioning SIP/SIMPLE here).

a. Sporadic internet connection

In those times, most people connected to the internet using a landline modem. It was slow, expensive and worst of all - loud and annoying (who can forget the “iiiiiiii-eeeeeeee-iii” sound accompanying every session?). No one would connect to the internet for longer than one, maybe two hours since it blocked the phone and ended up costing a fortune.

b. Presence, synchronicity of the user experience

In the very first instant messengers, the concept around which everything revolved was presence, as a core and central feature. When you opened the app you saw a roster listing all your contacts and their status indicated whether they were online or not. Large, blinking icons informed you who was available, busy or away at the moment. Prominent sound notifications let you know the current status of your friends. When logging in, by default, you too were broadcasting to the world that you were online. In both directions, people just wanted to know in real-time who was available to chat, and then engaged in discussion sessions.

c. Desktop-only client

Obviously, the first generation of IM was desktop-only (laptops were still a minority). That meant low bandwidth (before ADSL), but large, comfortable computing resources. Mobile phone screens were just about one or two lines of text in large black LCD pixels, and had no data network (spoiler: the second generation of IM is all about the smartphone).

d. Multi-window software is cool

Since presences and availabilities in the contact list were the main focus, the second most important was the chat window(s). IM clients were multi-window (one window per chat) or dual-window (all chats in one window with tabs). Multi-window software was a cool thing at that time, in photo editing, non-linear video editing, and many more. These were more or less targetted at power users.

e. Group chat as a secondary feature

Group chat was a secondary feature. Lots of room types and features were available: public vs hidden, permanent vs short-lived, whitelists vs blacklists, kick vs ban, etc. You could join group chats after you connected, but participants were not necessarily there all at the same time. Anyone could be suddenly disconnected, for whatever reason (modem stability, or parents taking over the phone). You would miss all the conversations happening while you were offline, and besides this, rooms were cluttered with automatic status messages (Mary joined, John disconnected).

f. Offline messages and logs, easing the suffering of absence

Offline messages (sometimes called store-and-forward) and chat logs were made to fix a few of this “chat while I’m not online” issues (the equivalent of the “leave me a message” phone voicemail). But this feature was very limited, being designed only as a workaround, and IM servers being made only for real-time routing and not for storage.

g. File transfers

The defacto standard of file transfers was more or less fixing a problem that was not specifically linked to IM, but was rather leveraging the intrinsic synchronous nature of its usage. At the time sending “large” (2MB) files by email was impossible, either because waiting for the progress bar to finish and closing the mail composition window took too long, and/or the servers had file size limits. It was a fully synchronous user experience: the sender proposes a file and waits, and the receiver accepts the file and waits for the progress. Sometimes the file proposal could wait for a long time, or even timeout or fail. Most had limited bandwidth, and some had censorship (that would be hidden as “security”).

Also, the file transfer was out of band, meaning it was made outside the context of a chat. No marker in the conversation made you aware you had that file transfer in the past. You had another window for all past file transfers.

h. IM with VoIP, not “VoIP applications”

Some IM services offered voice and video in a time when computers were not equipped with built-in webcams and the quality was poor. Most voice and video features were one-to-one and almost none was compatible with landline and cell phones.

i. Specificities: gadgets ;-) and ads :’(

I couldn’t end this review of the first generation without mentioning all the now defunct gadgets, such as buzz/nudge/wizz/attention, and other mood, activity, music, video.

Summary

To conclude, the first generation of IM was highly synchronous, with a lot of technology and user experience limitations, that were later fixed or mostly addressed by the second generation of IM...

2nd generation: mobile messaging apps

The mobile messaging revolution started with the massive consumer growth of multi-touch smartphones, beggining with the iPhone in 2007 and Android in 2008. The new buzzword became “app”. Not software, client, user agent, or even application, just app. A new generation, a reboot.

Among the most well known mobile messaging apps of the second generation were WhatsApp (which was based on XMPP in the beginning and then evolved). In no particular order the other 2nd generation players are WeChat, LINE, Google Hangouts, Viber, KakaoTalk, Telegram, ChatON, Hike, Kik, and probably Facebook Messenger (who are still competing with WhatsApp, despite owning them).

I am not including here BlackBerry and BBM (BlackBerry Messenger) which were aimed at a more confidential, elite market. Also at the time Skype was only a P2P voice and video call software.

a. Always-on, asynchronous user experience

With the advent of the smartphone, having an always-on internet connection became the norm. Being offline became only an exception, a temporary state. This brought on a massive change in all our lives: from being always OFF (except for a few minutes), to always ON (except for a few minutes).

Mobile messaging apps acquired most user experience from SMS and MMS: as they were always on a network, people would not feel the need to respond immediately anymore. People were finally freed from the obligation to stay on their IM app together at the same time.

This is how IM became asynchronous. Just send a message, you will probably have a reply, someday.

b. Presence became secondary, sometimes useless

Consequently, presence became significantly less necessary. App makers and users simply started considering presence as a bandwidth, scalability, and battery killer. Presence either became secondary or even was completely removed.

c. Mobile-only

The smartphone revolution was so fast and crazy that the first app makers completel forgot the deskop. Lots did mobile-ony apps. And in the later days of the 2nd generation, most of them evolved slowly to mobile-first apps. This was a great period as all the usages were completely reviewed from the ground up and a fully new user experience was created.

d. Full screen is obvious (no windows)

Smartphone apps are naturally full-screen, thus mono-window by nature, maximised to fit screen. Of course some tablet/phablet makers propose types of split screens, but the app stays in one window. The late days of 2nd generation IM saw desktop apps and web apps appear. Desktop apps were mostly based on web technologies, probably for cost saving. Most of them were mono-window, with some weird exceptions.

e. Simplified group chat, still a secondary feature

All the complexities of group chat usage and administration went away. Group chat was made simple, possibly too much so sometimes in second generation IMs finding the admin, if there is any, is a difficult mission as there is no UI, only a hidden command line. That is due mainly to the race between IM makers and the limited possibilities of small smartphone screens. Also implementors kept it to a bare minimum, as that was enough to satisfy most users’ needs. Last but not least, one-to-one or group chat conversations were treated equally.

f. Multi-device: transparent real-time synchronisation

The very limited offline messages of the 1st generation were replaced by a full blown account archive approach for all the messages. Synchonisation of the devices with the central message archive has been made transparent to the user. All the apps connected to a unique account, whether they were on smartphone brand, or another tablet brand, were able to be in full sync, in real-time. The multi-device user experience became the following: start a conversation on one device, continue on another, and finish on a third one. All sent and received messages are consistent across devices, in real-time.

g. In-chat media, no more “file transfer”

File proposition and wait for acceptation has been phased out. Since the connectivity was not predictible, one could not afford the wait for a contact to be online and willing to accept the file. So, IM makers promoted media files as the equal of messages. Photos and pictures, short sounds & videos, potentially any file, plus location could be sent like any other message, and received, notified and archived exaclty like any other message. The user experience for the sender was just a simple file selection, and click/tap send button… then put back the smartphone in the pocket, or type your next message. The app simply takes care about the rest. The user experience for the receiver was just a single notification for the media, like any other type of message. Of course, most apps offer an option to download large files only on wifi, in order to protect the data plan from overspending. The propose/accept UX was disrupting the conversation. With in-chat media, the UX became a single, continuous flow inside the same conversation.

h. Voice and video, better hardware

Real progress was made on voice and video, thanks to better hardware, with de facto standardisation and front camera in smartphones, and later front webcams in laptops. Also, in the late 2nd gen large bandwidth improvements were made thanks to 3G, and then 4G on mobile, and ADSL and optic fiber at home. People now expect most voice calls to work at least with the same quality as regular cell and landline phones. Video calls are much more sensitive to bandwidth limitations, thus users are still prepared to accept some glitches (although the degree of acceptance varies depending on whether it’s personal or business use).

i. Specificities: message actions, mentions, and… sticker craze!

On IM, typos are expected, as you type fast on a small keyboard, and you have auto-correct. Now, you can make sent message corrections. After a message was sent (and probably received), you now have the possibility to edit it on both ends (including archive).

Also, lots of apps propose the capacity to reply to a specific message, to quote or forward or resend a message, and to mention someone with the @nickname notation. These features have made chat much more mature.

A feature has also been borrowed from SMS and largely enhanced: the markers for sent, received, read. That was showed by ticks, labels, or simply metadata text. Some even went further with watermarking a conversation, saying a contact has read all messages until this one.

Stickers, stickers and stickers! Lots of IM apps proposed stickers. You could send a conversation-wide image, cuter and richer than smileys. Stickers are also much lighter than images, as they are just a suite of characters sent over the wire, sticker images being stored locally on each device. These enabled people to convey emotion much more rapidly and with more fun. Some made stickers a source of revenue, selling sticker packs, or letting advertisers pay to propose free-to-the-consumer, branded stickers packs.

Summary

The second generation is the era that made IM asynchronous, and long-lived. Much like the SMS experience from which it borrowed a lot, but also to which it added great maturity.

The second part of this article is focussed specifically on the third generation of Instant Messaging and is coming next week. Stay tuned and get a grasp of the undergoing revolution.

You can now read the second part of “Welcome to the third generation of Instant Messaging!”/

 

Stefan Strigler: Migrate ejabberd DB schema (mysql) from 2.1.x

Planet Jabber - 19 April, 2016 - 20:01

Hiya! Long time no see. So I was upgrading my beloved ejabberd a while back and when I looked closer I found that most of the new functionality just wouldn’t work. Mostly because my ejabberd’s DB schema dating back to some 2.1.x install didn’t fit anymore. So but how to upgrade? After playing weird ideas back and forth I came across a script called ‘php-mysql-diff‘. According to its description it sounded very promising to what I wanted to achieve. Just that it wouldn’t work right of the box. After tearing it apart and putting it back together again I found that this was because my dump files as created by mysqldump sport a ‘COLLATE’ keyword which wasn’t supported by the built-in regexp used by its parser. After I fixed this I got the desired result, a migration script that I could use to upgrade my schemas. Hooray!


# Disable Foreign Keys Check
SET FOREIGN_KEY_CHECKS = 0;
SET SQL_MODE = '';

# Deleted Tables

# Changed Tables

-- changed table `last`

ALTER TABLE `last`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `seconds` `seconds` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
CHANGE COLUMN `state` `state` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `seconds`;

-- changed table `privacy_default_list`

ALTER TABLE `privacy_default_list`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `name` `name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`;

-- changed table `privacy_list`

ALTER TABLE `privacy_list`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `name` `name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
ADD COLUMN `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP AFTER `id`;

-- changed table `privacy_list_data`

ALTER TABLE `privacy_list_data`
CHANGE COLUMN `t` `t` char(1) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `id`,
CHANGE COLUMN `value` `value` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `t`,
CHANGE COLUMN `action` `action` char(1) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `value`,
ADD KEY `i_privacy_list_data_id` (`id`);

-- changed table `private_storage`

ALTER TABLE `private_storage`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `namespace` `namespace` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
CHANGE COLUMN `data` `data` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `namespace`,
ADD COLUMN `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP AFTER `data`;

-- changed table `rostergroups`

ALTER TABLE `rostergroups`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `jid` `jid` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
CHANGE COLUMN `grp` `grp` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `jid`;

-- changed table `rosterusers`

ALTER TABLE `rosterusers`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `jid` `jid` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
CHANGE COLUMN `nick` `nick` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `jid`,
CHANGE COLUMN `subscription` `subscription` char(1) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `nick`,
CHANGE COLUMN `ask` `ask` char(1) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `subscription`,
CHANGE COLUMN `askmessage` `askmessage` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `ask`,
CHANGE COLUMN `server` `server` char(1) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `askmessage`,
CHANGE COLUMN `subscribe` `subscribe` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `server`,
CHANGE COLUMN `type` `type` text COLLATE utf8mb4_unicode_ci AFTER `subscribe`,
ADD COLUMN `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP AFTER `type`;

-- changed table `spool`

ALTER TABLE `spool`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `xml` `xml` blob NOT NULL AFTER `username`,
ADD COLUMN `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP AFTER `seq`,
ADD KEY `i_spool_created_at` (`created_at`) USING BTREE;

-- changed table `users`

ALTER TABLE `users`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `password` `password` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
ADD COLUMN `serverkey` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' AFTER `password`,
ADD COLUMN `salt` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' AFTER `serverkey`,
ADD COLUMN `iterationcount` int(11) NOT NULL DEFAULT '0' AFTER `salt`,
ADD COLUMN `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP AFTER `iterationcount`;

-- changed table `vcard`

ALTER TABLE `vcard`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `vcard` `vcard` mediumtext COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
ADD COLUMN `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP AFTER `vcard`;

-- changed table `vcard_search`

ALTER TABLE `vcard_search`
CHANGE COLUMN `username` `username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL FIRST,
CHANGE COLUMN `lusername` `lusername` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `username`,
CHANGE COLUMN `fn` `fn` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lusername`,
CHANGE COLUMN `lfn` `lfn` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `fn`,
CHANGE COLUMN `family` `family` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lfn`,
CHANGE COLUMN `lfamily` `lfamily` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `family`,
CHANGE COLUMN `given` `given` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lfamily`,
CHANGE COLUMN `lgiven` `lgiven` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `given`,
CHANGE COLUMN `middle` `middle` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lgiven`,
CHANGE COLUMN `lmiddle` `lmiddle` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `middle`,
CHANGE COLUMN `nickname` `nickname` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lmiddle`,
CHANGE COLUMN `lnickname` `lnickname` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `nickname`,
CHANGE COLUMN `bday` `bday` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lnickname`,
CHANGE COLUMN `lbday` `lbday` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `bday`,
CHANGE COLUMN `ctry` `ctry` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lbday`,
CHANGE COLUMN `lctry` `lctry` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `ctry`,
CHANGE COLUMN `locality` `locality` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lctry`,
CHANGE COLUMN `llocality` `llocality` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `locality`,
CHANGE COLUMN `email` `email` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `llocality`,
CHANGE COLUMN `lemail` `lemail` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `email`,
CHANGE COLUMN `orgname` `orgname` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lemail`,
CHANGE COLUMN `lorgname` `lorgname` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `orgname`,
CHANGE COLUMN `orgunit` `orgunit` text COLLATE utf8mb4_unicode_ci NOT NULL AFTER `lorgname`,
CHANGE COLUMN `lorgunit` `lorgunit` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL AFTER `orgunit`;

# New Tables

-- new table `archive`

CREATE TABLE `archive` (
`username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`timestamp` bigint(20) unsigned NOT NULL,
`peer` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`bare_peer` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`xml` text COLLATE utf8mb4_unicode_ci NOT NULL,
`txt` text COLLATE utf8mb4_unicode_ci,
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`kind` varchar(10) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`nick` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
KEY `i_bare_peer` (`bare_peer`) USING BTREE,
KEY `i_peer` (`peer`) USING BTREE,
FULLTEXT KEY `i_text` (`txt`),
KEY `i_timestamp` (`timestamp`) USING BTREE,
KEY `i_username` (`username`) USING BTREE,
UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `archive_prefs`

CREATE TABLE `archive_prefs` (
`username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`def` text COLLATE utf8mb4_unicode_ci NOT NULL,
`always` text COLLATE utf8mb4_unicode_ci NOT NULL,
`never` text COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `caps_features`

CREATE TABLE `caps_features` (
`node` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`subnode` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`feature` text COLLATE utf8mb4_unicode_ci,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
KEY `i_caps_features_node_subnode` (`node`(75),`subnode`(75))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `irc_custom`

CREATE TABLE `irc_custom` (
`jid` text COLLATE utf8mb4_unicode_ci NOT NULL,
`host` text COLLATE utf8mb4_unicode_ci NOT NULL,
`data` text COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY `i_irc_custom_jid_host` (`jid`(75),`host`(75)) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `motd`

CREATE TABLE `motd` (
`username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`xml` text COLLATE utf8mb4_unicode_ci,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `muc_registered`

CREATE TABLE `muc_registered` (
`jid` text COLLATE utf8mb4_unicode_ci NOT NULL,
`host` text COLLATE utf8mb4_unicode_ci NOT NULL,
`nick` text COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY `i_muc_registered_jid_host` (`jid`(75),`host`(75)) USING BTREE,
KEY `i_muc_registered_nick` (`nick`(75)) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `muc_room`

CREATE TABLE `muc_room` (
`name` text COLLATE utf8mb4_unicode_ci NOT NULL,
`host` text COLLATE utf8mb4_unicode_ci NOT NULL,
`opts` text COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY `i_muc_room_name_host` (`name`(75),`host`(75)) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `pubsub_item`

CREATE TABLE `pubsub_item` (
`nodeid` bigint(20) DEFAULT NULL,
`itemid` text COLLATE utf8mb4_unicode_ci,
`publisher` text COLLATE utf8mb4_unicode_ci,
`creation` text COLLATE utf8mb4_unicode_ci,
`modification` text COLLATE utf8mb4_unicode_ci,
`payload` text COLLATE utf8mb4_unicode_ci,
KEY `i_pubsub_item_itemid` (`itemid`(36)),
UNIQUE KEY `i_pubsub_item_tuple` (`nodeid`,`itemid`(36)),
CONSTRAINT `pubsub_item_ibfk_1` FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `pubsub_node`

CREATE TABLE `pubsub_node` (
`host` text COLLATE utf8mb4_unicode_ci,
`node` text COLLATE utf8mb4_unicode_ci,
`parent` text COLLATE utf8mb4_unicode_ci,
`type` text COLLATE utf8mb4_unicode_ci,
`nodeid` bigint(20) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`nodeid`),
KEY `i_pubsub_node_parent` (`parent`(120)),
UNIQUE KEY `i_pubsub_node_tuple` (`host`(20),`node`(120))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `pubsub_node_option`

CREATE TABLE `pubsub_node_option` (
`nodeid` bigint(20) DEFAULT NULL,
`name` text COLLATE utf8mb4_unicode_ci,
`val` text COLLATE utf8mb4_unicode_ci,
KEY `i_pubsub_node_option_nodeid` (`nodeid`),
CONSTRAINT `pubsub_node_option_ibfk_1` FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `pubsub_node_owner`

CREATE TABLE `pubsub_node_owner` (
`nodeid` bigint(20) DEFAULT NULL,
`owner` text COLLATE utf8mb4_unicode_ci,
KEY `i_pubsub_node_owner_nodeid` (`nodeid`),
CONSTRAINT `pubsub_node_owner_ibfk_1` FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `pubsub_state`

CREATE TABLE `pubsub_state` (
`nodeid` bigint(20) DEFAULT NULL,
`jid` text COLLATE utf8mb4_unicode_ci,
`affiliation` char(1) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`subscriptions` text COLLATE utf8mb4_unicode_ci,
`stateid` bigint(20) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`stateid`),
KEY `i_pubsub_state_jid` (`jid`(60)),
UNIQUE KEY `i_pubsub_state_tuple` (`nodeid`,`jid`(60)),
CONSTRAINT `pubsub_state_ibfk_1` FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `pubsub_subscription_opt`

CREATE TABLE `pubsub_subscription_opt` (
`subid` text COLLATE utf8mb4_unicode_ci,
`opt_name` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`opt_value` text COLLATE utf8mb4_unicode_ci,
UNIQUE KEY `i_pubsub_subscription_opt` (`subid`(32),`opt_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `roster_version`

CREATE TABLE `roster_version` (
`username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`version` text COLLATE utf8mb4_unicode_ci NOT NULL,
PRIMARY KEY (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `sm`

CREATE TABLE `sm` (
`usec` bigint(20) NOT NULL,
`pid` text COLLATE utf8mb4_unicode_ci NOT NULL,
`node` text COLLATE utf8mb4_unicode_ci NOT NULL,
`username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`resource` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`priority` text COLLATE utf8mb4_unicode_ci NOT NULL,
`info` text COLLATE utf8mb4_unicode_ci NOT NULL,
KEY `i_node` (`node`(75)),
UNIQUE KEY `i_sid` (`usec`,`pid`(75)),
KEY `i_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `sr_group`

CREATE TABLE `sr_group` (
`name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`opts` text COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `sr_user`

CREATE TABLE `sr_user` (
`jid` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`grp` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
KEY `i_sr_user_grp` (`grp`),
KEY `i_sr_user_jid` (`jid`),
UNIQUE KEY `i_sr_user_jid_group` (`jid`(75),`grp`(75))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- new table `vcard_xupdate`

CREATE TABLE `vcard_xupdate` (
`username` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
`hash` text COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

# Disable Foreign Keys Check
SET FOREIGN_KEY_CHECKS = 1;

For convenience you can also download the file created: ejabberd_migrate2.sql.

PS: The fixed version of php-mysql-diff can be found at https://github.com/sstrigler/php-mysql-diff, a PR has been submitted.

Update: First version was working with an outdated schema for the users table. This is fixed at ejabberd_migrate2.sql now. Apparently my ejabberd-16.01 with shipped with an incorrect schema. :-/

Stefan Strigler: jwchat.org Updates

Planet Jabber - 19 April, 2016 - 20:00

I have been working a lot on my XMPP service at jwchat.org recently. The idea was to bring you more security, privacy and modern features. In detail what has changed:

I hope you’ll enjoy the extended and improved service.

If you want to have your own XMPP (Jabber) server hosted, feel free to contact me!

Tigase Blog: Using Tigase Android Messenger

Planet Jabber - 16 April, 2016 - 01:49

One of the advantages of working with a company with its own communication platform is that you’re never far from contact. Whether it be other friends on federated XMPP servers wanting to contact you, or coworkers looking to get your quick response, it can come in handy.

Tigase Blog: REST now supported

Planet Jabber - 15 April, 2016 - 19:00

Tigase now supports commands sent using Representational State Transfer, a stateless client protocol using the HTTP protocol. Using the rest component, users and administrators can send stanzas, adjust settings, and even send messages using the REST protocol without the need for an XMPP client. One way this can prove useful is websites can interface with Tigase server seamlessly provide content or communications without the need for another API layer. Of course this is not the only use for REST.

Ignite Realtime Blog: Smack 4.1.7 and 4.2.0-beta1 released

Planet Jabber - 15 April, 2016 - 12:54

Two new releases of Smack have just been pushed to Maven Central.

 

Smack 4.1.7 fixes a few bugs. One noteworthy bug is that on certain platforms Smack's setEnabledSSL(Protocols|Ciphers) had no effect. More information about the fixed bugs can be found in the Release Notes.

 

The careful reader may noticed that this is the first beta release of Smack 4.2. Which means that Smack 4.2 just entered the beta phase. My rough timeplan is to release Smack 4.2 in 6 months: starting with 3 months long beta period now, followed by 3 months of release candidates. But as all schedules in the software industry, take it with a grain of salt.

ProcessOne: Property-based testing of XMPP: generate your tests automatically – ejabberd Workshop #1

Planet Jabber - 13 April, 2016 - 14:05

Thomas Arts, from Quviq AB, introduces property-based testing from his work on ejabberd XMPP server.

The talk explains how Quickcheck testing approach can help find bugs in ejabberd and improved the range (and the creativity) of the test cases covered.

Quviq is the company being Erlang Quickcheck property-based tool.

The video was recorded at ejabberd Advanced Erlang Workshop in Paris.

You can watch the full talk online:

You can also browse the slides:

If you like our videos, you may consider joining one of our next Advanced Erlang Workshop: Just get to Advanced Erlang website to stay updated on the workshop schedule.

ProcessOne: How to use ejabberd as an Elixir application dependency

Planet Jabber - 13 April, 2016 - 08:36

Starting from version 16.02, ejabberd is packaged as an Hex.pm application: ejabberd on hex.pm. In case of doubt, you can refer to ejabberd official documentation: Embedding ejabberd in an Elixir application

It means that you can now build a customized XMPP messaging platform with Elixir on top of ejabberd. You do so by leveraging ejabberd code base in your app and providing only your custom modules.

This makes the management of your ejabberd plugins easier and cleaner.

To create your own application depending on ejabberd, you can go through the following steps:

  1. Create new Elixir app with mix:

    mix new ejapp * creating README.md * creating .gitignore * creating mix.exs * creating config * creating config/config.exs * creating lib * creating lib/ejapp.ex * creating test * creating test/test_helper.exs * creating test/ejapp_test.exs Your Mix project was created successfully. You can use "mix" to compile it, test it, and more: cd ejapp mix test Run "mix help" for more commands.
  2. Get to your new app directory:

    cd ejapp
  3. Add ejabberd package as a dependency in your mix.exs file:

    defmodule Ejapp.Mixfile do ... defp deps do [{:ejabberd, "~> 16.2"}] end end
  4. Start ejabberd application from mix.exs when your app is started:

    defmodule Ejapp.Mixfile do ... def application do [applications: [:logger, :ejabberd]] end ... end
  5. Create or get ejabberd config file:

    (cd config; wget https://gist.githubusercontent.com/mremond/383666d563025e86adfe/raw/723dfa50c955c112777f3361b4f2067b76a55d7b/ejabberd.yml)
  6. Define ejabberd configuration reference in config/config.exs:

    config :ejabberd, file: "config/ejabberd.yml", log_path: 'logs/ejabberd.log' # Customize Mnesia directory: config :mnesia, dir: 'mnesiadb/'
  7. Create log dir:

    mkdir logs
  8. Compile everything:

    mix do deps.get, compile
  9. Start your app, ejabberd will be started as a dependency:

    iex -S mix
  10. Register user from Elixir console:

    :ejabberd_auth.try_register("test", "localhost", "passw0rd")
  11. You are all set, you can now connect with an XMPP client !

Monal IM: Word swat 1.0 out

Planet Jabber - 12 April, 2016 - 19:31

Wordswat is something I made between projects. This is a fantasy adventure that covers high frequency english vocabulary for children in kindergarten and first grade. Pick a grade and one of several units where a creature will ask the player to spell a set of words. (iPad iOS7 and up, Free)

  • All the the game’s words are actual audio recordings that do not feature the mispronunciation and odd intonation common in computer generated audio.
  •  Uses simple sentences for homophones
  •  The vocabulary list should align closely with common core.

ProcessOne: Securing ejabberd with TLS encryption

Planet Jabber - 8 April, 2016 - 12:49

In recent years security and privacy become central focus of users and system administrators. Here is brief guide on securing ejabberd connections and keep them private.

ejabberd have number of options that control security:

certfile: Full path to a file containing the default SSL certificate
ciphers: OpenSSL ciphers list in the same format accepted by ‘openssl ciphers’ command
protocol_options: List of supported SSL protocols
dhfile: Full path to a file containing custom parameters for Diffie-Hellman key exchange
starttls: This option specifies that STARTTLS encryption is available on connections to the port
starttls_required: This option specifies that STARTTLS encryption is required on connections to the port.
tls: This option specifies that traffic on the port will be encrypted using SSL immediately after connecting. This method is nowadays deprecated and not recommended
tls_compression: Whether to enable or disable TLS compression.
s2s_use_starttls: This option defines if s2s connections are encrypted
s2s_certfile: Full path to a file containing a SSL certificate
s2s_dhfile: Full path to a file containing custom DH parameters
s2s_ciphers: OpenSSL ciphers list in the same format accepted by ‘openssl ciphers’ command
s2s_protocol_options: List of supported SSL protocols
s2s_tls_compression: Whether to enable or disable TLS compression

For more configuration options and description refer to ejabberd documentation.

Settings: Recommended vs Compatibility

For many years security was something that was not primary concern in many cases in internet standards. ProcessOne team stands on the point that security is one of the primary factors thus we will recommend strong settings but also provide compatibility for reference only for those who want and need to retain support for insecure, legacy clients and servers but understand that this settings may jeopardize security and privacy. In below table you can find defaults for legacy and recommended settings:

Option Legacy Recommended certfile path: /etc/ssl/ejabberd/domain.pem path: /etc/ssl/ejabberd/domain.pem ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 protocol_options no_sslv2, no_sslv3 no_sslv2, no_sslv3, no_tlsv1,no_tlsv1_1 dhfile path: /etc/ssl/ejabberd/dh1024.pem path: /etc/ssl/ejabberd/dh2048.pem starttls TRUE TRUE starttls_required FALSE TRUE tls FALSE FALSE tls_compression FALSE FALSE s2s_use_starttls OPTIONAL REQUIRED s2s_certfile path: /etc/ssl/ejabberd/domain.pem path: /etc/ssl/ejabberd/domain.pem s2s_dhfile path: /etc/ssl/ejabberd/dh1024.pem path: /etc/ssl/ejabberd/dh2048.pem s2s_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 s2s_protocol_options no_sslv2, no_sslv3 no_sslv2, no_sslv3, no_tlsv1,no_tlsv1_1 s2s_tls_compression FALSE FALSE

Configuration examples

Example 1 – Strong settings for c2s settings

This config disables protocols from SSLv2 up to TLSv1.1 and allows only “modern” (as of 2016) protocol TLSv1.2 and related ciphers.

listen: - port: 5222 module: ejabberd_c2s protocol_options: - "no_sslv2" - "no_sslv3" - "no_tlsv1" - "no_tlsv1_1" ciphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256" shaper: c2s_shaper access: c2s certfile: "/etc/ssl/ejabberd/domain.pem" starttls: true starttls_required: true tls_compression: false dhfile: "/etc/ssl/ejabberd/dh2048.pem"

Note: Clients that do not support TLS1.2 will not be allowed to connect to c2s port.

Example 2 – Compatible settings for c2s

listen: - port: 5222 module: ejabberd_c2s protocol_options: - "no_sslv2" - "no_sslv3" ciphers: "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS" shaper: c2s_shaper access: c2s certfile: "/etc/ssl/ejabberd/domain.pem" starttls: true starttls_required: false tls_compression: false dhfile: "/etc/ssl/ejabberd/dh1024.pem"

Note: Clients that can connect to c2s ports need support at last TLS1.0. SSLv2 and SSLv3 have serious security flaws and have to be disabled. Also DH parameter is lowered here to 1024 bit as some older Java do not support higher grades.

Server-to-Server connections

s2s connections are more complex then client connections. If we want to federate with broad spectrum of XMPP servers, we have to allow unencrypted connections to that port. There are still lot of servers that do not support encryption. On the other hand, we have 2016 and it is hard to believe that there are still servers that sends data using plain-text. Choice is always up to server administrators, but ProcessOne strongly recommend to allow only secure, encrypted connections to port s2s:

Example 1 – Strong settings for s2s connections

Global section:

s2s_use_starttls: required s2s_certfile: /etc/ssl/ejabberd/domain.pem s2s_dhfile: /etc/ssl/ejabberd/dh2048.pem s2s_ciphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

Listening ports:

listen: - port: 5269 module: ejabberd_s2s_in protocol_options: - "no_sslv2" - "no_sslv3" - "no_tlsv1" - "no_tlsv1_1"

Note: Only TLSv1.2 connections are allowed and all s2s connections are required to be encrypted

Example 2 – Legacy and unsafe s2s settings

Global section:

s2s_use_starttls: optional s2s_certfile: /etc/ssl/ejabberd/domain.pem s2s_dhfile: /etc/ssl/ejabberd/dh1024.pem s2s_ciphers: "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS"

Listening ports:

listen: - port: 5269 module: ejabberd_s2s_in protocol_options: - "no_sslv2" - "no_sslv3"

Note: Allow unencrypted connections for servers that do not require it. If connections are encrypted – allow only protocol up from TLSv1. Also DH is lowered to 1024 bits.

Appendix: Create PEM files and DH paramerers

ejabberd supports certificates in PEM format. Certificate should also contain certificate-chain that comes from certificate provider. Here is how certificates in PEM file should stack-up:

——— Main Certificate (xmpp.example.com) ——— ——— Intermediate certificate, chain certs ——— ——— Private Key for Main Certificate ———

PEM file should be only readable by process running ejabberd.

ejabberd configuration allow to use custom DH parameters, this is important as recent research revealed weakness of widely and common used DH files (see https://weakdh.org). We are recommending to use at last 2048-bit DH parameters. To generate DH use openssl command, for example:

openssl dhparam -out /etc/ssl/ejabberd/dh2048.pem 2048

and add proper ejabberd config option (see previous section). If you need to support some old software like Java7, set DH size to 1024.

Appendix: Generating Private Key and Certificate Requests

You can generate self-signed certificates for your connections, however nowadays we strongly recommend that anyone use signed certificates by trusted and known Certificate Authority (CA). You can easily find commercial CA with pricing starting as low as $15 per year. There is also option of using free certificates from https://letsencrypt.org – see their docs for automated process of issuing certificates.

Generate Private Key (PK):

openssl genrsa -out xmpp_example_com.key 2048

this will generate PK – keep it safe, do not share. It is 2048 bit long, if you need bigger key, go for 4096 bits. Now you need to generate Certificate Signing Request (CSR) – that need to be send (usually copy&paste) to CA to generate certificate for you:

openssl req -out xmpp_example_com.csr -key xmpp_example_com.key -new -sha256

you will have to answer range of questions, and most important is: “Common Name (e.g. server FQDN or YOUR name)” this is where you place your domain name, like: xmpp.example.com , you can use wildcard names as well if you use certificate for other sub-domains.
After submitting CSR to CA you will get CRT – file that is actually public part of your key pair. Usually with your CRT, CA also provides certificate chain that need to be included in PEM file (see appendix about creating PEM files).

If you want to generate a self-signed certificate and not yet ask a certificate to a CA, you can use the following command. It is not recommended for production, but can be helpful for testing:

openssl x509 -req -days 365 -in xmpp_example_com.csr -signkey xmpp_example_com.key -out xmpp_example_com.crt

Then, all what you need to do is to combine files into single PEM file. Using names from above examples, that can be done using cat command (step-by-step):

Let’s assume that CA sent you xmpp_example_com.crt and ca_intermediate_certificate.crt:

cat xmpp_example_com.crt > xmpp_example_com.pem (create PEM file with certificate)
cat ca_intermediate_certificate.crt >> xmpp_example_com.pem (add intermediate CA certificate to PEM)
cat xmpp_example_com.key >> xmpp_example_com.pem (finally add private key to file)

ensure that PEM file do not have any garbage, it should be nice and smooth text file like:

-----BEGIN CERTIFICATE----- MIIHEjCCBfqgAwIBAgIQCI9arD288vK6p24B8dArzjANBgkqhkiG9w0BAQUFADBm MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 .... .... XJqV43tRs8oaymPzU9NVbLutjva+ln/ml2IcEoE7a8x0UbdcYfQKpFI9cjr9yIki sn5Y+o5sMjse8gXZtFMttmE3yypBt5BR4yLoQB2BSocmZkhWGjQ= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIGWDCCBUCgAwIBAgIQCl8RTQNbF5EX0u/UA4w/OzANBgkqhkiG9w0BAQUFADBs .... .... Ib4p1I5eFdZCSucyb6Sxa1GDWL4/bcf72gMhy2oWGU4K8K2Eyl2Us1p292E= -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- MIIEpQIyyiKCA35wtuube64IQM5hYnSzNL8HLJLYVfEl5vSrDO5KwLZ/P71BPrhx .... .... hddA/p+zRteyTvBJaXAJwrreSjeJL4HGyf0E9z4TLE5qNMF81bXFso0+2FGDrh0t -----END RSA PRIVATE KEY-----

Tigase Blog: Connection Watchdog

Planet Jabber - 8 April, 2016 - 00:11

A common problem that can occur with any server is stale connections tying up available bandwidth. Whether it is due to a connection timeout, poor quality connection, or system errors, stale connections can bog down a system from operating at peak efficiency and post security risks. Operating systems and network settings can be configured to attempt to solve this problem, but that solution can cause problems. We at Tigase thought if we can monitor connections internally, we can enable users can fine-tune settings to exactly fit their needs.

ProcessOne: ejabberd ARM64 support

Planet Jabber - 4 April, 2016 - 12:41

ARMv8 represents a fundamental change to the ARM architecture. It adds a 64-bit architecture instruction set, named “AArch64”, or ARM64.

ProcessOne has been playing with ARM64 ejabberd servers for few months already, but with recent availability of many low cost 64-bit ARM development platforms, we decided to announce official ARM64 support for ejabberd.

ejabberd Community Server 16.03 is the first public version available with an ARM64 installer.

You will need a 64-bit ARM Linux installation, with glibc >= 2.17 to use our official installer.
Give it a try and Send us feedback !

Fanout Blog: Migrated to Jekyll

Planet Jabber - 2 April, 2016 - 19:43

We recently migrated the Fanout Blog from WordPress to Jekyll, and we updated the blog theme to match the newer Fanout website design.

The blog content is all the same, and Livefyre commenting is still here as well as RSS/Atom feeds and the SubToMe buttons. The reason for the migration (and thus the differences) are mostly internal:

...

ProcessOne: ejabberd 16.03: Experimental MIX support, LDAP, SQL and Riak improvements

Planet Jabber - 30 March, 2016 - 16:20

ejabberd development keeps on its steady pace and we are energized by the growing momentum. Thank you all for your feedback and contributions for that release.

This new ejabberd release contains many many bugfixes, internal improvements, but also, as usual, some new features.

We are very excited by the experimental support for Mediated Information eXchange (MIX) we have added in ejabberd 16.03. This is the future of Multi User Chat for XMPP. While still rough, you can already give it a try and help improve the specification. You can learn more from our previous blog post: Experimental MIX Support for Group Conversations added to ejabberd

We have also started improvements of various third-party backends such a Microsoft SQL Server and LDAP. This is the beginning of a process to improve support of those backend, so please, bare with us and keep us posted on your results.

Changes Protocols
  • mod_mix: Experimental support for MIX (XEP-0369)
  • mod_http_upload: Add support for XEP-0363 v0.2
Core
  • Use SASL PLAIN authzid as client identity if auth module permits it
  • Make auto generated resources shorter
  • Start ezlib only if required, as it’s optional
  • Make it possible to get virtual host of a registered route
LDAP improvements
  • Fix issue getting shared roster
  • Do not call to deprected/undefined functions from mod_shared_roster_ldap
  • Proper naming for LDAP test function for shared roster
SQL databases support
  • New parse transform for SQL queries, use prepare/execute calls with Postgres
  • Support for run-time SQL queries selection depending on DBMS version
  • In SQL files create Users table with SCRAM support by default
  • Do not auto append IP suffix to usernames
  • Fix some LIMIT related problems with MSSQL
  • Update Microsoft SQL Server schema
Riak
  • Add support for Riak authentication
  • Fix is_connected/0 function
  • Keep alive Riak connections by default
API and Commands
  • Add support for ReST admin commands that are only restricted by source IP. This is key for easy integration with other backend using ReST API.
  • Fix add_commands and remove_commands options
  • Pass noauth when auth isn’t provided
  • Improve ban_account command to work with other DBs than Mnesia
  • Escape quoting node name for ejabberdctl ping
  • Bare JID in ‘from’ of Roster Push (RFC 6121 section 2.1.6) in mod_admin_extra
  • Fix result type of “connected_users_info” command
  • New command delete_mnesia deletes all tables that can be exported. This is useful after you have migrated to another backend, like SQL.
PubSub
  • Unregister route at the very end
  • Define PubSub node configuration per route/host explicitly
  • Fix config fetch and pubsub disco after host/serverhost cleanup
Admin and build chain
  • Update OTP release to use R17.5 and drop release 17.1
  • Compile ejabberd_config early to stop undefined behaviour warnings
  • Fix start via systemd
  • Fixed type specifications for ‘rebar doc’
  • Specify lacking nodename in ejabberdctl
Dependencies
  • Update p1_pgsql to 1.1.0: This add support for prepared statements.
  • Uptate fast_yaml to 1.0.3: This improves the error reporting on syntax errors in Yaml configuration file.
  • Use the v0.2 release of luerl instead of a commit.
Test framework
  • Add Coveralls support
  • Add ability to run the ejabberd test suite in a modular way. You can now run the test suite, even if you only have a a single backend locally.
Other
  • mod_mam: Don’t store watchdog notifications in MAM archives
  • mod_multicast: Fix Addresses element which lacked others local destinations
  • mod_offline: Mark get_queue_length obsolete, and use count_offline_messages
  • Update Gallician translation
Feedback

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 that you’ve found a bug, please search or fill a bug report on Github.

Tigase Blog: DBSchemaLoader Utility

Planet Jabber - 26 March, 2016 - 02:24

Tigase is programmed to work with a plethora of databases, however not all users will want to learn (or purchase) an SQL editor to maintain those databases. We at Tigase have decided to provide a utility, built into our XMPP server, that can perform many functions of database utilities. This utility has been included with Tigase for some time now, but it's possible many of our users never noticed it's existence. DBSchemaLoader runs as a java program, so it is independent of operating system, and can run on any machine that can also run Tigase XMPP Server.

Distribuir contenido