Agregador de noticias

ProcessOne: ejabberd 17.03

Planet Jabber - 24 March, 2017 - 15:03

New modular code, flexible core backend, dynamic configuration reload, spam protection and routing API changes.
These are the most interesting improvements coming in 17.03.

As usual, we also included several other improvements and many bug-fixes. In summary, almost 3K new lines of code and other 10K changed lines.

Many thanks to all of you which tested and sent feedback over the beta testing period!

Improvements Modular code

New modular code allows to develop modules for a wide scope of functionalities without patching the core code such as C2S, S2S and router.

Routing API

Now ‘From’ and ‘To’ arguments must be omitted in functions and structures related to routing.
The commit deprecates the following functions:

  • ejabberd_router:route/3 in favor of ejabberd_router:route/1
  • ejabberd_router:route_error/4 in favor of ejabberd_router:route_error/2
  • ejabberd_local:route_iq/4 in favor of ejabberd_local:route_iq/2
  • ejabberd_local:route_iq/5 in favor of ejabberd_local:route_iq/3

The format of {route, From, To, Packet} is changed in favor of {route, Packet}.
API changes will be better described with 17.03 release when new API documentation will be completed.

Flexible core backend

Ejabberd used to store all in-memory shared data such as ACLs, proxy65, sessions, routes, clustering, etc in internal Mnesia database and this used to be hardcoded. With new API it’s now possible to store such data in any database.
However, currently only Mnesia backend is supported, but we’re working on implementing other backends (redis, sql) in future releases.
For the record, it’s already possible to store client sessions in Redis and/or SQL servers, the API was just extended to make it possible to implement such a backend for any in-memory shared data.

New features Dynamic configuration reload

Using ‘reload_config’ ejabberd’s command it is now possible to reload modules, database connections, listeners, ACLs and global options without restarting ejabberd.
Thanks to this improvement, it’s now possible to add and remove virtual hosts via configuration reload.

Spam protection

If you want to get ride of XMPP SPAM, best option is now to use our new feature implemented by mod_block_strangers. This module just allow to block packets from non-subscribers, this means you won’t receive messages from users not registered in your roster.

S2S dialback

S2S dialback is now an optional module. If not present in the configuration, only TLS mechanism can be used to establish S2S connections.

Upgrade

While upgrading an existing system, you need to care about few required changes. In order to enable S2S dialback, stream management (XEP-0178), legacy client auth or the new anti-spam feature, the following modules should be added to ejabberd’s configuration:

  • mod_s2s_dialback
  • mod_stream_mgmt
  • mod_legacy_auth
  • mod_block_strangers

If you have issues using PubSub with Postgres backend, please check the full schema update from sources.
While in runtime, you can run the following bare minimal changes to fix PubSub

ALTER TABLE pubsub_state ALTER COLUMN subscriptions SET DEFAULT '';
UPDATE pubsub_state SET subscriptions='' WHERE subscriptions=null;

Changes

Here are the most relevant changes

Developer
  • tools/hook_deps.sh: checks hook dependencies
  • tools/find-outdated-deps.pl: checks which dependences need update
  • Mark as deprecated add/get_local/global_option config functions
  • Change routing API
Core
  • Fix some corner cases while re-reading RFC6120
  • Attach IP metadata to every stanza received from stream
  • Apply SASLprep before storing/converting passwords
  • Send compressed in correct order
  • Reset XML stream before sending SASL success
  • Speedup features list when a lot of virtual hosts configured
  • Fix s2s_dns_timeout issues
  • Better handling of IPv6 domains
  • Rename mod_sm -> mod_stream_mgmt
  • Don’t count resent stanzas
  • Improve startup procedure, and log startup time
  • Add more processes to supervision
  • sm_sql: Avoid PID collisions
Admin
  • Add ‘supervisor’ listening option
  • Accept “add_commands: admin” in commands section
  • Make sure that api_permissions always have “console commands” section
  • Change name of pam dep from p1_pam to epam
  • Improve compilation with rebar3
  • Add TLS support for external components
  • Specify “ExecReload” command in systemd unit
  • Don’t attempt to resolve _jabber._tcp SRV record
  • Improve error reporting for forbidden servers
  • mod_block_strangers: New module to block packets from non-subscribers
  • mod_register: Report password change in the log
  • Remove relict mod_service_log
  • Remove unused mod_ip_blacklist
  • Remove ejabberd_frontend_socket
  • WebAdmin: improve formatting when showing erlang terms
  • Import from Prosody: Fix import of SCRAM passwords, offline
API & Commands
  • get_last now always returns tuple with UTC XEP-0082 and status
  • Protect users from delete_old_users command using a fixed access rule
  • Separate list of strings with \n for srg_get_info in mod_http_api
  • Support non-JID lines in command create_rooms_file
  • stop_all_connections now stops all s2s connections via supervisor calls
  • Support scrammed passwords in ejabberdctl import_prosody
Configuration
  • Provide example mod_http_api configuration with couple commands
  • Clarify new modules usage in the example config
  • Don’t crash on malformed IP addresses
  • Fix parsing of acl/access rules inside oauth sections of api_permissions
Config reload improvements
  • Start/stop auth modules when host is added/deleted
  • Improve modules start/stop procedures
  • Check result of gen_mod:start/2 callback
  • Improve reload_config admin command
  • Invalidate access permissions on configuration reload
  • Start/stop virtual hosts when reloading configuration file
  • Reload modules when reloading configuration file
  • Restart listeners on configuration reload
  • Make sure all hooks are called with proper host
Databases
  • Add missing NOT NULL restrictions in schemas
  • Move archive tables into lite.sql for better comparison with other schemas
  • Implement database backend interface for mod_proxy65
  • Implement database backend interface for MUC, BOSH and auth_anonyous
  • Implement database backend interface for ejabberd_router
  • Propagate the TRANSACTION_TIMEOUT to pgsql driver
New XMPP stream behavior
  • Reflect cyrsasl API changes in remaining code
  • Improve return values in cyrsasl API
  • More refactoring on session management
  • Add xmpp_stream_out behavior and rewrite s2s/SM code
  • Rewrite ejabberd_service to use new XMPP stream API
MAM & offline storage
  • Make a message is not bounced if it’s archived
  • Archive message before delivering it to offline storage
  • Include stanza ID with archived offline messages
  • Add stanza-id to every archived message
PubSub
  • Avoid orphan_item leak on affiliation/subscription removal
  • Fix pubsub SQL schemas, add NOT NULL restrictions
  • Fix last item cache for multiple hosts
Server to server
  • Several improvements of S2S errors logging
  • Resolve all addresses from SRV lookup
  • Add s2s work-around for gmail.com
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.

The XMPP Standards Foundation: First Paris XMPP meetup

Planet Jabber - 23 March, 2017 - 22:59

After Berlin, Stockholm, and London, here is Paris. The trend of new XMPP meetups in major cities in Europe is confirmed.

The Paris meetup is simply organised by the JabberFr community, as this will be mostly oriented discussions on modern XMPP/Jabber.

Details are available on JabberFr, LinuxFr.org, and agendadulibre.

The XMPP Standards Foundation: New XMPP Software Listing Rules

Planet Jabber - 23 March, 2017 - 12:00

The XSF provides a public list of XMPP implementations on its website. For this list to be useful, it should contain up-to-date information about up-to-date software. To achieve this, the XSF Board has decided that all implementations have to reapply once per year, to ensure that they are still actively maintained and that the listed info is accurate. This is a purely formal process, though we encourage implementors to follow the current compliance suites.

If you have an entry in one of the lists, please create a pull request as desribed in the README before the 1st of May 2017. There is an example commit that can be used as a reference. Software that is not updated until that date will be automatically removed from the listing. Alternatively, you can ask in the jdev MUC for a manual update of your listing.

