Agregador de noticias

Fanout Blog: Push and reliability

Planet Jabber - 2 January, 2017 - 19:12

In push architectures, one of the main challenges is delivering data reliably to receivers. There are many reasons for this:

  • Most push architectures (including those developed by our company) use the publish-subscribe messaging pattern, which is unreliable.
  • TCP’s built-in reliability is not enough to ensure delivery, as modern network sessions span multiple connections.
  • Receivers can’t tell the difference between data loss and intentional silence.
  • There is no one size fits all answer.

The last point trips up developers new to this problem space, who may wish for push systems to provide “guaranteed delivery.” If only it were that simple. Like many challenges in computer science, there isn’t a best answer, just trade-offs you are willing to accept.

Below we’ll go over the various issues and recommended practices around reliable push.

...

Peter Saint-Andre: Philosophy and Ideology

Planet Jabber - 1 January, 2017 - 00:00
I know someone who only listens to the music of Bob Dylan. Now, I respect Dylan's songwriting immensely and I play a number of his songs, but I don't think you can call someone who only listens to Bob Dylan a lover of music. That requires what jazz musicians call big ears: an appreciation for a wide variety of musical styles, composers, and performers....

Ignite Realtime Blog: Openfire 4.1.1 Release

Planet Jabber - 31 December, 2016 - 19:17

The Ignite Realtime Community is pleased to announce the release of Openfire 4.1.1.  This release contains a few database related bugfixes that only impacted those who upgraded to 4.1.0 and particularly those using MySQL or SQL Server databases.

 

OSsha1sumFilenameLinux RPM (+32bit JRE)1a71272fbc29fb1239170f878ad803f3136082e1openfire-4.1.1-1.i686.rpmLinux RPM (No JRE)d56d83eaeca9c1cfe750e9fdbf1b1b0ef9cda74fopenfire-4.1.1-1.noarch.rpmLinux RPM (+64bit JRE)d17abe02887e991a442d2906e67dbf821ec82fdfopenfire-4.1.1-1.x86_64.rpmLinux Debianab16f19cbf56fdf592c3cb367e867079c7bbf9b4openfire_4.1.1_all.debMac DMGc5d09b44e4bba74e04b0029799f4b6e6f1b190fdopenfire_4_1_1.dmgWindows EXE762bbb2d2aa38ecb00c9b50841a9055d52ebd9deopenfire_4_1_1.exeBinary (tar.gz)36157c519b323007acd2067739e27fe242b58465openfire_4_1_1.tar.gzBinary (zip)ae67a8763b0a4c7bf64b97becd22f07ee5233369openfire_4_1_1.zipSource (tar.gz)01b060137c44e215acfcb30f77dae159cc4b5a06openfire_src_4_1_1.tar.gzSource (zip)28cb1739d0c2bdc1aacfc8d7639a7a9ee38532d9openfire_src_4_1_1.zip

 

You can download it from here:

Ignite Realtime: Downloads

As a reminder, Openfire's source code and development can be found on Github and an active developer discussion occurs within our open_chat@conference.igniterealtime.org groupchat.  Please consider helping out with Openfire's development!

 

As always, please report issues in the Community Forums and thanks for your interest in Openfire.

Peter Saint-Andre: Philosophy and Ideology

Planet Jabber - 31 December, 2016 - 00:00
While doing research for my forthcoming book on Henry David Thoreau, I've been exploring the philosophies of ancient India (Thoreau was a great admirer of the Bhagavat-Gita, the Rig-Veda, and the Laws of Manu). In so doing, I recently came across the Samkhya school of thought, which is an atheistic strand of Hinduism closely related to Yoga philosophy (apparently the Yoga Sutras of Patañjali grew out of the Samkhya tradition). Interestingly, Samkhya is more nontheistic than anti-theistic: in essence it treats god or gods as irrelevant to life and ethics. This approach is in line with my attitude; although I have been a non-believer since the age of nine (as described in my very first journal post from 1989), I am not militantly anti-theist and the underlying theme of my lifelong philosophy project is how to be good without god....

Peter Saint-Andre: The Irrelevance of God

Planet Jabber - 30 December, 2016 - 00:00
For students of American culture, one of the most fascinating books of the year was Hillbilly Elegy by J.D. Vance. The author's descriptions of his troubled upbringing in the rural hills of Kentucky and a fading industrial town in Ohio have spurred casual observers to note that these are just the kinds of places that switched political allegiances in 2016. Yet cries of "Trump!" uncover only a minuscule percentage of the story. To truly understand what's going on here requires a long-term historical perspective....

Peter Saint-Andre: The Borderer's Lament

Planet Jabber - 28 December, 2016 - 00:00
When I quit Twitter back in early November, I promised to post a journal entry every Friday night. Although I've kept that up for eight weeks, there's a slight problem: I have too much to say! Already I have quite the backlog of entries to write, and there are times when something topical cries out for a post on a day other than Friday. Case in point: today the RFC Editor published my latest RFC, on SIP-XMPP interoperability with respect to presence functionality. Here's the backstory....

Ralph Meijer: Changes

Planet Jabber - 23 December, 2016 - 13:28