Please also ensure that you repeat this step in the following years.

Swift Blog: Swift and Google Summer of Code 2017

Planet Jabber - 21 March, 2017 - 00:00

It’s Google Summer of Code time again! Swift is participating in GSOC2017 under the banner of the XMPP Standards Foundation and we’ve posted a range of project ideas covering Swift and Swiften on the XSF wiki. Read on for more information.

As reported in a post on the XMPP Standards Foundation blog, the XSF has once again been accepted as one of the Open Source organizations participating in Google Summer of Code.

We’ve listed some "potential ideas for Swift and Swiften GSOC projects on the XMPP Wiki so, if you’re interested in participating as a GSOC student this year, please take a look.

If any of these projects are of interest, or if you have ideas of your own you’d like to propose, then please join the swift@rooms.swift.im chat room to discuss GSOC and ask questions. We’ve had some great experiences with previous GSOC projects and we’re very much looking forward to working with students this summer.

Ignite Realtime Blog: Smack 4.2.0 released

Planet Jabber - 20 March, 2017 - 15:48

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

 

$ git shortlog -sn 4.1.0..4.2.0

   459  Florian Schmaus

     8  Fernando Ramirez

     3  Anno van Vliet

     3  Tibo-lg

     3  damencho

     3  ramabit

     2  Andrey Starodubtsev

     2  Vyacheslav Blinov

     2  stawny

     1  Andrey Prokopenko

     1  Craig

     1  Daniel Hintze

     1  Dave Cridland

     1  David Black

     1  Dmitry Deshevoy

     1  Grigory Fedorov

     1  Hugues Bruant

     1  Ishan Khanna

     1  TheHaf

     1  Tomas Nosek

     1  Tomáš Havlas

     1  UltimateZero

     1  Vaibhav

     1  meisterfuu

     1  rohanag12

     1  vfite

 

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

 

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

 

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

 

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

Christian Schudt: Babbler Version 0.7.4 released

Planet Jabber - 16 March, 2017 - 15:26
Version 0.7.4 of the Java XMPP library has been released to Maven Central!

It turned out there was a rare deadlock, when using Stream Management. It happened only rarely and was hard to spot, but when it did, it was of course a blocker.

Here's the full changelog:
  • Resolve rare deadlock when using Stream Management
  • Rework how WebSocket connections are closed
  • Don’t let a stream error close the stream immediately, but instead wait for the closing stream element and then close the connection.
  • Increase performance of IBB stream
  • Prevent rare, but possible NullPointerException after sending stanzas.
  • Fix error when using pages (XEP-0141) within data forms (XEP-0004)
  • Reset nick to null, if entering a chat room fails

Jérôme Poisson: Cagou(SàT): development progress of the desktop and Android XMPP frontend

Planet Jabber - 14 March, 2017 - 21:56

Salut à Vous !

It's been a little more that one year now that the crowdfunding campain has been successfuly completed, and that we have promised to develop a new Desktop/Android frontend for "Salut à Toi", our Multipurpose, multi frontend communication tool based on XMPP.

It's time for an overview of the state of the development. You'll find below a link to the first .apk (pre-alpha), FOR TESTING PURPOSE ONLY.

Cagou (SàT)

As we've already announced, the new Desktop/mobiles (Android only for now) frontend will be named "Cagou", a wind to the Kivy framework that we're using, and to this endemic bird of New Caledonia, which bark and can't fly.

Oh, and yes we know that "Cagou" has different meaning in different languages.

Development

This part is technical, you can go directly to the next one if you're not interested.

After a short time to get familiar with the Kivy ecosystem, the first step has been to integrate "Quick Frontend", which is a common base that we are using, as you guess, to quickly develop a frontend and factorise the code (cache handling, contact list – or "roster" in XMPP world –, widgets, etc.), then to integrate the "bridge" which is the name that we are using for the IPC and which handle the communication between the backend (which is the heart of SàT) and the frontends.

This phase went relatively well, and was followed by a thought on the architecture and user interface.

Once all of this was more or less usable, the Android port could began.