For me, Christmas and Jabber/XMPP go together. I started being involved with the Jabber community around the end of 2000. One of the first things that I built was a bot that recorded the availability presence of my online friends, and show this on a Christmas tree. Every light in the tree represents one contact, and if the user is offline, the light is darkened.As we are nearing Christmas, I put the tree up on the frontpage again, as many years before.

Over the years, the tooltips gained insight in User Moods and Tunes, first over regular Publish-Subscribe, later enhanced with the Personal Eventing Protocol. A few years later, Jingle was born, and in 2009, stpeter wrote a great specification that solidifies the relationship between Christmas and Jabber/XMPP.

Many things have changed in those 16 years. I've changed jobs quite a few times, most recently switching from the Mailgun team at Rackspace, to an exciting new job at VimpelCom as Chat Expert last April, working on Veon (more on that later). The instant messaging landscape has changed quite a bit, too. While we, unfortunately, still have a lot of different incompatible systems, a lot of progress has been made as well.

XMPP's story is long from over, and as such I am happy and honored to serve as Chair of the XMPP Standards Foundation since last month. As every year, my current focus is making another success of the XMPP Summit and our presence with the Realtime Lounge and Devroom at FOSDEM in Brussels in February. This is always the highlight of the year, with many XMPP enthousiasts, as well as our friends of the wider Realtime Communications, showing and discussing everything they are working on, ranging from protocol discussions to WebRTC and IoT applications.