Things have been a big more complicated there. The Kivy community has created several tools to develop on this platform, including python-for-android (compilation and archive creation tool), and Buildozer (multi-platform tool to facilitate the use of the first one). Using these tools take some efforts, specially for a project already well advanced (it's far more easy if you start directly with Kivy and the Android port).

There a 2 "chains" for developing on Android: the old and the new one. After the first unsuccessful tries with the new one, it has been temporarly put aside for the old one, the time to build the foundations of the port.

Pure Python dependencies can be imported easily, but as soon as it get more complicated, you'll have to creates "recipes" to tell how to build something to python-for-android. Fortunately, most of those needed for SàT (Twisted in particular) were already available, and just needed to be updated.

After all this dependencies and building chain problems solved, and after the joy to see the first .apk (no working), 2 other big troubles showed up: D-Bus which is the main "bridge" is not usable on Android, and how to have the backend and the frontend running together?

Being my first Android development, I've had to read a lot or documentation (which luckily is not lacking), and after a first try with a bridge "embedded", allowing to have backend and frontend in the same process, it's finally a new "pb" bridge which solved the issue. "pb" stands for "Perspective Broker", the Twisted IPC. Android native IPC is an other option to be evaluated in the future.

To launch the backend, Kivy comes with modules to start it as an Android service. With it, the backend can stay in background and process messages and other activities when the frontend is not visible to the user (which means frozen until the user show it again on Android).

This section is already long, so I'll skip other problems (like the lack of HTML widget), and let's now talk about the UI.

UI

At the moment Cagou is usable on desktop (GNU/Linux, but other platforms will most certainly follow), and on Android.

The current release is a pre-alpha, the .apk is available below, only to have a rough idea of the software. It is really bugged, doesn't check yet server certificates, doesn't handle SRV record on Android, etc. This is linked for 2 reasons: showing the progress, and having feedbacks early enought to go in the right direction.

You can't create account from the application (this will come before the release), so if you have no account yet you can use Libervia(SàT), the demo instance of our web frontend, to create one.

main concepts

Cagou's UI take inspiration from the excelent Blender. The widget selection and splitting are the most obvious examples. The huge bars that you can see should disappear later in favor of a small button, which may follow Blender example again. The goal here is that a newcomer can switch widgets intuitively, and an advanced user can use this splitting feature.

The contacts list is not the central element in the interface, it can be displayed if wanted, but it's not needed to use Cagou.

The upper menu, which is for now always visible, will certainly be only available on Desktop. On Android the menu button or a floating touch one should replace it before the release.

If you have notifications, they should appear for a couple of second on the top, but you can read them later by touching the cagou head on the upper left.

If there is an event needing user action (for instance a website needs your authorisation with XMPP), an other cagou will appear on the right, and the dialog will only appear after touching it. The idea is to never have an unwanted popup stealing the focus when you are doing something else: popups are displayed only with explicit user action.

In Android case, it may be replaced by the native notification system in the future, but it's not decided yet because notifications history would not be available anymore.

To change the mode (widget), you just have to click on the upper left button in the current widget. Only 4 widgets are available so far: the selector which display all widgets available, the settings, the contact list, and the chat. Other are planed, notabily the blogging one.

Inside a widget (only for chat so far), you can swipe horizontaly to switch between active conversations.

For now it's not easy to use the first time (you have to do a very quick swipe), it needs some tuning.

As for other SàT parts, Cagou is thought since the beginning to work with plugins and being easy to extend. All the widgets and file transmitting system (see below) are plugins.

instant messaging (chat)

As we want a frontend usable on small screens, which is simple but without making sacrifice on features, we have to find a compromise between data displayed on the screen and the elements/buttons needed for actions. Too many elements will make the UI more complicated and take room, but not enough will make the actions more difficult to do.

The current design (which can evolve) has a header with an input bar and a button (in addition to widget selection button), the body with messages, and a bottom input bar with a button too.

To talk with one or more contact(s), type some letters belonging to its name (anywhere in the name). For now, only identifiers ("jid") and already opened talks are looked for, but later the search will include names, nicknames and bookmarks.

Cagou detect if you want to talk to a single person, or to a group chat room, and will act consequently.

The end 2 end encryption is there, but only with OTR (v2) for the moment. OX (modern OpenPGP) and OMEMO are planed, but it's not sure that they will be available for the next release (they may be there for the following one, 0.8). To use it, you just have to click on the lock, it will be closed if the chat is encrypted, and will have a question mark if your contact is not authenticated.

Let's go directly to the input bar. You'll see on the right a "+" button, click on it and you'll have a sending dialog.

This dialog has 2 buttons on the top, with which you can choose between uploading the file or sending it directly using peer 2 peer. A text under them explain in simple language where your file will go, and if encryption is done (for now all files are sent unencrypted).

This text message is important to let the user understand where the data are transiting, it's the kind of information we plan to put in several locations.

The buttons below are the various transmitting options. On desktop, you can only use a file browser (for now), but on Android you can also send a picture from your gallery, take a new photo or a video, or record a voice message.

He is a screenshot of voice recording:

around Cagou

In addition to the work on Cagou itself, other things have been done.

A now mandatory feature with the explosion of mobile devices, carbon copy has been implemented. Server archives is implemented for long fot blogging, but not yet for chat messages, it will be done before the stable release.

Small binary files handling ("BoB" for "Bits of Binary") is now available. Implentation has been motivated by its use on the friend project Movim.

Delivery receipts and HTTP authentification have been contributed by Chteufleur.

Since the 0.6.1 version, messages handling has been improved, making now possible to implement features like last message correction, planed for the release.

Lastly, component (for gateways) and static blogs have also been implemented, but we'll talk about this later.

help

SàT is a huge project with strong ethical values (check the social contract), and it need help! It can be as easy as coming to talk with us (our room is at sat@chat.jabberfr.org, also availble by clicking here).

If you can, financial aid would of course be useful, we have recently opened an account on the excellent Liberapay.

You can also join us in our association, all informations are available here

And of course contributions are useful, specially development but also translations, icons, CSS, etc. Most of the coding is done in Python, and working on SàT is working on a tool you may use everyday. You'll not find us on big centralised forges, but we are in the process of modernising our development tools (more to come on that).

Talk about our association and project around you is always useful.

I think the most important things have been said, I'll try to keep you up to date with shorted posts.

Oh, and the link with the pre-alpha version (once again: FOR TESTING PURPOSE ONLY): https://www.goffi.org/public/Cagou-0.1-debug.apk

Tigase Blog: tigase-server project structure change

Planet Jabber - 13 March, 2017 - 19:59

Previously, our main project, tigase-server has used a couple of maven modules (separate for the server sources, documentation and one responsible for building distribution packages). Unfortunately for equally as long, the file structure did not follow the standard maven structure.

Tigase Blog: XMPP Summit 21 Reflections

Planet Jabber - 8 March, 2017 - 00:56

The XMPP Standards foundation had its 21st Summit this past month in Brussels, Belgium just prior to a strong showing at FOSDEM in the same city.

Erlang Solutions: 21 XMPP use-cases and the best ways to achieve them

Planet Jabber - 2 March, 2017 - 16:36
<h2>Who will find this interesting</h2> <p>If you’re considering XMPP for your project but you are unsure if it can provide the functionality you need, you’ll eventually end up here:</p> <p><a href="http://xmpp.org/extensions/">http://xmpp.org/extensions/</a></p> <p>I’m pretty sure you’ll be quite intimidated by such a long list of extensions. In some cases it will be pretty easy to find what you need. If you look for PubSub functionality, you’ll quickly notice “Publish-Subscribe”. Sometimes it’s not so obvious though. XMPP developers already know that in order to synchronise outgoing messages between several devices, they have to enable “Message Carbons”. Not very intuitive, isn’t it?</p> <p>The aim of this blog post is to guide you towards proper XMPP technologies and solutions, given your specific use cases. I’ve worked with and deployed solutions powered by XMPP, such as <a href="https://www.erlang-solutions.com/products/mongooseim.html#/">MongooseIM</a>, for years; so let me be your personal Professor Oak, providing a perfect “companion(s)” to work with and begin your journey in XMPP world. There are almost 400 XEPs, will you catch them all? ;)</p> <p>The length of this article is caused not by a complexity of descriptions but by a count of use cases and features. :)</p> <p>All numbers and information on implementation status are valid for March 2017.</p> <h3>What can you expect here?</h3> <p>For every use case, I will list XMPP features you definitely should consider using. Each one of them will be briefly described. The goal here is to understand the usefulness without reading whole specification. Besides that, each item will include MongooseIM’s module name providing discussed extension and example client implementations.</p> <h3>What you <em>won’t</em> find in this post</h3> <p>This post won’t cover any XMPP basics. It assumes you either know them already (what are JID, C2S, S2S, IQ, stanzas, stream etc.) or you intend to learn them from some other guide, like the excellent (iOS) tutorial written by Andres Canal <a href="https://www.erlang-solutions.com/blog/build-a-complete-ios-messaging-app-using-xmppframework-tutorial-part-1.html">Part 1</a>, <a href="https://www.erlang-solutions.com/blog/build-a-complete-ios-messaging-app-using-xmppframework-part-2.html">Part 2</a>). It’s more of a cookbook, not Cooking For Dummies.</p> <h2>ToC</h2> <ol> <li>I’m creating …<br> 1.1 … a mobile application.<br> 1.2 … a desktop application.<br> 1.3 … a web application.<br> 1.4 … an application that just can’t speak XMPP.</li> <li>I need my application to …<br> 2.1 … show message status like Facebook does.<br> 2.2 … provide message archive to end users.<br> 2.2.1 I’d like to have a full text search feature.</li> <li>… display inbox (a list of conversations with unread count and a last message).</li> <li>… allow file transfers and media sharing between users.<br> 4.1 P2P<br> 4.2 File Upload</li> <li>… support groupchats …<br> 5.1 … and I need precise presence tracking in each group.<br> 5.2 … and I don’t need to broadcast presence information in each group.</li> <li>… be compatible with other public XMPP setups.</li> <li>… present the same view of each conversation on every user’s device.</li> <li>… allow users to block each other.</li> <li>… support end-to-end encryption.</li> <li>… be a part of Internet of Things.</li> <li>… receive push notifications.</li> <li>… publish messages to groups of subscribers.</li> </ol> <h2>1. Creating …</h2> <p>Before we proceed to more specific requirements, it’s important to identify crucial standards based on your application type.</p> <h3>1.1 … a mobile application.</h3> <p>Smartphones are omnipresent nowadays. It’s a fact. The whole software market considered, mobile apps are an important medium between various companies and their customers. Some of them are the actual products (games, communicators, car navigations, etc.), not only a “channel”. If you’re going to develop a mobile application, you will need…</p> <p><strong>XEP-0198 Stream Management</strong></p> <p>It’s an extension that provides two features actually. One of them is stanza delivery confirmation (both server and client side), what allows early detection of broken connections or malfunctioning network layer. The other one is stream resumption. It makes reconnection faster by reducing the round-trip count and relieves the client of fetching message archive as pending, unacknowledged messages will be retransmitted from server buffer.</p> <p>It is enabled by default in MongooseIM and supported by major client libs like Smack or XMPPFramework. From a client developer perspective, it’s pretty transparent because the whole extension is enabled with a single flag or method call.</p> <p><strong>MUC Light, MIX, Push notifications, HTTP File Upload</strong></p> <p>These extensions are especially useful in the mobile environment. Why? With <strong>MUC Light</strong> and <strong>MIX</strong> you gain control over presence broadcasting - you can spare your users frequent radio wakeups and bandwidth usage. These extensions are a significant improvement over traditional presence-driven group chats.</p> <p>Virtually every app on our smartphones uses push notifications. Some are useful and some are just annoying commercials. It doesn’t matter - it’s almost certain you’ll want them integrated with your XMPP service.</p> <p>HTTP File Upload allows asynchronous media sharing, which is much more convenient in the case of group chats and doesn’t require both parties to stay online during the transfer.</p> <p>These are just brief summaries. You can find more details further in this post.</p> <h3>1.2. … a desktop application.</h3> <p>Despite mobile phones’ expansion and software products exclusive for them (Instagram, Snapchat, Tinder, etc.), nobody can deny the comfort of UI operated with a mouse, keyboard, or tablet. Some apps simply require processing power that portable devices can’t provide. If your code is going to be executed on desktops PCs and laptops, you’ll appreciate…</p> <p>There are no extensions that are strictly essential for desktop apps. Everything depends on specific applications. Just bear in mind that the standards important for mobile apps are generally useful for desktop ones too, only less critical.</p> <h3>1.3. … a web application.</h3> <p>As the days of heavy browser incompatibility (thank you, standardisation!) and Flash technology abuse are long gone, web applications are a great way to provide cross-platform solutions. It’s not only easier to reach more platforms but also to ensure the users are always running the most up-to-date version.</p> <p>If you’re a web developer, you’re going to connect to the XMPP server via <strong>BOSH</strong> or <strong>Websockets</strong>.</p> <h4><strong>Websockets</strong></h4> <p>Websockets technology allow to upgrade an HTTP connection to an asynchronous, full-duplex, binary one (a bit of simplification but it’s the essence). It means that XMPP stanzas can be exchanged almost as efficiently as over a raw TCP connection (Websockets add small overhead of integer with packet size). It’s the recommended protocol for single-page apps.</p> <p><strong>Note:</strong> You can combine <strong>Stream Management</strong>'s resumption with Websockets, although it will still be slower than BOSH’s session <strong>pause</strong>.</p> <p><strong>Warning:</strong> Websockets are not implemented by old browsers. If you have to support any outdated clients, take a look at <a href="https://en.wikipedia.org/wiki/WebSocket#Browser_implementation">this table</a> first.</p> <h4><strong>BOSH</strong></h4> <p>Defined in <strong>XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)</strong> and <strong>XEP-0206: XMPP Over BOSH</strong>. This protocol encapsulates XMPP stanzas in HTTP requests. It also simulates asynchronous, bidirectional communication by issuing long polling requests from client to the server to retrieve live data. What does it mean in practical terms?</p> <p>A persistent connection may be maintained but in general BOSH is designed to deal with interrupted connections. It’s a perfect solution for web apps that trigger browser navigation. On such event, all connections made by e.g. JavaScript from browser are closed but the BOSH session survives it on the server side (not forever of course) and the client can quickly and efficiently resume the session after page reload.</p> <p>The protocol is pretty verbose though, so if you don’t need this feature, go for Websockets.</p> <h3>1.4. … an application that just can’t speak XMPP.</h3> <p>You probably think that I’m crazy; why use XMPP with XMPP-less clients? Let’s change the way we think about XMPP for a moment. Stop considering XML the only input data format the XMPP server accepts. What if I told you that it’s possible to restrict XML to the server’s routing core and just make REST calls from any application? Tempting?</p> <p>It’s a non-standard approach and it hasn’t been documented by XSF (yet), but MongooseIM already exposes most important functionalities via REST. Check out <a href="https://github.com/esl/MongooseIM/blob/master/doc/REST-API.md">this</a> and <a href="http://mongooseim.readthedocs.io/en/latest/swagger/index.html?client=true#/">this document</a> to find out more.</p> <h2>2. I need my application to …</h2> <p>Now we continue to more specific use cases.</p> <h3>2.1. … show message status like Facebook does.</h3> <p>By message status we mean following states (plus live notifications):</p> <ol> <li>Not sent to server yet.</li> <li>Acknowledged by the server.</li> <li>Delivered to the recipient.</li> <li>Displayed by the recipient.</li> <li>User is composing a message.</li> <li>User has stopped composing a message.</li> </ol> <p>(1) and (2) are handled by <strong>Stream Management</strong>. It’s pretty obvious - before receiving an <strong>ack</strong> from the server, you are in (1); and <strong>ack</strong> confirms the message entered state (2).</p> <p>We can deal with (3) and (4) by using <strong>XEP-0333: Chat Markers</strong>. These are special stanzas sent by a recipient to the original sender. There are dedicated markers for <strong>received</strong> and <strong>displayed</strong> events.</p> <p>(5) and (6) are provided by <strong>XEP-0085: Chat State Notifications</strong>. It is up to a client to send updates like <code>&lt;composing/&gt;</code> and <code>&lt;paused/&gt;</code> to the interlocutor.</p> <h3>2.2. … provide message archive to end users.</h3> <p>Virtually every modern chat application maintains conversation history both for 1-1 communication and group chats. It can remind you of a promise you’ve made, be evidence in a divorce case, or help in police investigation.</p> <p>XMPP provides two protocols for accessing message archives. The older one, <strong>XEP-0136 Message Archiving</strong> is used by hardly anyone, because it’s difficult to implement and overloaded with features. It has been superseded by more modern <strong>XEP-0313 Message Archive Management</strong>, which is the current standard.</p> <p>There is one caveat though - its syntax changed significantly between versions, so it’s common for libraries and servers to explicitly state what versions are supported by the specific piece of software. These are 0.2, 0.3 and 0.4(.1) and 0.5. MongooseIM supports all of them in <code>mod_mam</code> module. If you choose another server, make sure its MAM implementation is compatible with your client library. Smack and XMPPFramework use 0.4 syntax.</p> <h4><strong>2.2.1. I’d like to have a full text search feature.</strong></h4> <p>Although standard Message Archive Management doesn’t specify any queries for full text search, it remains flexible enough to create such requests on top of the existing ones.</p> <p>In MongooseIM this feature is still in experimental phase and has been recently merged into <a href="https://github.com/esl/MongooseIM/pull/1136">master branch</a>. It’s not supported in any client library yet, so you have to construct a custom MAM query to do full text searches. Take a look at the <a href="https://github.com/esl/MongooseIM/pull/1136">PR description</a>, It’s not that difficult. :)</p> <h3>2.3. … display inbox (a list of conversations with unread count and a last message).</h3> <p>Unfortunately there are no open solutions providing this feature. XMPP community is in the process of discussing and creating the specification of Inbox functionality. Erlang Solutions is designing a XEP proposal, which you can view <a href="https://github.com/esl/MongooseIM/blob/inbox-proto-xep/doc/open-extensions/xeps/xep-inbox.html">here</a>.</p> <p>A quasi-inbox is available as a part of experimental standard <strong><a href="https://xmpp.org/extensions/xep-0386.html#example-3">Bind 2.0</a></strong>. It doesn’t cover all possible use-cases but a list of unread messages is what you actually need for optimal UX after establishing a connection. This feature is already under development in MongooseIM project.</p> <p>In the meantime, you can build an inbox view by persisting last known archived message ID or timestamp and query Message Archive Management for all messages that came later. When you fetch them all, you can build an inbox. Unfortunately this is not very efficient and that’s why the community needs a new standard.</p> <h3>2.4. … allow file transfers and media sharing between users.</h3> <p>Almost everyone loves to share cat pictures and every modern IM solution provides means to do this. Various file transfer techniques in the XMPP world can be grouped in two categories: P2P connections and file upload.</p> <p>The former involves establishing a direct connection between two clients, sometimes with a bit of a help from a TURN server. It ensures that data won’t get stored on any intermediate servers. Obviously, it requires less effort from the service provider because it’s easier and cheaper to set up a TURN service than to maintain a proper media server (or pay for storage in the cloud).</p> <p>File upload is much more efficient when sharing media with a group. It doesn’t require both parties to remain online for the transfer duration.</p> <h4><strong>2.4.1. P2P</strong></h4> <p>Now, you <em>DO</em> have a choice here. There are a couple of XEPs, describing various P2P transfer initiation methods. <strong>XEP-0047 In-Band Bytestreams</strong> (IBB) is guaranteed to work in every network, because it sends data (Base64-encoded) via IQs. So if you can reach the XMPP service, you can transfer files. It may be slow and not very convenient but it <strong>will</strong> work.</p> <p>Let’s carry on. You can transfer media via bytestreams external to XMPP. The P2P session is negotiated via XMPP but it’s only the “signalling” part. There are quite a few XEPs describing various negotiation and transmission protocols, so I will highlight specific implementations rather than listing all of the names which would only confuse readers who just want to send some bytes.</p> <ul> <li><strong>XMPPFramework</strong>: Look for <code>XMPPIncomingFileTransfer</code> and <code>XMPPOutgoingFileTransfer</code>. They support SOCKS5 and In-Band Bytestreams.</li> <li><strong>Smack</strong>: Everything begins with <code>FileTransferManager</code>. It supports SOCKS5 and In-Band Bytestreams as well. <br><br></li> </ul> <h4><strong>2.4.2. File Upload</strong></h4> <p>Unless you already have a dedicated media server that exposes an API to perform uploads and downloads, you should definitely take a look at <strong>XEP-0363 File Upload</strong>. It defines standard stanzas to request upload slots and respective download links. It is XMPP server’s responsibility to allocate the slots and return the links to the client.</p> <p>Unfortunately this extension is not widely supported yet. You can find it in XMPPFramework but not in Smack yet. In the case of MongooseIM, it’s already available with Amazon S3 backend (with more storage plugins to come!).</p> <h3>2.5. … support group chats …</h3> <p>A couple of years ago it was really simple - there was only one kind of group chat supported in the XMPP world. Today we have three standards, two of them being maintained by XSF and one <a href="http://mongooseim.readthedocs.io/en/latest/open-extensions/muc_light/">published by Erlang Solutions</a>. MIX (XEP-0369), doesn’t have any implementations yet and as a standard it changes very frequently, so it is not described in this post.</p> <h4><strong>2.5.1. … and I need precise presence tracking in each group.</strong></h4> <p>If you need IRC-like experience where users have certain roles in a room and client disconnection triggers leaving the room, then classic <strong>XEP-0045 Multi-User Chat</strong> will work for you. It has its disadvantages (frequent presence broadcast may impact UX and consume processing power or connection throughput) but fits the use case, where accurate presence information is important. It is provided by MongooseIM’s <code>mod_muc</code> (other major servers implement it as well) and is supported by all mainstream client libs.</p> <h4><strong>2.5.2. … and I don’t need to broadcast presence information in each group.</strong></h4> <p>Erlang Solutions’ <strong>Multi-User Chat Light</strong> is a protocol derived from real world use cases, where groups doesn’t care about presences and full member list is always available to room members. It has some strong assumptions (like only 2 types of affiliation or rooms being joinable only by invite) but is designed to reduce round-trips, expose powerful API (e.g. room creation + configuration + adding new members in one request) and be easy to work with. <a href="http://mongooseim.readthedocs.io/en/latest/open-extensions/muc_light/">Check it out</a> and see if it fits in your application. Server implementation is currently exclusive to MongooseIM (<code>mod_muc_light</code>) and respective plugins are available in Smack and XMPPFramework.</p> <h3>2.6. … be compatible with other public XMPP setups.</h3> <p>Even some proprietary installations do integrate with open XMPP world (like GTalk and Facebook at some point), so if this is your use case as well, the first important thing to remember is that no custom stanzas may leave your cluster. By custom I mean anything that is not covered by any XSF-approved XEP. Additionally, you will really benefit from using <strong>XEP-0030 Service Discovery</strong> protocol a lot, because you can never be sure what is the supported feature set on the other end. It is used to query both clients and servers. Virtually every client and server supports it. In case of MongooseIM, the base module is <code>mod_disco</code>.</p> <h3>2.7. … present the same view of each conversation on every user’s device.</h3> <p>I use Facebook messenger on multiple devices and I really expect it to display the same shopping list I got from my wife on both my desktop and my mobile phone. It usually breaks message order but anyway - at least the list is there.</p> <p>The problem is actually a bit more complex, because you have to take care of synchronising both online and offline devices.</p> <p>Online devices can ask the server to forward all incoming/outgoing messages, even if they originate from or are addressed to some other resource of the same user. It is achieved by enabling <strong>XEP-0280 Message Carbons</strong>. On the client side it’s easy - just enable the feature after authenticating and the server will do the rest. It’s supported by MongooseIM in mod_carboncopy module. You can find respective implementations in Smack, XMPPFramework, <a href="http://Stanza.io">Stanza.io</a> and many others, since it’s a very simple, yet powerful extension.</p> <p>If you want to fetch everything that happened while a specific device was offline for a while, just query <strong>XEP-0313 Message Archive Management</strong> (see “… provide message archive to end users.” section).</p> <h3>2.8. … allow users to block each other.</h3> <p>You just can’t stand your neighbour nagging you via IM to turn down the volume while Kirk Hammett is performing his great solo? Block him. Now. XMPP can help you with it. In two ways actually.</p> <p>Yes, XMPP features two standards that deal with blocking: <strong>XEP-0016 Privacy Lists</strong> and the simpler <strong>XEP-0191 Blocking Command</strong>. The former allows users to create pretty precise privacy rules, like “don’t send outgoing presences to JID X” or “accept IQs only from JIDs in my roster”. If you need such a fine grained control, take a look at MongooseIM’s <code>mod_privacy</code>. On the client side it is supported by the likes of Smack and XMPPFramework.</p> <p><strong>Blocking Command</strong> is much simpler but most setups will find it sufficient. When a client blocks a JID, no stanza will be routed from the blockee to the blocker. Period. MongooseIM (<code>mod_blocking</code>), Smack and XMPPFramework have it.</p> <h3>2.9. … support end-to-end encryption.</h3> <p>When Alice wants to send a message to Bob… no, we’ve all probably seen this classic example too many times already. :)</p> <p>There is no “one size fits all” when it comes to E2E encryption. The first tradeoff you’ll have to make is to decide whether you want new users devices to be able to decrypt old messages, or do you prefer to have a property of forward secrecy. For a full comparison between available encryption methods, let’s take a look at the table published by <a href="https://conversations.im/omemo/">OMEMO authors</a>:</p> <style type="text/css"> .tg {border-collapse:collapse;border-spacing:0;} .tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 10px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;} .tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 10px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;} .tg .tg-yw4l{vertical-align:top} .tg .tg-9hbo{font-weight:bold;vertical-align:top} </style> <table class="tg" style="undefined;table-layout: fixed; width: 780px"> <colgroup> <col style="width: 176px"> <col style="width: 151px"> <col style="width: 151px"> <col style="width: 151px"> <col style="width: 151px"> </colgroup> <tr> <th class="tg-yw4l"></th> <th class="tg-9hbo">Legacy Open PGP</th> <th class="tg-9hbo">Open PGP</th> <th class="tg-9hbo">OTR</th> <th class="tg-9hbo">OMEMO</th> </tr> <tr> <td class="tg-9hbo">Multiple Devices</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">No</td> <td class="tg-yw4l">Yes</td> </tr> <tr> <td class="tg-9hbo">Offline Messages</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">No</td> <td class="tg-yw4l">Yes</td> </tr> <tr> <td class="tg-9hbo">File Transfer</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Non-standard</td> <td class="tg-yw4l">Non-standard</td> <td class="tg-yw4l">Yes</td> </tr> <tr> <td class="tg-9hbo">Verifiability</td> <td class="tg-yw4l">No</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Yes</td> </tr> <tr> <td class="tg-9hbo">Deniability</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">No</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Yes</td> </tr> <tr> <td class="tg-9hbo">Forward Secrecy</td> <td class="tg-yw4l">No</td> <td class="tg-yw4l">No</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Yes</td> </tr> <tr> <td class="tg-9hbo">Server Side Archive</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">Yes</td> <td class="tg-yw4l">No</td> <td class="tg-yw4l">No</td> </tr> <tr> <td class="tg-9hbo">Per Message Overhead</td> <td class="tg-yw4l">High</td> <td class="tg-yw4l">High</td> <td class="tg-yw4l">Low</td> <td class="tg-yw4l">Medium</td> </tr> </table><br> <p>It’s difficult to find an open library that supports any of these methods. Gajim communicator has an OMEMO plugin. Smack and XMPPFramework don’t support E2E encryption in their upstream versions. If you’re going to use E2E encryption in your application, most probably you’ll have to implement it on your own. Good thing is there are standards you can base your code on.</p> <h3>2.10. … be a part of Internet of Things.</h3> <p>We are a peculiar bunch. We use semiconductors to build machines that do heavy number crunching for us, deliver messages in a blink of an eye and control robotic arms with precision far beyond ours. A desire has awoken in us to go even deeper and augment everything with electronics. To let <strong>everything</strong> communicate with each other.</p> <p>If you’re designing a fridge microcontroller that is supposed to fetch results from bathroom scales and lock the door for 8h for every excessive BMI point, you’ll need…</p> <ul> <li><strong>XEP-0323 Internet of Things - Sensor Data</strong></li> <li><strong>XEP-0324 Internet of Things - Provisioning</strong></li> <li><strong>XEP-0325 Internet of Things - Control</strong></li> <li><strong>XEP-0326 Internet of Things - Concentrators</strong></li> <li><strong>XEP-0347 Internet of Things - Discovery</strong> <br><br></li> </ul> <p>Unfortunately there are no public implementations of these standards. I wish it was easier but it seems you just can’t avoid reading these XEPs, picking the most suitable parts and creating your own implementation.</p> <p>To find out more and become an active member of XMPP IoT community, check out <a href="https://wiki.xmpp.org/web/IoT_SIG">IoT Special Interest Group</a>.</p> <h3>2.11. … receive push notifications.</h3> <p>Push Notifications are (usually) doing a great service to mobile devices’ battery life. It is great indeed that a single TCP connection is maintained by OS, while apps can remain hibernated in the background. It is natural to every chat application to deliver notifications to the end user, even when a smartphone is resting in the pocket. How does XMPP cooperate with popular services like APNS or GCM?</p> <p>It depends.</p> <p>Although it’s not difficult to find <strong>XEP-0357 Push Notifications</strong>, it deserves some explanation. This specification is <strong>very</strong> generic. It assumes the existence of another XMPP-enabled “App server” that handles push notifications further. Although implementations could be found (e.g. in MongooseIM or Prosody server), it is very common for commercial installations to use custom protocols to provide push tokens and send PN packets directly to the respective services (APNS, GCM, SNS…)</p> <h3>2.12. … publish messages to groups of subscribers.</h3> <p>Publish-subscribe is an ancient and extremely useful pattern. XMPP got its own PubSub specification quite early (first versions were published in 2003) and even though the protocol is pretty verbose (and a bit complicated), for the basic usage you’ll need to learn only the most important aspects: there are nodes in the PubSub service where publishers can publish data. Nodes can group other nodes or remain plain leaves. That’s the whole story. The rest is about configuration, access control, etc.</p> <p><strong>XEP-0060 Publish-Subscribe</strong> is implemented in every major XMPP piece of software. In case of MongooseIM, it’s handled by <code>mod_pubsub</code>. You can find in popular client libraries as well: Smack, XMPPFramework or <a href="http://Stanza.io">Stanza.io</a>.</p> <h2>Set sail!</h2> <p>Now, if you feel brave enough, you can dive into this looong, official list of XEPs. These documents are designed to provide a precise information for libs and server developers. In your daily routine you’ll probably won’t care about every server-side edge case or whether some information is encapsulated in element X or Y. These are perfect reference guides for if you’re stuck somewhere or need to tap into lib’s plugin internals.</p> <p>I’d recommend one more intermediate step though. Browse servers’ and clients’ feature lists published by virtually every project on their webpages. They usually skip (or enumerate them in separate, more detailed docs) minor items and highlight the features that may be important to you. This way you’ll expand your XMPP vocabulary and knowledge, while postponing the stage where reading XEPs is unavoidable, thus making the learning curve less steep.</p> <p>It won’t be long until you realise that XMPP is your friend, I promise. :)</p> <p>Stay tuned for Part 2! In the meantime, you can brush up on your XMPP basics with our guide to building an iOS app from scratch using XMPPFramework (parts <a href="https://www.erlang-solutions.com/blog/build-a-complete-ios-messaging-app-using-xmppframework-tutorial-part-1.html">1</a> and <a href="https://www.erlang-solutions.com/blog/build-a-complete-ios-messaging-app-using-xmppframework-tutorial-part-1.html">2</a>), or learn more about <a href="https://www.erlang-solutions.com/products/mongooseim.html?utm_source=XMPP%20Flavour%20Guide%20p1&amp;utm_medium=blog#/">MongooseIM</a>, Erlang Solutions’ XMPP platform.</p>

Ignite Realtime Blog: Google Summer of Code 2017

Planet Jabber - 2 March, 2017 - 09:47

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

 

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

 

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

The XMPP Standards Foundation: XMPP and the GSoC 2017

Planet Jabber - 2 March, 2017 - 08:44

We're delighted to have been accepted in the Google Summer of Code yet again. The XSF has participated in GSoC many times in the past, and it's always great to have the opportunity to work with the enthusiastic and capable students we see and to bring new views and abilities into the community.

We've got a wide range of projects offering to participate this year, and some great mentors, so this should be a really good year, all we need is the students. The XSF's ideas list is up at https://wiki.xmpp.org/web/Summer_of_Code_2017, and if you've got ideas of your own we'll happily discuss them with you, so if you're an eligible student please get in touch, we'd love to start talking to you. If you've decided you'd like to apply for one of the great projects we have on offer, please proceed to Google's Getting Started Page.

We're looking forward to working with you over the summer!

The XMPP Standards Foundation: XMPP Summit 21

Planet Jabber - 27 February, 2017 - 17:50

This year, the XMPP Standards Foundation again gathered in force to attend the summit, that traditionally precedes the FOSDEM event in Brussels, Belgium. Barely fitting in the (rather sizable) room that was made available to us by Cisco, the XSF members had a fruitful two-day meeting.

Day two @xmpp Summit21. #xmpp2017 #IoT pic.twitter.com/Z0xNFBdoiY

— Rikard Strid (@rikardstrid) February 3, 2017

The attending members, skillfully herded by Kev, addressed an impressive number of topics, including:

  • BIND2, improving the data exchange that occurs when an XMPP entity initially connects to a server.
  • MIX, the XEP that intends to be a replacement for the existing MUC protocol, bringing an up-to-date feature set and better extensibility.
  • Addressing the annoyance of instant-messaging-based spam.
  • The application of existing, or to be developed XMPP standards, to facilitate the growing world of Internet-of-Things.
  • The XSF intention to take part in this years Google Summer of Code.
  • Improvements to the existing end-to-end encryption, as defined in the OMEMO XEP.

The full minutes are made available in the XSF wiki. If any of these topics (or others for that matter) interest you, we'd love to hear from you. Please find us at xmpp.org, use the mailinglists to contact us, or find us in one of the dedicated MUCs.

#XMPP2017 Summit Dinner! pic.twitter.com/cbJCztuhmn

— Marcelo Terres (@mhterres) February 2, 2017

Many thanks to everyone involved in making the summit happen, including Cisco Belgium, Surevine, AG Software, Isode, Prosody, Erlang Solutions and Clayster for providing much appreciated sponsoring for the event, as well as the traditional XSF Member dinner!

Apart from the discussions, the summit proved to be an excellent opportunity for some of the newer members amongst us, myself included, to make acquaintance with the others. I, for one, am grateful to have been there, and am looking forward to the next meetup!

ProcessOne: ejabberd 17.03-beta

Planet Jabber - 27 February, 2017 - 15:59

New modular code, flexible core backend, dynamic configuration reload, spam protection and routing API changes.
These are the most interesting improvements coming in 17.03 and we are very happy to share a first snapshot as a beta version.

As usual, we also included several other improvements and many bug-fixes. In summary, almost 3K new lines of code and other 10K changed lines.

Improvements Modular code

New modular code allows to develop modules for a wide scope of functionalities without patching the core code such as C2S, S2S and router.

Routing API

Now ‘From’ and ‘To’ arguments must be omitted in functions and structures related to routing.
The commit deprecates the following functions:

  • ejabberd_router:route/3 in favor of ejabberd_router:route/1
  • ejabberd_router:route_error/4 in favor of ejabberd_router:route_error/2
  • ejabberd_local:route_iq/4 in favor of ejabberd_local:route_iq/2
  • ejabberd_local:route_iq/5 in favor of ejabberd_local:route_iq/3

The format of {route, From, To, Packet} is changed in favor of {route, Packet}.
API changes will be better described with 17.03 release when new API documentation will be completed.

Flexible core backend

Ejabberd used to store all in-memory shared data such as ACLs, proxy65, sessions, routes, clustering, etc in internal Mnesia database and this used to be hardcoded. With new API it’s now possible to store such data in any database.
However, currently only Mnesia backend is supported, but we’re working on implementing other backends (redis, sql) in future releases.
For the record, it’s already possible to store client sessions in Redis and/or SQL servers, the API was just extended to make it possible to implement such a backend for any in-memory shared data.

New features Dynamic configuration reload

Using ‘reload_config’ ejabberd’s command it is now possible to reload modules, database connections, ACLs and global options without restarting ejabberd. Ability to reload other core components (listeners, loglevel, etc) will be added in 17.03 release.
Thanks to this improvement, it’s now possible to add and remove virtual hosts via configuration reload.

Spam protection

If you want to get ride of XMPP SPAM, best option is now to use our new feature implemented by mod_block_strangers. This module just allow to block packets from non-subscribers, this means you won’t receive messages from users not registered in your roster.

S2S dialback

S2S dialback is now an optional module. If not present in the configuration, only TLS mechanism can be used to establish S2S connections.

Upgrade

While upgrading an existing system, you need to care about few required changes. In order to enable S2S dialback, stream management (XEP-0178), legacy client auth or the new anti-spam feature, the following modules should be added to ejabberd’s configuration:

  • mod_s2s_dialback
  • mod_stream_mgmt
  • mod_legacy_auth
  • mod_block_strangers

If you have issues using PubSub with Postgres backend, please check the full schema update from sources.
While in runtime, you can run the following bare minimal changes to fix PubSub

ALTER TABLE pubsub_state ALTER COLUMN subscriptions SET DEFAULT '';
UPDATE pubsub_state SET subscriptions='' WHERE subscriptions=null;

Changes

Here are the most relevant changes

Developer
  • tools/hook_deps.sh: checks hook dependencies
  • tools/find-outdated-deps.pl: checks which dependences need update
  • Mark as deprecated add/get_local/global_option config functions
  • Change routing API
Core
  • Fix some corner cases while re-reading RFC6120
  • Attach IP metadata to every stanza received from stream
  • Apply SASLprep before storing/converting passwords
  • Send compressed in correct order
  • Reset XML stream before sending SASL success
  • Speedup features list when a lot of virtual hosts configured
  • Fix s2s_dns_timeout issues
  • Better handling of IPv6 domains
  • Rename mod_sm -> mod_stream_mgmt
  • Don’t count resent stanzas
Admin
  • Add ‘supervisor’ listening option
  • Accept “add_commands: admin” in commands section
  • Make sure that api_permissions always have “console commands” section
  • Change name of pam dep from p1_pam to epam
  • Improve compilation with rebar3
  • Add TLS support for external components
  • Specify “ExecReload” command in systemd unit
  • Don’t attempt to resolve _jabber._tcp SRV record
  • Improve error reporting for forbidden servers
  • mod_block_strangers: New module to block packets from non-subscribers
  • mod_register: Report password change in the log
  • Remove relict mod_service_log
  • Remove unused mod_ip_blacklist
  • Remove ejabberd_frontend_socket
API & Commands
  • get_last now always returns tuple with UTC XEP-0082 and status
  • Protect users from delete_old_users command using a fixed access rule
  • Separate list of strings with \n for srg_get_info in mod_http_api
  • Support non-JID lines in command create_rooms_file
  • stop_all_connections now stops all s2s connections via supervisor calls
  • Support scrammed passwords in ejabberdctl import_prosody
Config reload improvements
  • Start/stop auth modules when host is added/deleted
  • Improve modules start/stop procedures
  • Check result of gen_mod:start/2 callback
  • Improve reload_config admin command
  • Start/stop virtual hosts when reloading configuration file
  • Reload modules when reloading configuration file
  • Make sure all hooks are called with proper host
Databases
  • Add missing NOT NULL restrictions in schemas
  • Move archive tables into lite.sql for better comparison with other schemas
  • Implement database backend interface for mod_proxy65
  • Implement database backend interface for MUC, BOSH and auth_anonyous
  • Implement database backend interface for ejabberd_router
New XMPP stream behavior
  • Reflect cyrsasl API changes in remaining code
  • Improve return values in cyrsasl API
  • More refactoring on session management
  • Add xmpp_stream_out behavior and rewrite s2s/SM code
  • Rewrite ejabberd_service to use new XMPP stream API
MAM & offline storage
  • Make a message is not bounced if it’s archived
  • Archive message before delivering it to offline storage
  • Include stanza ID with archived offline messages
  • Add stanza-id to every archived message
PubSub
  • Avoid orphan_item leak on affiliation/subscription removal
  • Fix pubsub SQL schemas, add NOT NULL restrictions
  • Fix last item cache for multiple hosts
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.

Justin Karneges: Delta XMPP project shutdown

Planet Jabber - 26 February, 2017 - 23:35

Back in the mid-2000s, when Psi was becoming popular and many applications were using its codebase, the Delta XMPP project was formed as a way to manage everything going on. Libraries were given their own websites, version control, and mailing list, to make them more attractive to outside developers. Ambitious goals beyond Psi were also set, such as the development of alternative clients with friendlier UIs, mobile clients, and even a server.

In recent years, it’s clear that no top-level “Delta” XMPP projects other than Psi are being pursued by the original team, and, with the exception of QCA, most development and discussion about our libraries occurs within the context of Psi (or Psi+). It is with this realization that I’ve decided to shut down the Delta XMPP project. As an umbrella project, it wasn’t serving any useful purpose anymore, and its grandiose roadmap is no longer realistic given current development interests and constraints.

To be clear, development on Psi and its libraries remains active, it’s just that the Delta wrapping is no longer needed.

All project websites have been moved off of delta.affinix.com. Their new homes:

The Delta website featured a blog written by me. Selected posts have been migrated to a personal blog for archival purposes: http://jblog.andbit.net.

Ignite Realtime Blog: Openfire 4.1.3 Release

Planet Jabber - 24 February, 2017 - 21:37

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

 

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

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

2b84acd3dbe6648ec4b08c81d912405d2ba78d5b

openfire-4.1.3-1.i686.rpm459Linux RPM (No JRE)b18f1b51bf131b7aff90af92fd4c7dce79ca2d51openfire-4.1.3-1.noarch.rpm335Linux RPM (64bit JRE)d9c52cd0029feb5e8b916410cea55d654f56b54b openfire-4.1.3-1.x86_64.rpm1413Linux .debda7ea0c5bd48c519b4b4a10a5af9160d77dce30bopenfire_4.1.3_all.deb2440Mac OSa76aa1612fa8066d76bab191f6fb7885b62c4195 openfire_4_1_3.dmg506Windows EXE12110eaa952c2bb9f0142aa5ecd67bde399ce5beopenfire_4_1_3.exe5104Binary (tar.gz)163c4f21bf34528fe3909e5be405d156911874feopenfire_4_1_3.tar.gz1066Binary (zip)fde35bc78d875ceb83d9c39be7d2f1a71c9c640aopenfire_4_1_3.zip1147Source (tar.gz)f270729ee6c7c530a7e927d728da7f136ff136f7openfire_src_4_1_3.tar.gz206Source (zip)a04a712c0a9a73acc4c6f4b8b3fbd812528d65b2openfire_src_4_1_3.zip687

 

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

 

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

Erlang Solutions: MongooseIM 2.0.1 more stability for app developers

Planet Jabber - 22 February, 2017 - 16:41
<h2>SSE for server to client real-time push</h2> <p>SSE stands for <a href="https://www.w3.org/TR/eventsource/">Server-Sent Events</a>, it is a W3C recommendation where a browser receives automatic updates from a server via HTTP connection. It is for mobile and web developers using the MongooseIM REST API. It is not intended to be used with XMPP connections (TCP, websockets, BOSH).</p> <p>The problem with a simple REST API is that it is polling only: the client has to continuously poll the server at regular intervals, even when there is nothing to expect, “just in case”. This regular polling consumes a lot of battery on the client and bandwidth both on the client and server, all for nothing. Also, this introduces some delay, as data can be made available on the server between the polling interval.</p> <p>SSE allows a very simple and basic push from server to client, with just a tiny library to use in your app. SSE is very easy to integrate on the client, saves battery and bandwidth, and is fully real-time (no delay).</p> <h2>Improved Cassandra for MAM</h2> <p>Sysadmins and devops will love the return of support for the Cassandra database.</p> <p>Our support for Cassandra in versions below 2.0.0 was average. Sometimes it was slow, and it had limited support of MAM (Message Archive Management) specifications, so we decided to remove it and bring it back once it was fully production ready.</p> <p>Now MongooseIM supports Cassandra again, with optimised code and improved support for MAM, and it comes bundled with a migration tool. Cassandra for MAM in MongooseIM is now faster and easier to upgrade.</p> <h2>HTTP file upload</h2> <p>This will help all app makers.</p> <p>The file exchange in XMPP is usually and historically off chats: it is made with a synchronous user experience, with an offer and an acceptation or refusal whereby you have to wait for the other party to accept or refuse. In many cases there are failures due to timeouts.</p> <p>The solution is an asynchronous user experience: you send files in chats, whether your contacts are online or not, available or not. You now have a single timeline with text messages and (links to) media files. It is also compatible with archiving.</p> <h2>Further improvements</h2> <h3>MUC hibernation</h3> <p>All the old and inactive MUC rooms are now hibernated and eventually flushed out of memory, which saves a significant amount of memory on the cluster.</p> <h3>ODBC/RDBMS backend for MUC light</h3> <p>MUC light was only available on Mnesia, now it can also be stored in MySQL or PostgreSQL.</p> <h3>Simplified MAM configuration</h3> <p>Before, MAM had to be configured in many ways in multiple places. Now, it is done in one central place, and there is fewer things to configure.</p> <h3>Changelog</h3> <p>Please feel free to read the raw <a href="https://github.com/esl/MongooseIM/releases/tag/2.0.1">changelog</a>, you can even follow links and find the code changes.</p> <h2>Special thanks to our contributors!</h2> <p>Special thanks to our contributors: <a href="https://github.com/kenstir">@kenstir</a>, <a href="https://github.com/sstrigler">@sstrigler</a>, <a href="https://github.com/igors">@igors</a>, <a href="https://github.com/bernardd">@bernardd</a>, <a href="https://github.com/msantos">@msantos</a>!</p> <h2>Next?</h2> <h3>From 2.0.0 to 2.0.1: please upgrade!</h3> <p>Version 2.0.1 will probably be the last of the 2.0.x series, unless major issues are found. As this is a massive improvement, we advise everyone to upgrade.</p> <p>We are now focusing on the development of the 2.1.x series. This will deliver even more value to mobile developers and sysadmins.</p> <h3>Mobile clients: social and groups</h3> <p>We are planning to release open source iOS and Android clients. Please do not expect market killer apps. The aim is very limited: we want to provide a technology and use case demonstration.</p> <p>Mangosta iOS and Mangosta Android will deliver very basic group chat and social network. For example, these will not be distributed on mobile app stores, they will only be available as source code on our repositories.</p> <h3>Flexible push notifications</h3> <p>You can expect more improvements on the push notifications front. We have now an existing generic mod _ http _ notification, we will add push to Amazon SNS (Simple Notification Service) and <a href="http://xmpp.org/extensions/xep-0357.html">XEP-0357: Push Notifications</a>.</p> <h3>Peer to peer or mediated binary streaming</h3> <p>We will deliver an ICE/STUN/TURN server, coded in Elixir, to allow peer to peer and one to one media streaming, like voice, video, screen sharing, and whiteboarding. The signalling part, named Jingle, is already available.</p> <h2>Call for action</h2> <p>Star our repo: <a href="https://github.com/esl/MongooseIM">github.com/esl/MongooseIM</a> Follow us on Twitter: <a href="https://twitter.com/MongooseIM/">twitter.com/MongooseIM</a> &amp; <a href="https://twitter.com/ErlangSolutions/">twitter.com/ErlangSolutions</a></p>

Tigase Blog: Maven repositories URL changes

Planet Jabber - 20 February, 2017 - 23:11

For quite some time we were using the basic mean to provide access to our Maven artifacts - simply serving them as a directory view. Recently we made some changes in that area to help with the maintenance and also provide a single access point to our repositories.

This resulted in deploying Apache Archiva under new URL: http://maven-repo.tigase.org/, from where you can access both final and snapshot repositories.

Ignite Realtime Blog: Request for Comments: Mavenizing Spark

Planet Jabber - 20 February, 2017 - 10:02

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

 

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

 

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

 

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

 

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

 

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

 

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

Peter Saint-Andre: Going Deep

Planet Jabber - 19 February, 2017 - 00:00
Three months ago, in a post entitled "Below the Surface", I started a habit of posting in my weblog at least once a week. Although it's been a good run, I've cleared out my backlog of topics to write about. More importantly, I have a big project to finish (The Upland Farm, my forthcoming book on Thoreau) and another one to restart (more on that in the coming weeks), not to mention the need to focus intently on building the team at Filament and bringing our products to market. Because all of these initiatives will require a lot of deep work, my weblog will likely be fairly quiet until mid-summer. See you then....
Distribuir contenido