Like last year, one of the topics that really excite me is the specification known as Mediated Information eXchange (MIX). MIX takes the good parts of the Multi User Chat (MUC) protocol, that has been the basis of group chat in XMPP for quite a while, redesigned on top of XMPP Publish-Subscribe. Modern commercial messaging systems, for business use (e.g. Slack and HipChat), as well as for general use (e.g. WhatsApp, WeChat, Google's offerings), have tried various approaches on the ancient model of multi-part text exchange, adding multi-media and other information sources, e.g. using integrations, bots, and cards.

MIX is the community's attempt to provide a building block that goes beyond the tradional approach of a single stream of information (presence and messages) to a collection of orthogonal information streams in the same context. A room participant can select (manually or automatically by the user agent) which information streams are of interest at that time. E.g. for mobile use or with many participants, exchanging the presence information of all participants can be unneeded or even expensive (in terms of bandwidth or battery use). In MIX, presence is available as a separate stream of information that can be disabled.

Another example is Slack's integrations. You can add streams of information (Tweets, continuous integration build results, or pull requests) to any channel. However, all participants have no choice to receive the resulting messages, intermixed with discussion. The client's notification system doesn't make any distinction between the two, so you either suffer getting alerts for every build, or mute the channel and possibly miss interesting discussion. The way around it is to have separate channels for notifications and discussion, possibly muting the former.

Using MIX, however, a client can be smarter about this. It can offer the user different ways to consume these information streams. E.g. notifications on your builds could be in a side bar. Tweets can be disabled, or modeled as a ticker. And it can be different depending on which of the (concurrent) clients you are connected with. E.g. the desktop or browser-based client has more screen real-estate to show such orthogonal information streams at the same time, a mobile client might still show the discussion and notifications interleaved.

All-in-all MIX allows for much richer, multi-modal, and more scalable interactions. Some of the other improvements over MUC include persistent participation in channels (much like IRC bouncers, but integrated), better defined multi-device use (including individual addressing), reconnection, and message archiving. I expect the discussions at the XMPP Summit to tie the loose ends as a prelude to initial implementations.

I am sure that FOSDEM and the XMPP Summit will have many more exciting topics, so I hope to see you there. Until then, Jabber on!

ProcessOne: ejabberd 16.12

Planet Jabber - 23 December, 2016 - 09:41

2016 was year of several major code refactors and improvements for ejabberd. From Elixir support, to test suite and code clean up and modernization.

After ejabberd 16.09 which brings a lot of improvements, ejabberd 16.12 includes a big refactor we have been preparing for long time, and a couple of new features that pursue the central effort on API, commands and web integration started early this year.

ejabberd 16.12 includes: a new API permissions framework for commands, a new more reliable BOSH module, major code refactor, more integration and unit tests, improved support for Erlang/OTP R19, compatibility with rebar3 build system, many fixes and optimizations, and Docker containers.

Thank you to all users who have send back their feedback on ejabberd 16.12 beta version. This is helping a lot make ejabberd better.

We hope you will enjoy this new release and we wish you a merry Christmas ! Stay tuned for even more new features in 2017 !

New BOSH module

This new BOSH implementation improves BOSH users experience, as it’s more robust and efficient and overall over lower latency.

New API permissions framework

This new framework is one of the big changes in this release. It makes our API very flexible, allowing administrators to fine grain access to some users to a group of API, depending on the path used to call a given command.

While it should make it possible to implement any kind of access control on top of ejabberd management API, it also makes it much easier to configure ejabberd API for simple needs.

ejabberd API operations are organised around the concept of commands. ejabberd modules provide many commands, but the mechanism is generic and any module can provide its own set of commands.

All commands can be exposed through interfaces. Available interfaces are: ejabberdctl command-line tool, ejabberd ReST API and ejabberd XML-RPC API. The XML-RPC API still works but is deprecated in favor of the ReST API. You should migrate to ReST if you are using it.

Finally, ReST API can be accessed through two authentication mechanisms: HTTP Basic Authentication and OAuth 2.

Each command interface can have different restrictions based on how exposed and sensitive the commands are.

Note that the following configuration snippets assume ejabberd API listeners are properly configured, as defined in API listener configuration

By default, when no api_permission option is provided, ejabberd would use the following default permissions:

api_permissions: "console commands": - from: - ejabberd_ctl - who: all - what: "*" "admin access": - who: - admin - oauth: - scope: "ejabberd:admin" - admin - what: - "*" - "!stop" - "!start"

This will grant access to all commands when ejabberdctl is used (this is what “console commands” group does), and additionally each command that is authenticated by user that match acl auth from any source will be able to call all commands except start and stop.

It’s possible to extend this by adding new section like this:

api_permissions: ... "allow statbot to get server stats" - who: - user: "statbot@server.example.com" - what: - connected_users_number - num_active_users

This will allow user statbot to execute commands connected_users_number and num_active_users.

You can even relax the need to authenticate on ReST API, for example, if you only want to restrict the API to localhost usage, for admin tasks:

api_permissions: "local admin can use all commands" - who: - ip: "127.0.0.1/8" - what: - "*" - "!stop" - "!start"

As you can see, for simple cases, the API permission management is now very simple. Yet, the system is powerful and can accommodate your most advanced needs.

For more details, see full api permission documentation.

You can now rely on ejabberd hundreds of commands to integrate in a precise and secure way with your back ends.

Major code refactor

Finally, the most important change (in terms of line of code and impact on ejabberd code base) is refactor of XMPP packet handling in the entire code base. This improvement makes code simpler, safer, and smaller. ejabberd now uses a dedicated XMPP library, which helps developers packing/unpacking XMPP packets.

Example is always better than words:

Don’t build entire XML element, but rely on common “templates”

Before:

#xmlel{name = <<"identity">>, attrs = [{<<"category">>, <<"pubsub">>}, {<<"type">>, <<"pep">>}]} IQ#iq{type = error, sub_el = [Error, SubEl]}

After:

#identity{category = <<"pubsub">>, type = <<"pep">>} xmpp:make_iq_result(IQ, Error); Match packets efficiently

Before:

normal_state({route, From, <<"">>, #xmlel{name = <<"message">>, attrs = Attrs, children = Els} = Packet}, StateData) -> case is_user_online(From, StateData) of true -> case fxml:get_attr_s(<<"type">>, Attrs) of <<"groupchat">> -> ...

After:

normal_state({route, From, <<"">>, #message{type = Type, lang = Lang} = Packet}, StateData) -> case is_user_online(From, StateData) of true when Type == groupchat -> ... Don’t use macros to build error response

Before:

jlib:make_error_reply(Packet, ?ERRT_BAD_REQUEST(Lang, Txt));

After:

xmpp:make_error(Packet, xmpp:err_bad_request(Txt, Lang));

The code is safer, as all XMPP processing in the core of ejabberd can be typed-checked through static analyzer like Dialyzer.

Overall, this change paves the way to improvements of ejabberd API and will make it much more pleasant for contributors to write new modules and extensions. Improving the contribution documentation is next on our list and you are welcome to join the effort.

This big refactor impacts the entire code base. Now that all tests are successful, we provide an early beta before the final 16.12 release. 16.12-beta1 is not yet intended for production use. We are waiting for your feedback to check that special cases did not sleep through our careful refactor. Please, test it and send us feedback in your use case, so that we can catch the tricky bugs before the final version is released.

Docker containers

Ejabberd docker container contributed by Rafael Römhild is now included in ejabberd sources.
We also provide simple containers to build and run ejabberd from sources. Thanks to this image, you can build ejabberd with dependencies provided in our Docker image, without the need to install any specific tools (beside Docker) directly on your own machine. This works on Linux, FreeBSD, MacOSX, Windows.
See more in this blogpost.

External modules

Ejabberd’s ext_mod has been updated to build external modules with the new xmpp library. You should port your contribution to make it compile and work with ejabberd 16.12. While this will improve your code, it will also offer possibility to implement post_install and pre_uninstall directly in your module. By exporting these functions, ejabberd will call them after module has been successfully installed and right before uninstalling it to allow any custom tasks at these stages.

Windows installer

The installer now moves ejabberd data files (configuration, database and logs) in %ProgramData% instead of %APPDATA%. This move fixes running ejabberd as a service. As a result, installer now registers ejabberd service by default. If you’re upgrading ejabberd from an older version, the installer will automatically move your configuration from %APPDATA% to %ProgramData% to keep your existing data without any manual operation.

Changes

This is just a summary of the most relevant ones:

API / integration
  • New API permissions framework
Commands
  • Add configurable weight for ejabberd commands
  • add_rosteritem: Support several groups separated by ;
  • create_rooms_file: Fix reading room jids from file
  • delete_old_messages: Fix command for SQL backends
  • send_message: Don’t duplicate the message
  • Remove obsolete remove_node command (use leave_cluster)
  • Fix reload_config
  • Cleanup mod_admin_extra, add few functions
  • Expose unregister API command
Core XMPP
  • New BOSH module
  • Use fxml_gen XML generator
  • Use our new stand-alone XMPP library instead of jlib.erl
  • Don’t let MAM messages go into offline storage
  • Add xdata generator for XMPP data form
  • Get rid of excessive (io)list_to_binary/1 calls
HTTP
  • Add authentication support to mod_http_fileserver
  • ejabberd_http: Handle missing POST data gracefully
  • Use inets instead of lhttpc in http_p1
  • Add http_p1.erl, rest.erl, and oauth2 ReST backend for OAuth2 tokens
MUC
  • Create room on configuration request as per XEP-0045, 10.1.3
  • Ensure that presence_broadcast room option is stored
  • Fix conference disco#items when running multiple virtual hosts
  • Fix Result Set Management (RSM) for conference disco#items
  • Introduce muc_invite hook
  • Make the constant MAX_ROOMS_DISCOITEMS configurable
  • mod_carboncopy: Don’t copy MUC private messages
MUC/Sub
  • Store the flag “Allow Subscription” room option in database
  • When getting list of subscribed rooms, also check temporary ones
  • Add password support in muc_subscribe
  • When unsubscribes, check if room should get closed
Pubsub
  • Enforce pubsub node removal
Relational databases support
  • Append ; to privacy_list_data exporting lines
  • Improve relational database import
Build
  • Make build system compatible with rebar3
  • Produce ejabberd.service and fix for systemd usage
  • Cleanup ext_mod and fix compilation path
  • Fix compilation of external module with new xmpp lib
  • Add optional post_install and pre_uninstall hooks for external module
Miscelanea
  • Add docker container from Rafael Römhild
  • fast_tls is now compatible with LibreSSL
  • Delete obsolete module mod_configure2
  • Rename #error{} record to #stanza_error{}
  • Bugfix: Ignore offline sessions in ejabberd command statistics
  • Bugfix: Don’t let MAM messages go into offline storage
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.

Peter Saint-Andre: RFC 8048: SIP-XMPP Presence Revisited

Planet Jabber - 23 December, 2016 - 00:00
Just about thirteen years ago I posted a list of "desert island dics" that I couldn't do without (yes, this was back before streaming music services took off, so forgive the anachronism - though I still prefer to own and listen to physical albums). Looking at that list again recently reminds me that I've been meaning to post about some other recent musical finds....

Ignite Realtime Blog: Openfire 4.1.0 Final Release

Planet Jabber - 21 December, 2016 - 15:20

Christmas has come early.

 

Our github repository - GitHub - igniterealtime/Openfire: A XMPP server licensed under the Open Source Apache License. - reached a thousand and one stars today, so we've celebrated by releasing Openfire 4.1.0, containing over 150 fixes and new features. I feel I should personally thank Daryl Herzmann and Guus der Kinderen in particular for the gargantuan effort they've both put into this release, but we're also very lucky to have a large number of developers within the community providing us with high-quality patches via Pull Requests. This is, once again, a huge collective effort.

 

Changlog: Openfire Changelog

 

 

Platform
sha1sumFilenameMac

3e245dc7cd67707847bba605ec4942a81438066d

openfire_4_1_0.dmgWindowsd590ebf8e3ca429b1d738833e14419c3dd514110openfire_4_1_0.exeBinary (tar.gz)

074021df4cc60af0f18879421c3b9e11316dad91

openfire_4_1_0.tar.gzBinary (zip)

2e933881c80d9ded13027679e6a0465f20d812eb

openfire_4_1_0.zipSource (tar.gz)cf458223b8acf23c84219f343d5d14bebfe9a963openfire_src_4_1_0.tar.gzSource (zip)a4a637354be17031be64f7cff9443584dde4022dopenfire_src_4_1_0.zipRPM Installer (32-bit JRE)

8ed5af7cbd41b48c866dc756cd8d927c34b39400

openfire-4.1.0-1.i686.rpmRPM Installer (64-bit JRE)

ec257c300732d00d323f44f02a6d97d4030068fa

openfire-4.1.0-1.x86-64.rpmRPM Installer (No JRE)

88d8bb61f2437d0ad1612d6f6464bf5dacd2425d

openfire-4.1.0-1.noarch.rpmDEB Installer9ea6b83a7aa9229be0358385e02985a9df04418eopenfire_4.1.0_all.deb

 

You can download it from here:

 

Ignite Realtime: Downloads

 

As a reminder, Openfire's source code and development can be found on Github and an active developer discussion occurs within our open_chat@conference.igniterealtime.org groupchat.  Please consider helping out with Openfire's development!  We can use help in about all areas of development, but especially:

  • experienced packaging developers to improve the install/upgrade experience on various platforms
  • developers interested in transitioning Openfire to Maven
  • testing of Bamboo generated builds

 

Thank you for your interest in Openfire!

ProcessOne: ejabberd 16.12 beta1

Planet Jabber - 15 December, 2016 - 14:57

In 2016, we made several major code refactors and improvements on ejabberd. From Elixir support, to test suite and code clean up and modernization.

After 16.09 which brings a lot of improvements, the last version for 2016 includes a big refactor we have been preparing for long time, and a couple of new features that pursue the central effort on API, commands and web integration started early this year.

ejabberd 16.12 includes: a new API permissions framework for commands, a new more reliable BOSH module, major code refactor, more integration and unit tests, improved support for Erlang/OTP R19, compatibility with rebar3 build system and many fixes and optimizations.

New BOSH module

This new BOSH implementation improves BOSH users experience, as it’s more robust and efficient and overall over lower latency.

New API permissions framework

This new framework is one of the big changes in this release. It makes our API very flexible, allowing administrators to fine grain access to some users to a group of API, depending on the path used to call a given command.

While it should make it possible to implement any kind of access control on top of ejabberd management API, it also makes it much easier to configure ejabberd API for simple needs.

ejabberd API operations are organised around the concept of commands. ejabberd modules provide many commands, but the mechanism is generic and any module can provide its own set of commands.

All commands can be exposed through interfaces. Available interfaces are: ejabberdctl command-line tool, ejabberd ReST API and ejabberd XML-RPC API. The XML-RPC API still works but is deprecated in favor of the ReST API. You should migrate to ReST if you are using it.

Finally, ReST API can be accessed through two authentication mechanisms: HTTP Basic Authentication and OAuth 2.

Each command interface can have different restrictions based on how exposed and sensitive the commands are.

Note that the following configuration snippets assume ejabberd API listeners are properly configured, as defined in API listener configuration

By default, when no api_permission option is provided, ejabberd would use the following default permissions:

api_permissions: "console commands": - from: - ejabberd_ctl - who: all - what: "*" "admin access": - who: - admin - oauth: - scope: "ejabberd:admin" - admin - what: - "*" - "!stop" - "!start"

This will grant access to all commands when ejabberdctl is used (this is what “console commands” group does), and additionally each command that is authenticated by user that match acl auth from any source will be able to call all commands except start and stop.

It’s possible to extend this by adding new section like this:

api_permissions: ... "allow statbot to get server stats" - who: - user: "statbot@server.example.com" - what: - connected_users_number - num_active_users

This will allow user statbot to execute commands connected_users_number and num_active_users.

You can even relax the need to authenticate on ReST API, for example, if you only want to restrict the API to localhost usage, for admin tasks:

api_permissions: "local admin can use all commands" - who: - ip: "127.0.0.1/8" - what: - "*" - "!stop" - "!start"

As you can see, for simple cases, the API permission management is now very simple. Yet, the system is powerful and can accommodate your most advanced needs.

For more details, see full api permission documentation.

You can now rely on ejabberd hundreds of commands to integrate in a precise and secure way with your back ends.

Major code refactor

Finally, the most important change (in terms of line of code and impact on ejabberd code base) is refactor of XMPP packet handling in the entire code base. This improvement makes code simpler, safer, and smaller. ejabberd now uses a dedicated XMPP library, which helps developers packing/unpacking XMPP packets.

Example is always better than words:

Don’t build entire XML element, but rely on common “templates”

Before:

#xmlel{name = <<"identity">>, attrs = [{<<"category">>, <<"pubsub">>}, {<<"type">>, <<"pep">>}]} IQ#iq{type = error, sub_el = [Error, SubEl]}

After:

#identity{category = <<"pubsub">>, type = <<"pep">>} xmpp:make_iq_result(IQ, Error); Match packets efficiently

Before:

normal_state({route, From, <<"">>, #xmlel{name = <<"message">>, attrs = Attrs, children = Els} = Packet}, StateData) -> case is_user_online(From, StateData) of true -> case fxml:get_attr_s(<<"type">>, Attrs) of <<"groupchat">> -> ...

After:

normal_state({route, From, <<"">>, #message{type = Type, lang = Lang} = Packet}, StateData) -> case is_user_online(From, StateData) of true when Type == groupchat -> ... Don’t use macros to build error response

Before:

jlib:make_error_reply(Packet, ?ERRT_BAD_REQUEST(Lang, Txt));

After:

xmpp:make_error(Packet, xmpp:err_bad_request(Txt, Lang));

The code is safer, as all XMPP processing in the core of ejabberd can be typed-checked through static analyzer like Dialyzer.

Overall, this change paves the way to improvements of ejabberd API and will make it much more pleasant for contributors to write new modules and extensions. Improving the contribution documentation is next on our list and you are welcome to join the effort.

This big refactor impacts the entire code base. Now that all tests are successful, we provide an early beta before the final 16.12 release. 16.12-beta1 is not yet intended for production use. We are waiting for your feedback to check that special cases did not sleep through our careful refactor. Please, test it and send us feedback in your use case, so that we can catch the tricky bugs before the final version is released.

Changes

This is just a summary of the most relevant ones:

API / integration
  • New API permissions framework
Commands
  • Add configurable weight for ejabberd commands
  • add_rosteritem: Support several groups separated by ;
  • create_rooms_file: Fix reading room jids from file
  • delete_old_messages: Fix command for SQL backends
  • send_message: Don’t duplicate the message
Core XMPP
  • New BOSH module
  • Use fxml_gen XML generator
  • Use our new stand-alone XMPP library instead of jlib.erl
  • Don’t let MAM messages go into offline storage
  • Add xdata generator for XMPP data form
  • Get rid of excessive (io)list_to_binary/1 calls
HTTP
  • Add authentication support to mod_http_fileserver
  • ejabberd_http: Handle missing POST data gracefully
  • Use inets instead of lhttpc in http_p1
  • Add http_p1.erl, rest.erl, and oauth2 ReST backend for OAuth2 tokens
MUC
  • Create room on configuration request as per XEP-0045, 10.1.3
  • Ensure that presence_broadcast room option is stored
  • Fix conference disco#items when running multiple virtual hosts
  • Fix Result Set Management (RSM) for conference disco#items
  • Introduce muc_invite hook
  • Make the constant MAX_ROOMS_DISCOITEMS configurable
  • mod_carboncopy: Don’t copy MUC private messages
MUC/Sub
  • Store the flag “Allow Subscription” room option in database
  • When getting list of subscribed rooms, also check temporary ones
Relational databases support
  • Append ; to privacy_list_data exporting lines
  • Improve relational database import
Build
  • Make build system compatible with rebar3
  • Produce ejabberd.service and fix for systemd usage
Miscelanea
  • Bugfix: Don’t let MAM messages go into offline storage
  • Delete obsolete module mod_configure2
  • Bugfix: Ignore offline sessions in ejabberd command statistics
  • Rename #error{} record to #stanza_error{}
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.

Ignite Realtime Blog: Openfire 4.1.0 Beta

Planet Jabber - 14 December, 2016 - 18:52

A Year and a Day - TV Tropes

 

On the 13th of December, 2015, we released Openfire 4.0.0 Beta.

 

Now, a year later, we have a new Beta to try. This one has numerous major security fixes and enhancements, and a huge long Openfire Changelog to read through.

 

Platform
sha1sumFilenameMac

0a8ac2adbec60f411ff959a967d9635173da0ef2

openfire_4_1_0_beta.dmgWindows1834ff1278e0249f4fe8662536683aabd6b839c5openfire_4_1_0_beta.exeBinary (tar.gz)

73e43670a6ceb3bd987f9d0176eb6a8346b2a581

openfire_4_1_0_beta.tar.gzBinary (zip)

a84e156284bf1d51f8f1cee24e977846b350944f

openfire_4_1_0_beta.zipSource (tar.gz)625e92e1dd76c99ebde70b3ae7de6a651f08d4d5openfire_src_4_1_0_beta.tar.gzSource (zip)9d9fe67f5e62f3d31d2ab6d6a4ebf282a1e01254openfire_src_4_1_0_beta.zipRPM Installer (32-bit JRE)

a3fb24fd3c33fb3f92ab53b8665d028b68c11e32

openfire-4.1.0-0.2.beta.i686.rpmRPM Installer (64-bit JRE)

e055fd8eae9cf5f418fcfda7da93b8c3cd6a38bc

openfire-4.1.0-0.2.beta.x86-64.rpmRPM Installer (No JRE)

71855a71dfe1ab4ad9aa472bd1ebb0b7a702bf04

openfire-4.1.0-0.2.beta.noarch.rpmDEB Installer9cce98aadd53cb3995b355fd54543459ab80e056openfire_4.1.0.beta_all.deb

 

Please do try this, but not in production of course. Unless you're a mad and crazy bunch, like we are. You can download it from here:

 

Ignite Realtime: Beta Downloads

 

As a reminder, Openfire's source code and development can be found on Github and an active developer discussion occurs within our open_chat@conference.igniterealtime.org groupchat.  Please consider helping out with Openfire's development!  We can use help in about all areas of development, but especially:

  • experienced packaging developers to improve the install/upgrade experience on various platforms
  • developers interested in transitioning Openfire to Maven
  • testing of Bamboo generated builds

 

Thank you for your interest in Openfire!

ProcessOne: Build awesome Internet of Things with ProcessOne

Planet Jabber - 13 December, 2016 - 12:33

You probably don’t know this, but ProcessOne has been delivering enterprise-grade solutions for device communication since before it was called the Internet of Things. IoT market is growing at a rapid pace, and by 2018 there will be more internet-connected devices than PCs, smartphones and tablets combined!

But back in 2008, we already implemented production-ready infrastructure for IoT. Based on XMPP, of course, it powered the community of Nabaztags – ambient electronic devices in the shape of a rabbit that could communicate with text and voice messages, play music and internet radio, as well as speak various news: weather, stocks, rss, email etc. Its community continued to be very live and open, and keeps supporting the rabbits through private servers.

After the Nabaztag project we were approached by Kodak to create an IoT infrastructure for digital, connected photo frames. Through 2010 we developed XMPP-based connection backend for several series of Kodak digital frames.

Another notable example of our long-term commitment to the Internet of Things is the now decade-long cooperation with IMA Téléassistance, a major European player in security and monitoring of individual and commercial property. With the growing popularity of Smart Home solutions, IMA Téléassistance recently entered this market with additional connected products like electricity plugs, light and motion sensors or smoke detectors. With our proven IoT backend, they had the confidence to expand their device pool.

At ProcessOne, we believe connected devices will power the big change in enterprise and infrastructure operations. It is our opinion that your business will need IoT infrastructure to cut costs, empower employees and optimize processes. And we are here to help you do that – See more and contact us today! »

Peter Saint-Andre: Musical Finds

Planet Jabber - 13 December, 2016 - 00:00
Although I don't live or eat in a consistently paleo fashion, I do like some paleo foods. One of my favorites is grain-free granola. It also happens to be very simple to make. Here's how....

Peter Saint-Andre: Grain-Free Granola Recipe

Planet Jabber - 9 December, 2016 - 00:00
In Walden, Thoreau wrote:...

ProcessOne: ejabberd Development with Docker

Planet Jabber - 5 December, 2016 - 11:31

We have released a Docker image to help you get started with ejabberd development easily.

Docker image for ejabberd developers is available from Docker Hub: ejabberd/mix

Thanks to this image, you can build ejabberd with dependencies provided in our Docker image, without the need to install any specific tools (beside Docker) directly on your own machine.

Please note that this image can likely be reused as is to build other Erlang or Elixir software.

Pulling ejabberd development Docker image

You can pull ejabberd image for developer with this Docker command:

docker pull ejabberd/mix

Once done, you are ready to build ejabberd from source and add your custom plugin modules.

Building ejabberd from source

You can build ejabberd from source with all dependencies, with the following commands:

git clone https://github.com/processone/ejabberd.git docker run --rm -v $(pwd):$(pwd) -w $(pwd) ejabberd/mix do deps.get, deps.compile, compile

Alternatively if you do not have Git installed, you can do retrieve compressed source code archive and then build ejabberd:

wget https://github.com/processone/ejabberd/archive/master.zip unzip ejabberd-master cd ejabberd-master docker run --rm -v $(pwd):$(pwd) -w $(pwd) ejabberd/mix do deps.get, deps.compile, compile Run ejabberd with mix command-line tool attached

During development, you will need to run ejabberd with debug console attached.

First, you can customize the configuration used by ejabberd in development mode by editing the file config/ejabberd.yml. As a default, it will run ejabberd with console attached on domain “localhost”:

docker run --rm -it -p 5222:5222 -p 5280:5280 -v $(pwd):$(pwd) -w $(pwd) --entrypoint="/usr/bin/iex" ejabberd/mix -S mix

You can then directly create a user from Elixir shell:


Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:2:2] [async-threads:10] [kernel-poll:false] Interactive Elixir (1.3.4) - press Ctrl+C to exit (type h() ENTER for help) iex(1)> :ejabberd_auth.try_register("test", "localhost", "passw0rd") {:atomic, :ok}

Finally, you can connect with user “test@localhost” (password: passw0rd) on server on localhost port 5222 and use those parameters to connect with an XMPP client.

Get into the container

If you want to run Erlang command line, you can do so by opening a shell inside the container and then running the command as desired:

docker run -it -v $(pwd):$(pwd) -w $(pwd) --entrypoint="/bin/sh" ejabberd/mix Troubleshooting Clock resync

If you have warning about file timestamp being out of sync (Like ‘Clock skew detected’), you may want to force resync your clock before running the build. Docker on MacOS does not force clock resync of Docker after the laptop went to sleep.

You can force clock resync as follow:

docker run -it --rm --privileged --entrypoint="/sbin/hwclock" ejabberd/mix -s

You can check if the clock of your laptop is in sync with the one inside Docker with the following command:

docker run --rm --entrypoint="/bin/sh" ejabberd/mix -c date -u && date -u Send us feedback

This image is under development and improvement, so please do not hesitate to send us your feedback, so that we can improve ejabberd development experience.

The goal is to provide a simple easy way to develop ejabberd plugins from any OS, whether you use Linux, MacOS or Windows.

Enjoy !

Peter Saint-Andre: Philosophy as a Way of Life

Planet Jabber - 2 December, 2016 - 00:00
Most people have no idea how the web works and don't understand the role they play in the web ecosystem. Partly this is because our mental model of the web dates back to the early days of "Web 1.0", when folks used the web to read physics papers and personal weblogs and such, somewhat as they would visit their local public library and read books and magazines and newspapers sitting on the shelves. My, how times have changed!...

Ignite Realtime Blog: Openfire 4.0.4 is Released

Planet Jabber - 1 December, 2016 - 14:53

The Ignite Realtime Community is pleased to announce the 4.0.4 release of Openfire.  Openfire is a cross-platform real-time collaboration server based on the XMPP (Jabber) protocol. This release signifies our ongoing effort to produce a stable 4.0 series release while continuing to work toward a 4.1 release. A changelog of fixes is available and indicates 16 issues resolved.

 

As always, please report issues in the Community Forums and you can download this release from our website.  Here are the sha1sum's for the downloads available.

 

 

Platform
sha1sumFilenameMac

1d95db39719843ec731ddc69ffb622212b85feb9

openfire_4_0_4.dmgWindows3d342c6f45abb9fc6aff990cf25d879ee20470edopenfire_4_0_4.exeBinary (tar.gz)

5b395f2aedfa55e989730ee960a8c6cb7624bd0e

openfire_4_0_4.tar.gzBinary (zip)

dfb2860197e50858728e2532cd8f21d8f61a6658

openfire_4_0_4.zipSource (tar.gz)e947ffdf4746d3d0a7efb7cf25d198c05668ab54openfire_src_4_0_4.tar.gzSource (zip)fbd8e4c143b7c4841fcb231db2c5974d90137b4fopenfire_src_4_0_4RPM Installer

94d5e0f21f7cbef8d5986e29e3f2f2fc3bec7796

openfire-4.0.4-1.i386.rpmDEB Installerb16d334a90c86e7b15e9ec44162ec01ca700434dopenfire_4.0.4_all.deb

 

As a reminder, Openfire's source code and development can be found on Github and an active developer discussion occurs within our open_chat@conference.igniterealtime.org groupchat.  Please consider helping out with Openfire's development!  We can use help in about all areas of development, but especially:

  • experienced packaging developers to improve the install/upgrade experience on various platforms
  • developers interested in transitioning Openfire to Maven
  • testing of bamboo generated builds

 

Thank you for your interest in Openfire!

Ignite Realtime Blog: Spark 2.8.2 Released

Planet Jabber - 25 November, 2016 - 19:00

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

 

This is a regular update. But there is a change, which can affect new users. "Accept all certificates" option on the Adanced menu on the Login screen won't be enabled by default for new users from now on. This option makes Spark automatically accept expired, self-signed and other incorrect TLS certificates. Which makes it less secure. If you are using self-signed certificates, your new users will have to enable this option manually (once). Or you can add this option to a preconfigured spark.properties file, if you distribute it to new users. Old users won't be affected by this (those upgrading straight from 2.7 version will still be affected). We encourage server admins to use certificates from trusted authorities (e.g. Let's Encrypt). This version also includes 4.1.9 update for Smack, which has a fix for a critical security vulnerability.

 

UPDATE (2016/11/29): it looks like Spark is not saving settings on Advanced menu, if a user has never opened it. For such users "Accept all certificates" setting will be disabled after updating to 2.8.2 from any version. They will have to go to Advanced menu and enable it, if they encounter "Unable to verify a certificate" error.

 

Those who are using Client Control plugin will have to update it to version 2.1.0 as Spark 2.8.2 is already modified to work with that version and it will miss many menus and checkboxes if being used with an older version of that plugin. 2.1.0 version requires Openfire 4.0.0 at least. If you are using older version of Openfire and want to keep using Client Control, you might want to hold of updating to Spark 2.8.2.

 

We also would like to mention SparkMeet plugin provided by our long time contributor Dele Olajide. Hopefully we will find a way to bundle this plugin with Spark or provide other options to use it. You can also vote here and tell what you think about it. Initial commit is done and its in Spark's source code sparkmeet plugin - initial release by deleolajide · Pull Request #253 · igniterealtime/Spark · GitHub.

 

For a complete list of changes please check Spark Changelog

 

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

 

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

freeseawind · GitHub  contributed new skin for Spark - LittleLuck

Alexander198961 (Aleksander Kovtunenko) · GitHub  fixed the issue with Spark freezing on exit because of a faulty plugin

Michael  added more settings to default.properties and Client Control plugin, fixed showing of an empty Unfiled group and a few other issues

Martini26  updated Polish translation

speedy  fixed an issue with systray icon switching to regular one when it should be DND or Away and a few issues with invisible mode

nicoben (Nico Ben) · GitHub  updated Italian translation

 

Here are sha1 checksums for the downloads:

7a45319a723368b6c830a1c1a7287fb207140b4f spark_2_8_2.dmg

dd9c533868d42fc0ef651d544f463ff1fba5d21c  spark_2_8_2.exe

fb324011e7f1a61b5e793b2c6b1778306bf19102  spark_2_8_2_online.exe

20dbc5940a450ab3176f1dcf4d4dfd01f90b4b06  spark_2_8_2.tar.gz

813e110f6715f7f72af28e2ee90ed2bd9fa11005  spark-2.8.2.rpm

1409189a0877a203ef3fe16410a520056fe214d7  spark-2.8.2.src.rpm

565ff2947b4cca69f73f6818f18d49571db6bf78  spark_2.8.2.deb

Peter Saint-Andre: I'm Just a Thing on the Internet

Planet Jabber - 25 November, 2016 - 00:00
The other day I finished reading Nicholas Carr's book The Glass Cage: Automation and Us. Carr's argument about automation, and technology more generally, is that it is not an unmitigated good. If technology is not made to serve human ends, then humans will end up serving technology. We can see this clearly with social networking services. As the saying goes, if you're not paying then you're the product. Yet it goes much deeper than that. Tools such as the ubiquitous "like" button give you the pleasant feeling that you are interacting with your 500 friends on Facebook or Twitter or Instagram, but that feeling is illusory. Aristotle observed over 2300 years ago that true friendship requires spending time together; yet when clicking buttons on a website you are merely engaged in the simulacra of friendship, not the real thing. (I gather that Jacob Silverman makes this point quite forcefully in his book Terms of Service, which I have not yet read.)...
Distribuir contenido