Planet Jabber

August 07, 2022

Dino

Stateless File Sharing: Base implementation

The last few weeks were quite busy for me, but there was also a lot of progress. I’m happy to say that the base of stateless file sharing is implemented and working. Let’s explore some of the more interesting topics.

File Hashes

File hashes have some practical applications, such as file validation and duplication detection. As such, they are part of the metadata element that stateless file sharing introduces. The hash values are stored as the base64 encoded raw byte representation of the hashes result. Multiple hashes can be added, and it is not specified which algorithm should be used. Instead, XEP-0414 has a maintained list of the recommended hash algorithms.

The idea behind not specifying which algorithm should be used is to keep flexibility and to stay future-proof. However, this does make implementations more complicated because you somehow have to handle multiple hashes, and perhaps from algorithms your code is unaware of. As of now, I intend to only send the sha256 in the metadata.

File Sources

As you might recall, the big idea behind stateless file sharing is that it is not bound to a specific method for file transfer. Same as with the hashes, multiple sources can be provided. For this project, the goal is just to have HTTP file transfers working (the base of which already works) in an extendable way. This is mostly because the type of jingle (peer-to-peer) file transfer that exists in Dino is not suitable for this: Dino currently only allows users to start a file transfer as the sending party (‘push’). Suitable would be if a sender could signal an available file and have the receiver signal that they now want to receive it (‘pull’).

New file transfer method in Dino

Turns out, you need to edit multiple components of a messenger when adding something that sends and parses certain messages. Figuring out which parts of Dino’s code I will need to touch wasn’t exactly clear to me. Dino is written in Vala, which was also a new language for me.

The components I had to touch are:

  • xmpp-vala: low level XMPP code
  • libdino: Code that can be used to build a messenger UI
  • plugins: Messenger components that can be disabled

So, which parts of my code goes where?

  • xmpp-vala: Stanza definitions, serializing, parsing, methods for the stanzas
  • libdino: File management, storing data in the correct database, attaching to the correct XMPP streams
  • plugins: To have libsoup as an optional dependency, HTTP file transfer stuff is a plugin

By adding the different components, I had to both edit and add new tables to the database.

  • The FileTransfer table received more fields to accommodate the additional metadata
  • FileHashes is a new table to store the triple file_id, hash_algorithm, and hash_value
  • SfsHttpSources stores the tuple file_id, url. New columns can be added later for more complicated HTTP requests

Writing Vala and Debugging

Having not programmed in Vala before, I must say that I was very positively surprised at how little debugging I had to do. Most smaller things simply worked out of the box.

There were of course also instances where debugging wasn’t trivial. Especially database code and connecting to networking didn’t work out of the box for me. While trial-and-error with printf-debugging sometimes did the trick, sometimes I figured that outside help would cut down the time I would need drastically. For many things I contacted my mentor, Marvin who could usually point me in the right direction very quickly, which made work on the project quite pleasant.

Also helpful was of course debugging with gdb. In particular when critical warnings are already output, setting the environment variable G_DEBUG=fatal-criticals helps a lot. This will simply break on every such warning, which allows you to easily inspect what went wrong.

Next Steps

While there was a lot of progress, there are also a good amount of loose ends to tie up. The reusage of the HTTP send and receive code is a bit hacky, and some parts of the code should be written more extendable. Next up is cleaning up the code that was introduced. After that, there is still obtaining the image- and video-specific metadata and some UI work.

As always, progress can be tracked on my stateless-file-sharing branch

August 07, 2022 00:00

August 04, 2022

Ignite Realtime Blog

REST API Openfire plugin 1.9.1 released!

Woopsie doodle! It turns out that a rather annoying bug was introduced in version 1.9.0 of the REST API plugin for Openfire, that we released earlier today!

To avoid unnecessary issues, we’ve decided to follow up with an immediate new release that addresses this issue. Thus, we present: release 1.9.1 of the REST API plugin for Openfire!

The updated plugin should become available for download in your Openfire admin console in the course of the next few hours. Alternatively, you can download the plugin directly, from the plugin’s archive page.

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

by guus at August 04, 2022 17:54

REST API Openfire plugin 1.9.0 released!

We have released version 1.9.0 of the Openfire REST API plugin! This version adds functionality and provides some bug fixes that relates to multi-user chat rooms.

The updated plugin should become available for download in your Openfire admin console in the course of the next few hours. Alternatively, you can download the plugin directly, from the plugin’s archive page.

For other release announcements and news follow us on Twitter

2 posts - 1 participant

Read full topic

by guus at August 04, 2022 11:23

August 03, 2022

The XMPP Standards Foundation

The XMPP Newsletter July 2022

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of July 2022.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, especially throughout the current situation, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

Newsletter translations

This is a community effort, and we would like to thank translators for their contributions. Volunteers are welcome! Translations of the XMPP Newsletter will be released here (with some delay):

XSF Announcements

  • The XSF membership application period for the third quarter 2022 is currently open. If you are interested in becoming a XSF member then you can apply for membership. Please submit by August 25, 2022.

Google Summer of Code 2022

XSF and Google Summer of Code 2022

The Google Summer of Code 2022 has lifted off and coding started a while ago! The two new contributors Patiga and PawBud who will work on open-source software projects in the XMPP environment. Read their first blog posts, too.

XSF fiscal hosting projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective. For more information, see the announcement blog post. Current projects:

Events

Articles

There are some articles and thoughts on the European Digital Markets Act:

The site “Chat standard (XMPP)” with lots of information is available in English now at freie-messenger.de

Axel from eversten.net published an XMPP Push Notification Test for iOS covering latest Monal, Siskin IM and Snikket versions on different server implementations. A good 15 minutes read for both iOS users and their multi-platforms contacts alike.

JMP now delivers transcribed voicemail in many common languages, not just English. The voicemail system has also been updated to source names from more modern XMPP profiles including vCard4 and PEP Nickname.

MoongoseIM 5.1 was released as announced, as announced in the June 2022 Newsletter. In addition to the previously mentioned features, this brought improvements to the Inbox feature. You can now read more about the new Inbox settings and scalability improvements in this article.

Software news

Clients and applications

The Mellium Dev Communiqué for July 2022 has been published! Important updates this month include an implementation of the new RFC 9266 and a new tool for finding documentation related issues in Go projects. In addition, Mellium has moved to Codeberg! The repositories can now be found at codeberg.org/mellium and the announcement post can be found on Lemmy or Open Collective.

Conversations 2.10.8, a Jabber/XMPP client for Android, has been released.

Gajim 1.4.6 and 1.4.7 have been released. These releases bring performance improvements, better file previews, and fix some bugs with the status icon and notifications. Emoji short code detection has been improved as well.

Monal version 5.2.0 has been released by the Monal development team! This release’s highlights are the new (private) push servers in Europe and the US, display of transferred files in app’s documents directory, and several fixes regarding encryption (OMEMO), QR code scanning, and onboarding. Besides, Monal also features a new webpage.

Psi+ 11.5.1634 (2022-07-11) has been released.

Servers

eturnal 1.10.0, a STUN / TURN standalone server, has been released.

Openfire version 4.7.2 is out, stabilizing and fixing bugs, notably improving BOSH connections under load.

Push Notification Openfire plugin 0.9.1 was released with only one, but an important fix.

Version 1.8.3 of the Openfire REST API plugin is out too, extending MUC search and updating dependencies.

Libraries

libstrophe 0.12.1, a lightweight XMPP client library written in C, has been released.

nbxmpp 3.1.1 has been released. This version comes with performance improvements and bug fixes.

The XMPP webhooks component has been updated to support more webhooks out of the box. Effectively, this component replaces proprietary tools such as Slack with a better option based on open code and open protocols, fully under control of its users. It now has:

  • Richer messages for GitLab events (labels, time spent, etc.)
  • Support for Stripe events, including optional (but recommended) signature verification.
  • Support for SMS to URL Forwarder, a simple but effective SMS forwarder application for Android. This is handy for those with a second or third phone and it’s also used to showcase some of the new features.
  • Integration with Nextcloud via Flow Webhooks.

Paul Schaub wrote a short blog post about their recent progress towards adding Web-of-Trust support to PGPainless. With release 1.3.2, the OpenPGP library got support for creating signatures on third-party certificates, which will help users to build their trust network.

xmpp-dns, a tool to check XMPP SRV records, was released in version 0.3.0, bringing support for DNS over TLS (DoT) and for setting a custom DNS server.

Extensions and specifications

Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

xmpp.org features a page about XMPP RFCs as well.

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

  • Bookmark Pinning
    • This document defines an XMPP protocol extension to allow users to pin PEP Native Bookmarks.
  • Pubsub Attachments
    • This specification provides a way to attach elements to a pubsub item.

New

  • WebSocket S2S
    • This specification defines a procedure to make s2s XMPP connections over WebSocket.
  • XMPP over QUIC
    • This specification defines a procedure to make both c2s and s2s XMPP connections over the QUIC protocol instead of TCP+TLS.

Deferred

If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

  • No XEPs deferred this month.

Updated

  • No XEPs updated this month.

Last Call

Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call help improving the XEP before returning it to the Council for advancement to Stable.

  • External Service Discovery
    • This document specifies an XMPP protocol extension for discovering services external to the XMPP network.

Stable

  • No XEPs advanced to Stable this month.

Deprecated

  • No XEP deprecated this month.

Call for Experience

A Call For Experience - like a Last Call, is an explicit call for comments, but in this case it’s mostly directed at people who’ve implemented, and ideally deployed, the specification. The Council then votes to move it to Final.

  • No Call for Experience this month.

Spread the news!

Please share the news on other networks:

Subscribe to the monthly XMPP newsletter
Subscribe

Also check out our RSS Feed!

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Therefore, we would like to thank Adrien Bourmault (neox), anubis, Anoxinon e.V., Benoît Sibaud, cpm, daimonduff, emus, Holger, IM, Ludovic Bocquet, martin, MattJ, MSavoritias (fae,ve), nicfab, Pierre Jarillon, Sam Whited, TheCoffeMaker, wh0nix, vanitasvitae, wurstsalat, Zash for their support and help in creation, review, translation and deployment. Many thanks to all contributors and their continuous support!

Each month’s newsletter issue is drafted in this simple pad. At the end of each month, the pad’s content is merged into the XSF Github repository. We are always happy to welcome contributors. Do not hesitate to join the discussion in our Comm-Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

  • gathering news in the XMPP universe
  • short summaries of news and events
  • summary of the monthly communication on extensions (XEPs)
  • review of the newsletter draft
  • preparation of media images
  • translations

License

This newsletter is published under CC BY-SA license.

August 03, 2022 00:00

August 02, 2022

Ignite Realtime Blog

Openfire 4.7.3 released

The Ignite Realtime Community is pleased to announce the release of Openfire version 4.7.3. This version brings a number of bug fixes and other improvements and signifies our efforts to produce a stable 4.7 series of Openfire whilst work continues on the next feature release 4.8.0.

You can find download artifacts on our website with the following sha256sum values.

f05df8e68b8d52ef2941d80884484e62dcface5069868d3f51d2bfe17a72ea5a  openfire-4.7.3-1.noarch.rpm
8ba71bbf0b1abb5c2cd0e18dc20ade77ca2714d58a8ad5313f64614bdc7dac44  openfire_4.7.3_all.deb
d2b1ffa24b3d86858e4d5451a094193c839bceae0a73773fa5ae0e114d0732ff  openfire_4_7_3.dmg
41056744e15e3a9b384b852f5e2c1d1ebb4bfd1d79bb10b54526a1fd9a7fee07  openfire_4_7_3.exe
3ced4613c3cef61068fb89eed723e49b5845e960c6eec194961f75bc65042832  openfire_4_7_3.tar.gz
9c8ebcb930f2373713c1eb53a4b70d9f76a8577b95cbefd41e1ae284c2ff28aa  openfire_4_7_3_x64.exe
670db7574e6b528145c002f22f58789f949d5d5c03fbe372204816db07bd01e7  openfire_4_7_3.zip

As always, thanks for your interest in Openfire and stop by the open chat if you need any help or just want to say hi! Please report any issues you have in our Community Forums.

1 post - 1 participant

Read full topic

by guus at August 02, 2022 14:05

July 27, 2022

JMP

Newsletter: Multilingual Transcriptions and Better Voicemail Greetings

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

As foreshadowed last month, the new voicemail transcription engine is now live for all customers who have transcription enabled (which it is by default).  This should improve speed and accuracy, and bring support for many more languages to the system.  Let us know if you notice any issues with the new transcriptions.

From the beginning of the voicemail system we have supported a default text-to-speech greeting if a custom one is not set.  The name used in this greeting is sourced from the customer’s legacy vCard if they have one set up.  We now also support modern vCard4 and PEP Nickname specifications to get this data, which should result in it working for many more people with many more clients.  Check the voicemail FAQ for details.

Many new JMP customers are also new to Jabber in general, and so our signup process usually suggests one or more free-to-use volunteer-run Jabber services that one can sign up with to get a working Jabber ID.  These services are best-effort by volunteers, and this month one of the ones most popular with our customers experienced an extended outage.  The best protection you can have against any kind of outage at your Jabber service is to have your Jabber ID be attached to a DNS name you control.  With or without your own name, we also include the option for any JMP customer to get an instance hosted by Snikket at no extra charge.  Please contact support if you have any questions about this.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

by Stephen Paul Weber at July 27, 2022 17:30

July 24, 2022

Gajim

Gajim 1.4.7

Gajim 1.4.7 brings performance improvements, better file previews, and many bug fixes. Thanks for all your reports!

What’s New

Multiple issues with Gajim’s file preview have been fixed. If you want to disable file previews entirely, there is now a setting in Gajim’s preferences.

For people with many contacts in their contact list, this release will bring a significant performance improvement 🚀

Furthermore, notifications on Windows should not appear in the taskbar anymore.

Fixes and improvements

Several issues have been fixed in this release.

  • Improved detection of emoji shortcodes
  • Flatpak: Fixed tray icon
  • Renaming a contact now preserves its groups
  • Fixed an issue where the new message icon would vanish even though messages haven’t been read

Have a look at the changelog for the complete list.

Gajim

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab.

July 24, 2022 00:00

July 22, 2022

Ignite Realtime Blog

REST API Openfire plugin 1.8.3 released!

We recently release version 1.8.3 of the Openfire REST API plugin. This version extends the MUC search capability to include the natural name of the MUC (instead of just the name). It also updates a number of library dependencies.

The updated plugin should be available for download in your Openfire admin console already. Alternatively, you can download the plugin directly, from the plugin’s archive page .

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

by danc at July 22, 2022 15:01

July 19, 2022

Paul Schaub

Creating a Web-of-Trust Implementation: Certify Keys with PGPainless

Currently I am working on a Web-of-Trust implementation for the OpenPGP library PGPainless. This work will be funded by the awesome NLnet foundation through NGI Assure. Check them out! NGI Assure is made possible with financial support from the European Commission’s Next Generation Internet programme.

NLnet
NGI Assure

Technically, the WoT consists of a graph where the nodes are OpenPGP keys (certificates) with User-IDs and the edges are signatures. I recommend watching this talk by Justus Winter (22:51) to get an overview of what the benefits of the WoT are. In order to be able to create a WoT, users need to be able to sign other users certificates to create those edges.

Therefore, support for signing other certificates and User-IDs was added to PGPainless as a milestone of the project. Since release 1.3.2, users have access to a straight-forward API to create signatures over other users certificates. Let’s explore the new API together!

There are two main categories of signatures which are important for the WoT:

  • Certifications are signatures over User-IDs on certificates. A certification is a statement “I believe that the person holding this certificate goes by the name ‘Alice alice@pgpainless.org‘”.
  • Delegations are signatures over certificates which can be used to delegate trust decisions to the holder of the signed certificate.

This is an example for how a user can certify a User-ID:

PGPSecretKeyRing aliceKey = ...;
PGPPublicKeyRing bobsCertificate = ...;

CertificationResult result = PGPainless.certify()
        .userIdOnCertificate("Bob Babbage <bob@pgpainless.org>",
                bobsCertificate)
        .withKey(aliceKey, protector)
        .build();

PGPSignature certification = result.getCertification();
// or...
PGPPublicKeyRing certifiedCertificate = result.getCertifiedCertificate();

It is possible to choose between different certification types, depending on the “quality” of the certification. By default, the certification is created as GENERIC_CERTIFICATION, but other levels can be chosen as well.

Furthermore, it is possible to modify the signature with additional signature subpackets, e.g. custom annotations etc.

In order to create a delegation, e.g. in order to delegate trust to an OpenPGP CA, the user can do as follows:

PGPSecretKeyRing aliceKey = ...;
PGPPublicKeyRing caCertificate = ...;

CertificationResult result = PGPainless.certify()
        .certificate(caCertificate,
                Trustworthiness.fullyTrusted().introducer())
        .withKey(aliceKey, protector)
        .buildWithSubpackets(new CertificationSubpackets.Callback() {
            @Override
            public void modifyHashedSubpackets(
                    CertificationSubpackets hashedSubpackets) {
                hashedSubpackets.setRegularExpression(
                        "<[^>]+[@.]pgpainless\.org>$");
            }
        });

PGPSignature delegation = result.getCertification();
// or...
PGPPublicKeyRing delegatedCertificate = result.getCertifiedCertificate();

Here, Alice decided to delegate to the CA as a fully trusted introducer, meaning Alice will trust certificates that were certified by the CA.

Depending on the use-case, it is advisable to scope the delegation, e.g. to a specific domain by adding a Regex packet to the signature, as seen above. As a result, Alice will only trust those certificates introduced by the CA, which have a user-id matching the regex. This is optional however.

Check out PGPainless and don’t forget to check out the awesome NLnet foundation!

by vanitasvitae at July 19, 2022 17:23

July 14, 2022

Erlang Solutions

Updates to the MongooseIM Inbox in version 5.1

This article describes new improvements to the Inbox feature of MongooseIM – an open-source XMPP server. We added “boxes” so you can keep your inbox organized as well as a lot of performance improvements in the new 5.1 release

User interfaces in open protocols

When a messaging client starts, it typically presents the user with:

  • an inbox
  • a summary of chats (in chronological order)
  • unread messages in their conversation
  • a snippet of the most recent message in the conversation
  • information on if a conversation is muted (and if so how long a conversation is muted for)
  • other information that users may find useful on their welcome screen

MongooseIM as a messaging server uses XMPP as its underlying protocol, and to gather the data needed above, traditional XMPP makes it possible to build a summary by combining knowledge of the users’ roster (friend list), the archive, and possibly private storage for any extensions, but this means far too many round-trips between the server and the client to build the initial UI, a number of round-trips that worsens the more out-of-date the client is, and which also imposes a load on the server to answer them all.

MongooseIM Inbox open extension

For this, MongooseIM introduced an extension called inbox, back in 3.0.0, that simply keeps track of the active conversations, the snippet with the last message, and a count of unread messages for each conversation which is, intuitively, restarted when a user sends a new message or a chat marker pointing to the latest message in the chat.

In retrospect

In 3.5.0, we introduced a mechanism to manually set the unread count of a conversation to zero, which is a common operation for a user, when reading the conversation is as undesired as continuing to see it pop up with unread messages, but on 4.2.0 we took this really seriously: we introduced a mechanism to not only set a conversation as read, but also to set it as unread again, to mark a conversation as muted until a certain date, and to unmute it as well.

Until now we had not added a function to set as unread because it would have been easy to introduce a problematic API and it was deemed out-of-scope for the effort at that time: if we allowed a client to set any count they desire, we might allow broken client software to break the experience of a good client software. the same user might use separately, for example by setting a number much higher than the actual number of messages in the conversation. And there’s also the chance of setting a number at the same time more messages arrive, that would therefore invalidate the count: should the number requested be considered an absolute number, or an increment? In the end, we settled for an atomic “set-as-one-if-it-was-zero”, i.e., if the conversation already had unread messages, the request does nothing. If the conversation was fully read, the request only sets it as strictly one. This way, a user cannot possibly move away from the actual number of unread messages, set incorrect numbers, or accidentally set a number at the same time more messages arrive.

But this is not all, what if the user doesn’t want to be notified about a certain conversation? For example, they might say “mute this chat for an hour”, and all their devices should sync on the fact that the chat shouldn’t be making the phone buzz, and maybe the logo should be displayed differently. 4.2.0 introduces a possibility for that as well! A client might provide the number of seconds they want a conversation muted for, and MongooseIM will tell all his other devices, persist this information on the inbox summary, and propagate this information to be picked up by other services, like possibly the push-notification one.

Classifications

One more functionality (apart from a myriad of performance optimizations!) added in the latest MongooseIM 5.1, the concept of boxes. Like in an email service, a user can classify chats in boxes like “favourites”, “travel”, “business”, or “home”. You can set a box for a chat and then when reconnecting focus on that box specifically in MongooseIM, and build a nice UI accordingly, including a “pinned” box of conversations you always want at the top!

Configuration

To use this functionality, it is as easy as enabling the inbox module in your MongooseIM configuration, all the defaults are set for you. Out-of-the-box the inbox will have the “inbox”, “archive” and “bin” boxes enabled, and the trash bin will be periodically cleaned every hour for entries older than 30 days. Group chats are enabled, chats are considered read when a displayed marker is sent, and the synchronous backend is chosen. To go further away from the details, try enabling the asynchronous backend, see below for the scalability details.

It always comes down to scalability

Another important feature is the creation of an asynchronous backend for inbox. Until now, inbox operations were synchronous in the context of a message processing pipeline: that means that the message processing would be blocked by the database operation, until the database successfully returned. This becomes especially bad for big group-chats where a message updates the inbox of each room participant. This means that MongooseIM’s message processing throughput would be as scalable as the database is, which is bad news.

Releasing the Database

In order to untie MongooseIM’s scalability from the database performance, we needed to first make the inbox processing asynchronous, that is, the message processing pipeline will only “submit a task” to update the appropriate inbox. But this still leaves the fact that the inbox generates too many database operations. So we tried to do less of them: the trick was that inbox is (mostly) an update-only operation: Alice receives a message from Bob, we update Alice’s inbox’s snippet with the new message, and an incremented count of one, Alice receives a new message, we update the snippet again with an incremented count of another one. We could have just applied the second update with an incremented count of two instead!

% If we don't have any request pending, it means that it is the first task submitted,
% so aggregation is not needed.
handle_task(_, Value, #state{async_request = no_request_pending} = State) ->
    State#state{async_request = make_async_request(Value, State)};
handle_task(Key, NewValue, #state{aggregate_callback = Aggregator,
                                  flush_elems = Acc,
                                  flush_queue = Queue,
                                  flush_extra = Extra} = State) ->
    case Acc of
        #{Key := OldValue} ->
            case Aggregator(OldValue, NewValue, Extra) of
                {ok, FinalValue} ->
                    State#state{flush_elems = Acc#{Key := FinalValue}};
                {error, Reason} ->
                    ?LOG_ERROR(log_fields(State, #{what => aggregation_failed, reason => Reason})),
                    State
            end;
        _ ->
            % The queue is used to ensure the order in which elements are flushed,
            % so that first requests are first flushed.
            State#state{flush_elems = Acc#{Key => NewValue},
                        flush_queue = queue:in(Key, Queue)}
    end.

The new inbox asynchronous backend does just this: it submits updates to the database immediately, but instead of waiting for the database’s response, it aggregates all upcoming requests in the meantime. This means that on an unloaded server inbox is still pretty much immediate, and it will saturate the database throughput as fast as messages arrive: but once the database is saturated, it will not overload it!

aggregate({set_inbox_incr_unread, _, _, _, _, Incrs2, _},
          {set_inbox_incr_unread, Entry, Content, MsgId, Timestamp, Incrs1, Box}) ->
    {set_inbox_incr_unread, Entry, Content, MsgId, Timestamp, Incrs1 + Incrs2, Box};

To enable this backend, all you need to do is to select “rdbms_async” as the inbox backend in your mongooseim.toml configuration file and you’re good to go!

Note some comparisons:

rdbms
12k users, rooms
of 5 user
rdbms_async
30k users, rooms of 10 users
No inbox
35k users, rooms of 10 users
Delivery time, .99>40s
50ms
50ms
Stanzas sent per minute140k180k180k
CPU usage80%99%99%
Memory usage800MB1200MB950MB

Note how for the traditional backend the CPU is not even saturated and messages are terribly stalled, but for the new asynchronous backend, we saturate the CPU with more than twice the number of users, and get pretty fast delivery times. Even when compared to disabling inbox altogether, the regular backend penalty shoots above 70% of the throughput, while the new backend costs only 12% (35k users lowers to 30k).

The post Updates to the MongooseIM Inbox in version 5.1 appeared first on Erlang Solutions.

by Nelson Vides Luzardo at July 14, 2022 10:26

July 13, 2022

Ignite Realtime Blog

Openfire 4.7.2 released

The Ignite Realtime Community is pleased to announce the release of Openfire version 4.7.2. This version fixes a number of bugs and signifies our efforts to produce a stable 4.7 series of Openfire whilst work continues on the next feature release 4.8.0.

A major highlight of this release is fixing of BOSH bugs found under load testing.

You can find download artifacts on our website with the following sha256sum values.

998e469fad00452004c9f9d6c309c6749fa48d53af48c1501407f0f77870edca  openfire-4.7.2-1.noarch.rpm
72ee5a31685f6010fc14a992d87d2d1f9c49b79b4e718c239520911ec7167340  openfire_4.7.2_all.deb
674bab49908ff4de14f54dab1fdf7a6a29904b32f00669289b793d8dc19189c8  openfire_4_7_2.dmg
66571c760776d02a28d00ed3c0ca085c327a1874f9d75f8b2037b347ec99decb  openfire_4_7_2.exe
707ede6cc6d8d8bcce257c7f30d8a79fc7ed52576fb217a8220b800f2d52be64  openfire_4_7_2.tar.gz
8eeaf4f07948d10b6b77b3e1e8b8d1f65a6ad3ffd85e5353a2d8055503d724fc  openfire_4_7_2_x64.exe
ad07c991a3812a45250b303e95129a37242de01a591cce438057437d4f5a30d9  openfire_4_7_2.zip

For those of you curious, here’s an accounting of artifact downloads from the previous release.

Openfire Download Stats for Release: 4.7.1
           openfire-4.7.1-1.noarch.rpm   3690
                openfire_4.7.1_all.deb   8102
                    openfire_4_7_1.dmg   1018
                    openfire_4_7_1.exe   6338
                 openfire_4_7_1.tar.gz   4175
                    openfire_4_7_1.zip   2029
                openfire_4_7_1_x64.exe  18466
                                       ======
                                        43818

As always, thanks for your interest in Openfire and stop by the open chat if you need any help or just want to say hi! Please report any issues you have in our Community Forums.

1 post - 1 participant

Read full topic

by akrherz at July 13, 2022 13:24

July 07, 2022

Gajim

Gajim 1.4.6

Gajim 1.4.6 fixes some bugs with the status icon and notifications. Emoji short code detection has been improved.

Fixes and improvements

Several issues have been fixed in this release.

  • Improved detection of emoji short codes
  • Tray icon with libappindicator has been fixed
  • Groups are now preserved when changing a contact’s name
  • Windows: Notifications shouldn’t appear in the taskbar anymore

Have a look at the changelog for the complete list.

Gajim

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab.

July 07, 2022 00:00

July 06, 2022

Ignite Realtime Blog

Push Notification Openfire plugin 0.9.1 released

The Ignite Realtime community is happy to announce the immediate availability of a bugfix release for the Push Notification plugin for Openfire!

This plugin adds support for sending push notifications to client software, as described in XEP-0357: “Push Notifications”.

This update includes only one bugfix, but one that prevented functionality for many people. You are highly encouraged to update!

Your instance of Openfire should automatically display the availability of the plugin in the next few hours. Alternatively, you can download the new release of the plugin at the Push Notification plugin archive page

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

by guus at July 06, 2022 07:59

July 05, 2022

The XMPP Standards Foundation

The XMPP Newsletter June 2022

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of June 2022.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, especially throughout the current situation, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

Newsletter translations

This is a community effort, and we would like to thank translators for their contributions. Volunteers are welcome! Translations of the XMPP Newsletter will be released here (with some delay):

XSF Announcements

  • The XSF membership application period for the third quarter 2022 is currently open. If you are interested in becoming a XSF member then you can apply for membership.

Google Summer of Code 2022

XSF and Google Summer of Code 2022

The Google Summer of Code 2022 has lifted off and coding started a while ago! The two new contributors Patiga and PawBud who will work on open-source software projects in the XMPP environment. Read their first blog posts, too.

Feel free to spread the word via Mastodon or Twitter. More details in our designated page at xmpp.org.

XSF fiscal hosting projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective. For more information, see the announcement blog post. Current projects:

Events

Articles

JMP News: Command UI and better transcriptions coming soon.

Nicola Fabiano wrote the article To be «IM apps addicted» or not to be, that is the question. Choose to be free: Snikket, the system messaging based on XMPP protocol highlighting XMPP as his best solution and Snikket as his choice. In another article he states his reasons to avoid WhatsApp, also considering the European Commission’s actions: Persisting with Whatsapp use: how to persevere unknowingly. The whys of our «No».

Paul Schaub wrote a piece on PGPainless: Reproducible Builds – Telling of a Debugging Story.

Prosody devs got funded by EU’s NGI Assure via the NLnet Foundation to modernize XMPP authentication and authorization so users can secure their sessions with MFA (multi-factor authentication) and have peace of mind with per session controls.

Software news

Clients and applications

Gajim 1.4.3, 1.4.4, and 1.4.5 have been released: Gajim’s new versions come with many improvements: emoji auto-complete, automatic theme switching when your desktop switches from light to dark in the evening, a completely reworked Gajim remote interface, and many bug fixes.

Gajim emoji auto-complete

Servers

MongooseIM’s new release 5.1 comes with a configuration rework.

Jackal 0.61.0 has been released.

ProcessOne announced ejabberd .deb and .rpm repositories for amd64 and arm64 systems.

ejabberd .deb and .rpm

Prosody 0.12.1 has been released, and it comes with improved compatibility with Jitsi Meet plus bug fixes for its newly-extended XEP-0227 support.

From the ignite realtime community:

Libraries

No news this month.

Extensions and specifications

Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

By the way, xmpp.org features a new page about XMPP RFCs.

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

  • WebSocket S2S
    • This specification defines a procedure to make s2s XMPP connections over WebSocket.
  • XMPP over QUIC
    • This specification defines a procedure to make both c2s and s2s XMPP connections over the QUIC protocol instead of TCP+TLS.

New

  • No New XEPs this month

Deferred

If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

  • No XEPs deferred this month.

Updated

  • No XEPs updated this month.

Last Call

Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call help improving the XEP before returning it to the Council for advancement to Stable.

  • External Service Discovery
    • This document specifies an XMPP protocol extension for discovering services external to the XMPP network.

Stable

  • No XEPs advanced to Stable this month.

Deprecated

  • No XEP deprecated this month.

Call for Experience

A Call For Experience - like a Last Call, is an explicit call for comments, but in this case it’s mostly directed at people who’ve implemented, and ideally deployed, the specification. The Council then votes to move it to Final.

  • No Call for Experience this month.

Spread the news!

Please share the news on other networks:

Subscribe to the monthly XMPP newsletter
Subscribe

Also check out our RSS Feed!

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Therefore, we would like to thank Adrien Bourmault (neox), anubis, Anoxinon e.V., Benoît Sibaud, cpm, daimonduff, emus, guusdk, Holger, Ludovic Bocquet, MattJ, MSavoritias (fae,ve), nicfab, TheCoffeMaker, wh0nix, wurstsalat, Zash for their support and help in creation, review, translation and deployment. Many thanks to all contributors and their continuous support!

Each month’s newsletter issue is drafted in this simple pad. At the end of each month, the pad’s content is merged into the XSF Github repository. We are always happy to welcome contributors. Do not hesitate to join the discussion in our Comm-Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

  • gathering news in the XMPP universe
  • short summaries of news and events
  • summary of the monthly communication on extensions (XEPs)
  • review of the newsletter draft
  • preparation of media images
  • translations

License

This newsletter is published under CC BY-SA license.

July 05, 2022 00:00

July 03, 2022

The XMPP Standards Foundation

ConverseJS: An in-depth view into my GSoC'22 project!

In this blog, I will discuss my GSoC project, and post an update about the work done since the GSoC contribution period started. Ok, so I would like to split the whole project in two phases, with the first GSoC evaluation (29th July) as being the divider. Since it’s only been three weeks, I will only write about the first phase of the project.

About my project

  • Expected Hours: 175 Hrs(Medium Project)
    • Adding support for Audio/Video Communication via Jingle.
    • Deliverables / Expected Results:
      • The goal is to create a Converse plugin that adds the ability to make one-on-one audio/video calls from Converse
      • The audio/video calls must be compatible with other XMPP clients such as Conversations.

Jingle protocol works something like this:

Jingle Protocol

In short it signals WebRTC to start/end or modify the status of a session.

Proposed Plan

The first phase, as it stands, will consist of the UI implementation, it’s associated tests and implementaion of XEP 0353. I genuinely thought that I would be done with the UI implementation till now, but choosing a UI can be surprisingly tough. Given the deadline, I want to make sure that I complete the implementation of the project in time, so for now we (me & my mentor JC) decided to implement a decent looking UI that would be enough to cover all the edge cases and functionality of the project.

UI

Here is a screenshot which shows the current UI.

Call pending state

Do mind the spacing between the Call Initiated text and the End Call button. The call can simply be ended after clicking either the end call button or the call button in the toolbar. Having said that, I presented Discord’s UI to my mentor and he seemed to like it.

Discord’s Call UI

Although, we plan to build something much more simpler for converse, it’s good to have a long term vision for this feature.

Tests

As on this date of writing this blog, I am working on integrating XEP 0353. The XEP makes it easier to keep track of my progress since it splits the feature into sections.

You can track my progress through this Pull Request

July 03, 2022 00:00

June 30, 2022

Dino

Project Stateless File Sharing: First Steps

Hey, this is my first development update! As some of you might already know from my last blog post, my Google Summer of Code project is implementing Stateless File Sharing for Dino. This is my first XMPP project and as such, I had to learn very basic things about it. In my blog posts I’ll try to document the things I learned, with the idea that it might help someone else in the future. I won’t refrain from explaining terms you might take for granted in the XMPP world.

The idea behind Stateless File Sharing

Currently there are mutiple ways to send files via XMPP. Some of those methods initiate the file transfers in very different ways. This makes it difficult to add shiny new features like blurred previews of images, because we would need to implement that for each file transfer individually.

What we want is a unified initiation for file transfers. In that initiation, “sources” should be specified that tell the receiver how they can access that file.

Relevant XEPs

The core of the XMPP protocol is very slim, defining only general ways of communicating data. It is build to be extensible, and XEP are exactly that: XMPP Extension Protocols.

Stateless File Sharing is XEP-0447. It depends on XEP-0446, which defines the metadata that should be sent alongside a file. XEP-0446 in turn depends on XEP-0300, where the integration of hashes is specified, and XEP-0264, which defines the usage of thumbnails.

Stanzas

This is a term that comes up everywhere if you dive into XMPP technical information. Since it confused be for a while, here a quick rundown.

Stanzas are the basic form of communication between XMPP clients and servers. There are different types of them, but they are all encoded with XML. As such, they inherit XML’s structure.

An XML element can be viewed as a tree. See for instance the format example for the file metadata element (XEP-0446):

<file xmlns='urn:xmpp:file:metadata:0'>
    <media-type>text/plain</media-type>
    <name>test.txt</name>
    <date>2015-07-26T21:46:00+01:00</date>
    <size>6144</size>
    <hash xmlns='urn:xmpp:hashes:2'
          algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=</hash>
</file>

The root element is called ‘file’, and has only one attribute “xmlns”. Each attribute has a value assigned, in this case its ‘urn:xmpp:file:metadata:0’. The ‘file’ element also has child elements, all containing a text body. Only the “hash” child element has an additional attribute.

Progress (as of 29/06/2022)

I’m now familiar with how Dino represents Stanzas. I’ve created the base struct for the file metadata element (XEP-0446) and serialize, send, and deserialize it. So far I simply integrate the code into the http file transfer code, detaching from it will come later.

You can track my progress on my stateless-file-sharing branch!

June 30, 2022 00:00

June 29, 2022

JMP

Newsletter: Command UI and Better Transcriptions Coming Soon

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

This month the team has been hard at work on a new major feature for Cheogram Android: the command UI.  This feature will get rid of the need to configure your account with a clunky chat bot on mobile, replacing it with a fit-for-purpose native UI that can be viewed under the cheogram.com contact.  And because we are implementing it using only open standards, the UI will also work for other command-using entities out there.  The feature is not quite ready for first release, but if you want to come test a pre-release just drop by the chatroom (see below for how to get to the chatroom).

Almost since the beginning of JMP one of the favourite features has been our voicemail.  Reading your voicemails instead of having to “dial in” somewhere and listen to them is a real advantage for many users.  However, the transcription is far from perfect, sometimes being slow and completely missing support for any language other than English.  We are now testing an alternative engine with anyone who is interested, this new engine gets you the transcription faster and supports dozens of languages.  Come by the chatroom if you want to help test this out before we roll it out as a full replacement.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

by Stephen Paul Weber at June 29, 2022 18:00

Sam Whited

Sirius

Name
Sirius
Designation
α CMa
Make/model
Honda CB1100
Style
Naked bike
Engine
1140cc air-cooled inline four
Tires
Metzeler Roadtec Z8 Interact Tires 110/80-18; 140/70-18
Purchased
2022-06-07
Miles
75803

With gas prices as high as they are I recently decided to sell my Honda S2000, Vela. Though I normally say that there is never a reason to buy a new vehicle when a used one can be had that’s just as good, depreciates less, and is cheaper, I’ve decided to break my own rule and ordered a new truck (more on that in a later post). However, even though I placed my order in October of 2021 I have yet to hear anything from the manufacturer. I was getting tired of the almost 2 hour each way commute by bicycle-bus-train-bicycle, so I decided to get a temporary vehicle until my truck comes. I wanted something that was cheap, had good gas mileage, and that was easy to repair so that I wouldn’t have to pay a mechanic to work on it if I ran into trouble, so I decided to go with a motorcycle. I ended up finding a Honda CB1100 with ~76k miles at a reasonable price and went for it!

3.5mm audio jack 3.5mm close up

Since I named each of my cars after constellations, I decided to name my motorcycle after an individual star: Sirius.

Star map of Canis Major

Star Map of Canis Major

Star map by Torsten Bronger and Kxx, CC-BY-SA

New Tires

The first thing I did is put some new rubber on it, jacking it up was interesting, to say the least.

A motorcycle supported by its center stand and some ratchet straps looped over the ceiling joists and under the fork

I went with the Metzeler Roadtec Z8 Interact Tires after several recommendations from local shops. They were the same as the worn ones which were already on the bike and were one of the few tires I could find in the relatively odd combination of 110/80-18 and 140/70-18. I put ~40 miles/day on the bike commuting to work, so some fresh tires were important.

Date
2022-06-27
Tires
No change (Metzeler Roadtec Z8 Interact Tires 110/80-18; 140/70-18)
Miles
76818

I’m not planning on building the bike out in any particular way (nor do I have the money), so I’m not sure that this will turn into a longer build blog, but I hope to get lots of high-gas-mileage and fun miles out of Sirius. As always, I’ll update this post with any modifications I make, or possibly with short trip reports that aren’t worth a full post on their own. In particular, I’m looking forward to a ride in the North East Georgia mountains sometime very soon!

Until then, ride on!

June 29, 2022 11:22

Ignite Realtime Blog

Smack 4.4.6 released

We are happy to announce the release of Smack 4.4.6. For a high-level overview of what’s changed in Smack 4.4.6, check out Smack’s changelog

This release mostly consists of bug fixes, many of them reported by the Jitsi folks. I would like to thank especially Damian Minkov for detailed problem descriptions, for the fruitful collaboration and for various joint bug hunts which turned out to be very successful. :slight_smile:

As always, all Smack releases are available via Maven Central.

We would like to use this occasion to point at that Smack now ships with a NOTICE file. Please note that this adds some requirements when using Smack as per the Apache License 2.0. The content of Smack’s NOTICE file can conveniently be retrieved using Smack.getNoticeStream().

2 posts - 2 participants

Read full topic

by Flow at June 29, 2022 08:22

June 27, 2022

Erlang Solutions

Gaining a Competitive Advantage in Fintech From Your Choice of Tech Stack

In our recent white paper ‘Technology Trends in Financial Services 2022’, we explained the importance of software engineering for gaining a competitive advantage in the industry. Since the start of the year, a lot has occurred on a macro level strengthening our belief that modern financial services must be based on a solid technical foundation to deliver the user experiences and business reliability needed for commercial success.

We see the role of the underlying technology (away from the customer-facing products) as being critical in enabling success in fintech in two main ways:

  • Building customer trust – by guaranteeing operational resilience and optimal availability of fintech systems
  • Exceptional user experience – rapid development of features facilitated by a tech stack that just works

These tenets, if you like, are core to the Erlang ecosystem, including the Elixir programming language and the powerful BEAM VM (or virtual machine). In this follow-up article, we will dive deeper into how your choice of tech stack impacts your business outcomes and why Erlang and Elixir will often be the right tool for the job in fintech. We also share some guiding principles that underpin our expert engineering team’s approach to projects in the financial services space.

What are the desirable characteristics of a fintech system?

Let’s first look at some of the non-negotiable must-haves of a tech stack if you are involved in a fintech development project.

A seamless customer experience

Many projects fail in the fintech space due to focusing only on an application’s user interface. This short-sighted view doesn’t consider the knock-on effects of predicted (user growth) or unpredicted changes (like the pandemic lockdowns). For instance, your slick customer interface loses a lot of its shine when it’s connected to a legacy backend that is sluggish in responding to requests. 

Key point: When it comes to modern financial services, customers expect real-time, seamless and intelligent services and not clunky experiences. To ensure you deliver this, you need predictable behaviour under heavy loads and during usage spikes, resilience and fault-tolerance without the associated costs sky-rocketing.

Technology that enables business agility

Financial services is a fast-moving industry. To make the most of emerging opportunities, whether as an incumbent or fintech-led startup, you need to be agile from a business perspective, which is bound to tech agility. With the adoption of open-source technology on the rise in FS, we’re starting to see the benefits of moving away from proprietary tech, the risk of vendor lock-in, and the obstacles that can create. When you can dedicate more resources to shipping code without being constrained and forced into unfavourable trade-offs, you’re better positioned to cash in on opportunities before your competitors.

Key point: You want a system that is easy to maintain and understand; this will help with onboarding new developers to the team and focusing resources where they can make the most impact.

Tech stacks that use fewer resources

Designing for sustainability is now a key consideration for any business, especially in an industry under the microscope like financial services. The software industry is responsible for a high level of carbon usage, and shareholders and investors are now weighing this up when making investment decisions. As funding in the tech space tightens, this is something that business leaders need to be aware of as a part of their tech decision-making strategy.

CTOs and architects can help by making better choices in technologies. For instance, using a BEAM-based language can reduce the physical infrastructure requiring just one-tenth of the servers. That leads to significant cost reductions and considerable savings in terms of carbon footprint.  

Key point: Minimising costs is important, but sustainability too is now part of the consideration process.

System Reliability and availability

A robust operational resiliency strategy strengthens your business case in financial services. We’ve learnt from the stress placed on systems caused by spikes in online commerce since the pandemic is that using technologies that are proven and built to deal with the unpredictability of the modern world is critical.

One thing sure to damage any FS player, regardless of size, is high-profile system outages and downtime. This can cause severe reputation damage and attract hefty fines from regulators.

According to Gartner, the average cost of IT downtime is around $5,600 per minute. That is about $300,000 per hour on average. So avoiding downtime in your fintech production system is mission-critical.

Key point: Your fintech system must be fault-tolerant, able to handle spikes in traffic and always be available and scalable.

How Erlang/Elixir is meeting these challenges

Erlang, Elixir and the BEAM VM overview

Erlang is a programming language designed to build massively scalable, soft real-time systems that require high availability. Elixir is a programming language that runs on the BEAM VM – the same virtual machine as Erlang – and can be adopted throughout the tech stack. Many of the world’s largest banking, e-commerce and fintech companies depend on these technologies to power their tech stacks, such as Klarna, SumUp and SolarisBank.

In telecoms, where phone systems, by law, had to work, and penalties were huge if they failed. Vendors designed in resilience from day one and not as an afterthought. Erlang and Elixir, as programming languages originally designed for the telecoms, are the right tools for the job for many fintech use cases where fault-tolerance and reliability are also essential.

Of course, many languages are being used successfully across financial services but, the big differentiator with Erlang and Elixir is that high availability, fault-tolerance and scalability are built-in, out of the box. This makes developers’ lives easier and allows them the freedom to deliver innovative features to end-users. For fast-moving verticals such as fintech, the robust libraries and reduced lines of code compared to C, C++ or Java mean that you are set up for rapid prototyping and getting to market before the opposition.

Key attributes of Erlang/Elixir for fintech development:

  • Can handle a huge number of concurrent activities
  • Ideal for when actions must be performed at a certain point in time or within a specific time (soft real-time)
  • Benefits of system distribution
  • Ideal for massive software systems
  • Software maintenance without stopping the system
  • Built-in fault tolerance and reliability

If you’re in the early stages of your fintech project, you may not need these capabilities right away, but trying to retrofit them later will cost you valuable time and resources. Our expert team has helped many teams adopt BEAM-based technology at various times in their business lifecycle, talk to us about how we can help you.  

Let’s start a discussion about how we can help with your fintech project >

Now let’s look at how Erlang/Elixir and the BEAM VM deliver against the desirable fintech characteristics outlined in the previous section.

System availability and resilience during unpredicted events

Functional Programming helps developers to write reliable software. Using the BEAM VM means you can have reliability of up to ‘nine-nines’ (99.9999999%) – that’s almost zero downtime for your system, obviously very desirable in any fintech system.

This comes from Erlang/Elixir systems having ‘no single point of failure’ that risks bringing down your entire system. The ‘actor model’ (where parallel processes communicate with each other via messages) crucially does not have shared memory, so errors that inevitably will occur are localised and will not impact the rest of your system.

Fault tolerance is another crucial aspect of Erlang/Elixir systems, making them a good option for your fintech project. ‘Supervisors’ are programmed with instructions on how to restart parts of a system when things do fail. This involves going back to a known initial state that is guaranteed to work:

The end result is that using Erlang/Elixir means that your system will achieve unrivalled availability with far less effort and resources than other programming languages.

System scalability for when demand grows

Along with unmatched system uptime and availability, Erlang and Elixir offer scalability that makes your system able to handle changes in demand and sudden spikes in traffic. This is possible without many of the difficulties of trying to scale with other programming languages.

With Erlang/Elixir, your code allows thousands of ‘processes’ to run concurrently on the same machine – in other words, you are making the most of each machine’s resources (vertical scaling). 

These processes are distributed, meaning they can communicate with processes on other machines within the network enabling developers to coordinate work across multiple nodes (horizontal scaling).

In the fintech startup space especially, having confidence that if you achieve dramatic levels of fast growth, your tech system will stand up to demand and not require a costly rewrite of the codebase can be a critical factor in maintaining momentum.

Concurrency model for high volume transactional systems

Concurrent Programming makes it appear like multiple sequences of commands are being executed in parallel. Erlang and Elixir are ideal for workloads that involve a considerable amount of concurrency, such as with transaction-intensive segments of financial services like payments and trading.  

The functional nature of Erlang/Elixir, plus the lightweight nature of how the BEAM executes processes, makes writing concurrent programs far more straightforward than with other languages.

If your fintech project expects to need to process massive amounts of transactional data from different sources, then Erlang/Elixir could be the most frictionless way for your team to go about building it.

Developer friendly 

There are many reasons why developers enjoy working with Erlang/Elixir – in fact, Elixir has just been voted the second most loved programming language in the 2022 Stack Overflow Developer Survey.

OTP middleware (the secret sauce behind Erlang/Elixir) abstracts the technical difficulty of concurrency and handling system failures. It allows your tech team the space to focus on business logic instead of time-consuming computational plumbing and facilitates fast prototyping and development of new features. 

Speed to market is a crucial differentiator in the competitive fintech landscape, with Erlang/Elixir you can release new features in time to attract new customers and retain existing ones better than with many other languages.

Because using Erlang/Elixir for your project means less code and a lightweight execution model of processes demanding fewer CPU resources, you will need fewer servers, reducing your energy consumption and infrastructure costs. An independent study made at Heriot-Watt University found that an application written in Erlang compared to one in C++ found that 4-20 times less code was required for the Erlang codebase.

During the beginning of the pandemic in 2020, Turn.io used Elixir to launch the world’s first WhatsApp-based COVID-19 response in just 5 days. The service was designed, deployed, stress-tested, and launched. It scaled to 450K unique users on the first day and has since grown to serve over 7.5 million people.

Key takeaways about using Erlang and Elixir in fintech

We can summarise that what is needed for success in fintech is a real-time, secure, reliable and scalable system that is easy to maintain and cost-efficient. Furthermore, you need a stack that lets your developers ship code and release new products and features quickly. The Erlang Ecosystem (Erlang, Elixir and the BEAM VM) sets a solid foundation for your fintech startup or project to be successful. 

With a reliable, easy-to-maintain code base, your most valuable resource (your tech talent) will be freed up to concentrate on delivering value and competitive advantage that delivers to your bottom line.

With the right financial products to market and an Erlang/Elixir backend, you can be confident in delivering smooth and fast end-user experiences that are always available and seamless. This is crucial if you are looking to digitally onboard new customers, operate payment services, handle vast numbers of transactions or build trust in emerging areas such as cryptocurrency or blockchain.

The benefits of using Erlang/Elixir for your fintech project

2x FASTER DEVELOPMENT – of new services thanks to the language’s design, the OTP middleware, set of frameworks, principles, and design patterns that guide and support the structure, design, implementation, and deployment 

10x BETTER RELIABILITY –  services that are down less than 5 minutes per year thanks to built-in fault tolerance and resilience mechanisms built into the language and the OTP middleware, e.g. software upgrades and generic error handling, as seen by e.g. Ericsson in their mobile network packet routers.

10x MORE SECURE – solutions that are hard to hack and crash through denial of service attacks thanks to the language construction with lack of pointers, use of messages instead of shared memory and immutable state rather than variable assignments, as seen by the reduced number of vulnerabilities compared to other languages.

10x MORE USERS – handling of the potential millions of transactions per second within milliseconds thanks to a battle-tested VM.

10x LESS COSTS AND ENERGY CONSUMPTION – thanks to fewer servers needed and the fact that the BEAM is open-source. Swapping from Ruby to Elixir Bleacher report managed to reduce their hardware requirements from 150 to just 8.


We will be an events partner with Fintech Week London again this year, hosting a special panel and networking evening at CodeNode in Central London on 12 July from 6 pm. Register your interest in attending via this link here.

The post Gaining a Competitive Advantage in Fintech From Your Choice of Tech Stack appeared first on Erlang Solutions.

by Michael Jaiyeola at June 27, 2022 16:46

The XMPP Standards Foundation

On-Boarding Experience with XSF (Converse)

Hi, I am PawBud. I will be working as a GSoC Contributor with XSF. To know more about my project kindly read this blog. Feel free to contact me through my email to ask me anything you want!

Before I start, I feel that some things that I am going to write in this blog might offend someone. Kindly note that these thoughts are my own. Once again you are free to contact me through my email if you have anything to say, I would be happy to hear your thoughts.

On-Boarding Experience with XSF & Community Bonding Period

Well, I must say, this is unlike any technical internship that you will experience. The level of attention and support that you will get from the organization admins and your project mentors from day 1 is genuinely surprising. I mean, I started having weekly calls with my mentor before the coding period even began, and I am still quite thankful that my mentor(s) spent their time to guide me. Believe it or not, as soon as the results were announced and I saw my name, my first reaction was “oops, well this is bad”. I wasn’t ready for it! Meeting JC (my primary mentor) definitely helped me a lot during the community bonding period. Turns out not everyone does feel the same (thanks to Patiga, I knew about this). Still, from my past experience in internships, I do believe that self-doubt is something that our present-day society profits from, and it is something that one can’t afford if one wants to improve.

I wanted to spend as much time with the source code as I could but my university exams did not allow me to do so. I managed to work on some minor issues though, but I still feel that I need to put in as much work as I can. As of writing this blog, it’s the second week of GSoC. I have to work on designing and implementing a UI for the jingle call modal and will hopefully be done with that and the tests, by the end of this week.

Why Choose GSoC & specifically XSF?

Ok, this is an interesting one, I still remember the special treatment I received from the whole community once the GSoC results were announced. I think Eddie instantly shared the results with the community through the XSF GSoC group chat, Twitter and a couple of other XSF social media pages. I genuinely feel pampered by the overwhelming support of the community, but I am so proud that I chose GSoC over a usual company internship.

I took a course on software engineering during my sophomore year, and until now I have never ever seen/experienced its concepts being implemented. In Converse, I learned more about the applications of test-driven software development in 2 weeks than I ever did during my whole semester. Turns out, that practising a technique is actually the best way to learn it. The fact that my mentor takes out his time which he could very easily spend on developing Converse, just to guide me through the smallest of obstructions, is what really makes this whole thing special. No manager or supervisor in any company is going to give you this kind of attention! Period.

There is this book called Zucked by Roger McNamee. For those of you who haven’t read it here is a gist:- Roger was one of the initial investors of Facebook and a mentor to Mark Zuckerberg. Throughout the book, he explains how Facebook turned into an evil giant, and how the guilt he feels that he could not stop Zuckerberg and Facebook from pivoting to its present-day state. My hate for social media giants like Instagram, Facebook and Twitter, started after I graduated from Secondary School, this was because I started watching a lot of technology-related youtube channels and understood how toxic these social media giants actually are and how they exploit human psychology by giving instant gratification, and blah blah blah. I must say, I was infuriated and disgusted that all this time, I was just a product of these social media giants.

That mentality has grown stronger over the years and yes, I am not on any social media except Reddit, which I occasionally use to text my friends. Hence, XSF was a no-brainer for me, plus I wanted to learn Javascript well, so I only submitted one proposal, which was for Converse.

This was a personal and a non-technical blog post. To be honest, I am still figuring out how to write blogs, as this is my first blog post. I think I will start writing more technical and project-related blog posts after this.

Acknowledgement

In conclusion, I would like to thank my Mentors (JC & Vanitas), Eddie (XSF GSoC Admin), Patiga (Co-contributor for XSF) and the whole XSF community for putting their trust in me. I would also like to take this opportunity to thank Zerefwayne & Yash Rathore for guiding me in the journey leading up to me getting selected as a contributor for XSF. I look forward to learning from all of you henceforth the GSoC period is finished.

For those of you who could not make it to GSoC with any organization including XSF

Remember, open source is not GSoC. I would honestly still contribute to various organizations, had I not gotten selected to GSoC, because it’s fun! Imagine writing code that is used by potentially millions of users daily. All those late-night hotfixes and mistakes that you do, do become good memories and of course, you get to learn a lot. The open source community is so friendly, that I have yet to see organizations that have core contributors who do not support newcomers.

GSoC should be a side goal in my opinion. If you get selected, that’s good for you. If you don’t get selected, you haven’t lost anything, you simply gain knowledge and contributions.

June 27, 2022 00:00

June 23, 2022

Ignite Realtime Blog

REST API Openfire plugin 1.8.1 released!

Earlier today, version 1.8.1 of the Openfire REST API plugin was released. This version removes the need to authenticate for status endpoints, adds new endpoints for bulk modifications of affiliations on MUC rooms, as well as a healthy number of other bugfixes.

The updated plugin should become available for download in your Openfire admin console in the course of the next few hours. Alternatively, you can download the plugin directly, from the plugin’s archive page .

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

by danc at June 23, 2022 13:09

June 22, 2022

Erlang Solutions

Contract Programming an Elixir approach – Part 1

This series explores the concepts found in Contract Programming and adapts them to the Elixir language. Erlang and BEAM languages, in general, are surrounded by philosophies like “fail fast”, “defensive programming”, and “offensive programming”, and contract programming can be a nice addition. The series is also available on Github.

You will find a lot of unconventional uses of Elixir. There are probably things you would not try in production, however, through the series, we will share some well-established Elixir libraries that already use contracts very well.

Programming by contract?

It is an approach to program verification that relies on the successful execution of statements; not that different from what we do with ExUnit when testing:

defmodule Program do
  def sum_all(numbers), do: Enum.sum(numbers)
end

ExUnit.start(autorun: false)

defmodule ProgramTest do
  use ExUnit.Case

  test "Result is the sum of all numbers" do
    assert Program.sum_all([-10, -5, 0, 5, 10]) == 0
  end

  test "Should be able to process ranges" do
    assert Program.sum_all(0..10) == 55
  end

  test "Passed in parameter should only be a list or range" do
    assert_raise Protocol.UndefinedError,
                 ~s(protocol Enumerable not implemented for "1 2 3" of type BitString),
                 fn -> Program.sum_all("1 2 3") end
  end

  test "All parameters must be of numeric value" do
    assert_raise ArithmeticError, ~s(bad argument in arithmetic expression), fn ->
      Program.sum_all([["1", "2", "3"]])
    end
  end
end

ExUnit.run()
....

Finished in 0.00 seconds (0.00s async, 0.00s sync)
4 tests, 0 failures

In the example above, we’re taking Program.sum_all/1 and verifying its behavior by giving it inputs and matching them with the outputs. In a sense, our function becomes a component that we can only inspect from the outside. Contract programming differs in that our assertions get embedded inside the components of our system. Let’s try to use the assert keyword within the program:

defmodule VerifiedProgram do
  use ExUnit.Case

  def sum_all(numbers) do
    assert is_list(numbers) || is_struct(numbers, Range),
           "Passed in parameter must be a list or range"

    result =
      Enum.reduce(numbers, 0, fn number, accumulator ->
        assert is_number(number), "Element #{inspect(number)} is not a number"
        accumulator + number
      end)

    assert is_number(result), "Result didn't return a number got #{inspect(result)}"
    result
  end
end

Our solution became a bit more verbose, but hopefully, we’re now able to extract the error points through evaluation:

VerifiedProgram.sum_all("1 2 3")
** (ExUnit.AssertionError) 

Passed in parameter must be a list or range
 
VerifiedProgram.sum_all(["1", "2", "3"])
** (ExUnit.AssertionError) 

Element "1" is not a number

This style of verification shifts the focus. Instead of just checking input/output, we’re now explicitly limiting the function reach. When something unexpected happens, we stop the program entirely to try to give a reasonable error.

This is how the concept of “contracts” works in a very basic sense.

How to run tests in contract programming

Having contracts in our codebase doesn’t mean that we can stop testing. We should still write them and maybe even reduce the scope of our checks:

defmodule VerifiedProgramTest do
  use ExUnit.Case

  test "Result is the sum of all numbers" do
    assert VerifiedProgram.sum_all(0..10) == 55
    assert VerifiedProgram.sum_all([-10, -5, 0, 5, 10]) == 0
    assert VerifiedProgram.sum_all([1.11, 2.22, 3.33]) == 6.66
  end
end

ExUnit.run()
.

Finished in 0.00 seconds (0.00s async, 0.00s sync)
1 test, 0 failures
 
By  using our functions in runtime or test-time we can re-align the expectations of our system components if requirements change:
# Now we expect this to work
VerifiedProgram.sum_all("1 2 3 4")
** (ExUnit.AssertionError) 

Passed in parameter must be a list or range

We also need to make the changes required for it to happen. In this case, we need to expand our domain to also include stringified numbers, separated by a space.

Should we add use ExUnit everywhere then?

As seen in the examples above, there’s nothing stopping us from trying the assert keyword. It is a creative way to verify our system components. However, I feel that the failures are designed in such a way as to be used in a test environment, not necessarily at runtime.

From the docs: “In general, a developer will want to use the general assert macro in tests. This macro introspects your code and provides good reporting whenever there is a failure.“Thankfully for us, in Elixir, we have a more primitive mechanism in which we can assert data in an effective way: pattern matching. I would like to explore this more in-depth in the second installment of this contract series.

Main takeaways

  • Contract programming is a technique for program verification that can be applied in Elixir.
  • Similar to testing, we’re not limited to only verifying at test time.
  • We embedded assertions within our code to check for failures.
  • Although not endorsed, we may take advantage of ExUnit to do contracts in Elixir.
  • Other mechanisms native to Erlang and Elixir may be used to achieve similar results.

More info on contracts

About the author

While on a desk Raúl spends time as an elixir programmer, still distilling some thoughts on the topic of “contract programming”; otherwise he’s a recent dad, enjoys simulation games and trying out traditional food. He operates from Tijuana, México from where he was born and lives.

The post Contract Programming an Elixir approach – Part 1 appeared first on Erlang Solutions.

by Raul Chouza at June 22, 2022 10:32

June 21, 2022

ProcessOne

Announcing ejabberd DEB and RPM Repositories

Today, we are happy to announce our official Linux packages repository: a source of .deb and .rpm packages for ejabberd Community Server. This repository provides a new way for the community to install and upgrade ejabberd.

All details on how to set this up are described on the dedicated website:
https://repo.process-one.net

ejabberd installation log

What packages are available?

Currently, the latest DEB and RPM packages are available for the open-source ejabberd version (eCS 22.05). New versions will be published as they’re released to https://repo.process-one.net.

Which platforms are currently supported?

The DEB and RPM packages currently target popular amd64 and arm64 systems. So if you are using Debian or centOS you should be fine. If your platform is not in this list, you can open an issue on Github describing which platform you would like to be added.

We aim to expand the support to other widely adopted architectures and platforms in the future.

What is next?

In addition to providing packages for ejabberd for upcoming releases, as well as expanding distribution and architecture support, we will make improvements to this official repository. Away from prying eyes, we’ve been studying the possibility to make ejabberd’s installers (.deb, .rpm, .run) directly on Github below each Release and that’s now the case! You can check them here now.

We’re looking forward to the community feedback on these packages to provide the best possible experience. Feel free to get in touch if needed!

The post Announcing ejabberd DEB and RPM Repositories first appeared on ProcessOne.

by Adrien at June 21, 2022 13:28

ejabberd 22.05

A new ejabberd release is finally here! ejabberd 22.05 includes five months of work, 200 commits, including many improvements (MQTT, MUC, PubSub, …) and bug fixes.

ejabberd 22.05 released
– Improved MQTT, MUC, and ConverseJS integration
– New installers and container
– Support Erlang/OTP 25

When upgrading from the previous version please notice: there are minor changes in SQL schemas, the included rebar and rebar3 binaries require Erlang/OTP 22 or higher, and make rel uses different paths. There are no breaking changes in configuration, and only one change in commands API.

A more detailed explanation of those topics and other features:

New Indexes in SQL for MUC

Two new indexes were added to optimize MUC. Those indexes can be added in the database before upgrading to 22.05, that will not affect older versions.

To update an existing database, depending on the schema used to create it:

  • MySQL (mysql.sql or mysql.new.sql):
CREATE INDEX i_muc_room_host_created_at ON muc_room(host(75), created_at);
CREATE INDEX i_muc_room_subscribers_jid USING BTREE ON muc_room_subscribers(jid);
  • PostgreSQL (pg.sql or pg.new.sql):
CREATE INDEX i_muc_room_host_created_at ON muc_room USING btree (host, created_at);
CREATE INDEX i_muc_room_subscribers_jid ON muc_room_subscribers USING btree (jid);
  • SQLite (lite.sql or lite.new.sql):
CREATE INDEX i_muc_room_host_created_at ON muc_room (host, created_at);
CREATE INDEX i_muc_room_subscribers_jid ON muc_room_subscribers(jid);
  • MS SQL (mssql.sql):
CREATE INDEX [muc_room_host_created_at] ON [muc_registered] (host, nick)
    WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON);
CREATE INDEX [muc_room_subscribers_jid] ON [muc_room_subscribers] (jid);

Fixes in PostgreSQL New Schema

If you moved your PostgreSQL database from old to new schema using mod_admin_update_sql or the update_sql API command, be aware that those methods forgot to perform some updates.

To fix an existing PostgreSQL database schema, apply those changes manually:

ALTER TABLE archive DROP CONSTRAINT i_archive_sh_peer;
ALTER TABLE archive DROP CONSTRAINT i_archive_sh_bare_peer;
CREATE INDEX i_archive_sh_username_peer ON archive USING btree (server_host, username, peer);
CREATE INDEX i_archive_sh_username_bare_peer ON archive USING btree (server_host, username, bare_peer);

DROP TABLE carboncopy;

ALTER TABLE push_session DROP CONSTRAINT i_push_session_susn;
CREATE UNIQUE INDEX i_push_session_susn ON push_session USING btree (server_host, username, service, node);

ALTER TABLE mix_pam DROP CONSTRAINT i_mix_pam;
ALTER TABLE mix_pam DROP CONSTRAINT i_mix_pam_us;
CREATE UNIQUE INDEX i_mix_pam ON mix_pam (username, server_host, channel, service);
CREATE INDEX i_mix_pam_us ON mix_pam (username, server_host);

ALTER TABLE route DROP CONSTRAINT i_route;
CREATE UNIQUE INDEX i_route ON route USING btree (domain, server_host, node, pid);

ALTER TABLE mqtt_pub DROP CONSTRAINT i_mqtt_topic;
CREATE UNIQUE INDEX i_mqtt_topic_server ON mqtt_pub (topic, server_host);

API Changes

The oauth_revoke_token API command has changed its returned result. Check oauth_revoke_token documentation.

API Batch Alternatives

If you use the command delete_old_messages periodically and noticed it can bring your system to an undesirable state with high CPU and memory consumption…

Now you can use delete_old_messages_batch, which performs the operation in batches, by setting the number of messages to delete per batch and the desired rate of messages to delete per minute.

Two companion commands are added: delete_old_messages_status to check the status of the batch operation, and abort_delete_old_messages to abort the batch process.

There are also new equivalent commands to delete old MAM messages.

Erlang/OTP and Elixir

From now, Erlang/OTP 25 is supported. As that’s a brand new version, for stable deployments you may prefer to use 24.3 or other lower version.

Notice that ejabberd can be compiled with Erlang as old as 19.3, but the rebar and rebar3 binaries included with ejabberd 22.05 require at least Erlang 22. This means that, to compile ejabberd 22.05 with those tools using an Erlang version between 19.3 and 21.3, you should get yourself a compatible rebar/rebar3 binary. If your operating system doesn’t provide a suitable one, you can download the old ones: rebar from ejabberd 21.12 and rebar3 from ejabberd 21.12.

Regarding Elixir supported versions:

  • Elixir 1.4 or higher is supported for compilation, but:
  • Elixir 1.10 is required to build OTP releases (make rel and make dev)
  • Elixir 1.11 is required to run make relive
  • Elixir lower than 1.11.4 requires Erlang lower than 24 to build OTP releases

mod_conversejs

mod_conversejs was introduced in ejabberd 21.12 to serve a simple page for the Converse.js XMPP web browser client.

Several improvements in mod_conversejs now allow a simpler configuration, and more customization at the same time:

  • The options now support the @HOST@ keyword
  • The options now support auto, which uses local or remote Converse files
  • The Converse’s auth and register options are set based on ejabberd’s configuration
  • default_domain option now has @HOST@ as default value, not the first defined vhost
  • conversejs_options: New option to setup additional options for Converse
  • conversejs_resources: New option to serve converse.js files (no need to setup an additional web server)

For example, if you downloaded Converse, now you can setup WebSocket, mod_conversejs, and serve Converse without additional web server, in an encrypted port, as simple as:

listen:
  -
    port: 443
    module: ejabberd_http
    tls: true
    request_handlers:
      /websocket: ejabberd_http_ws
      /conversejs: mod_conversejs

modules:
  mod_conversejs:
    conversejs_resources: "/home/ejabberd/conversejs-9.0.0/package/dist"

With that configuration, Converse is available in https://localhost/conversejs

More details in the mod_conversejs documentation.

New Installers

For many years, the release of a new ejabberd source code package was accompanied with binary installers, built using InstallBuilder and CEAN, and available in the ProcessOne Downloads page.

Since this ejabberd 22.05, there are new installers that use a completely different build method:

  • they are built using the tools provided in PR 3781
  • they use the most recent stable dependencies
  • they are available for linux/amd64 and linux/arm64 architectures
  • they are built automatically using the Installers Workflow
  • for stable releases, they are available for download in the ejabberd GitHub Releases
  • they are built also for every commit in master branch, and available for download in the results of Installers Workflow
  • if the installer is ran by root, it installs in /opt/ejabberd* and setups systemd service
  • if ran by a regular user, it asks installation path

However, compared to the old installers, those new installers:

  • do not ask for domain: now you must edit ejabberd.yml and set the hosts option
  • do not register the first Jabber account and grant admin rights: you must do it yourself

Please give those new installers a try, and comment any problem, improvement or ideas.

New Container Image

In addition to the ejabberd/ecs Docker container image published in Docker Hub, there is a new container image published in ejabberd GitHub Packages.

Its usage is similar to the ejabberd/ecs image, with some benefits and changes worth noting:

  • it’s available for linux/amd64 and linux/arm64 architectures
  • it’s built also for master branch, in addition to the stable ejabberd releases
  • it includes less customizations to the base ejabberd compared to ejabberd/ecs
  • it stores data in /opt/ejabberd/ instead of /home/ejabberd/

See its documentation in CONTAINER.

If you used previous images from that GitHub Packages registry please note: until now they were identical to the ones in Docker Hub, but the new 22.05 image is slightly different: it stores data in /opt/ejabberd/ instead of /home/ejabberd/. You can update the paths to the container volumes in this new image, or switch to Docker Hub to continue using the old same images.

Source Code Package

Until now, the source code package available in the ProcessOne Downloads page was prepared manually together with the binary installers. Now all this is automated in GitHub, and the new source code package is simply the same one available in GitHub Tags.

The differences are:

  • instead of tgz it’s now named tar.gz
  • it contains the .gitignore file
  • it lacks the configure and aclocal.m4 files

The compilation instructions are slightly improved and moved to a separate file: COMPILE.md

New make relive

This new make relive is similar to ejabberdctl live, but without requiring to install or build an OTP release: compile and start ejabberd immediately!

Quickly put:

  • Prepare it with: ./autogen.sh && ./configure --with-rebar=./rebar3 && make
  • Or use this if you installed Elixir: ./autogen.sh && ./configure --with-rebar=mix && make
  • Start without installing (it recompiles when necessary): make relive
  • It stores config, database and logs in _build/relive/
  • There you can find the well-known script: _build/relive/ejabberdctl
  • In that erlang shell, recompile source code and reload at runtime: ejabberd_admin:update().

Please note, when make relive uses Elixir’s Mix instead of Rebar3, it requires Elixir 1.11.0 or higher.

New GitHub Workflows

As you may notice while reading these release notes, there are new github workflows to build and publish the new installers and the container images, in addition to the Common Tests suite.

The last added workflow is Runtime. The Runtime workflow ensures that ejabberd compiles with Erlang/OTP 19.3 up to 25, using rebar, rebar3 and several Elixir versions. It also checks an OTP release can be built, started, register an account, and stop ejabberd.

See its source code runtime.yml and its results.

If you have troubles compiling ejabberd, check if those results reproduce your problem, and also see the steps used to compile and start ejabberd using Ubuntu.

Translations Updates

The German, Portuguese, Portuguese (Brazil), Spanish and Catalan translations are updated and completed. The French translation was greatly improved and updated too.

Documentation Improvements

Some sections in the ejabberd Documentation are improved:

ChangeLog

Core

  • C2S: Don’t expect that socket will be available in c2s_terminated hook
  • Event handling process hook tracing
  • Guard against erlang:system_info(logical_processors) not always returning a number
  • domain_balancing: Allow for specifying type only, without specifying component_number

MQTT

  • Add TLS certificate authentication for MQTT connections
  • Fix login when generating client id, keep connection record (#3593)
  • Pass property name as expected in mqtt_codec (fixes login using MQTT 5)
  • Support MQTT subscriptions spread over the cluster (#3750)

MUC

  • Attach meta field with real jid to mucsub subscription events
  • Handle user removal
  • Stop empty MUC rooms 30 seconds after creation
  • default_room_options: Update options configurable
  • subscribe_room_many_max_users: New option in mod_muc_admin

mod_conversejs

  • Improved options to support @HOST@ and auto values
  • Set auth and register options based on ejabberd configuration
  • conversejs_options: New option
  • conversejs_resources: New option

PubSub

  • mod_pubsub: Allow for limiting item_expire value
  • mod_pubsub: Unsubscribe JID on whitelist removal
  • node_pep: Add config-node and multi-items features (#3714)

SQL

  • Improve compatibility with various db engine versions
  • Sync old-to-new schema script with reality (#3790)
  • Slight improvement in MSSQL testing support, but not yet complete

Other Modules

  • auth_jwt: Checking if an user is active in SM for a JWT authenticated user (#3795)
  • mod_configure: Implement Get List of Registered/Online Users from XEP-0133
  • mod_host_meta: New module to serve host-meta files, see XEP-0156
  • mod_mam: Store all mucsub notifications not only message notifications
  • mod_ping: Delete ping timer if resource is gone after the ping has been sent
  • mod_ping: Don’t send ping if resource is gone
  • mod_push: Fix notifications for pending sessions (XEP-0198)
  • mod_push: Keep push session ID on session resume
  • mod_shared_roster: Adjust special group cache size
  • mod_shared_roster: Normalize JID on unset_presence (#3752)
  • mod_stun_disco: Fix parsing of IPv6 listeners

Dependencies

  • autoconf: Supported from 2.59 to the new 2.71
  • fast_tls: Update to 1.1.14 to support OpenSSL 3
  • jiffy: Update to 1.1.1 to support Erlang/OTP 25.0-rc1
  • luerl: Update to 1.0.0, now available in hex.pm
  • lager: This dependency is used only when Erlang is older than 22
  • rebar2: Updated binary to work from Erlang/OTP 22 to 25
  • rebar3: Updated binary to work from Erlang/OTP 22 to 25
  • make update: Fix when used with rebar 3.18

Compile

  • mix release: Copy include/ files for ejabberd, deps and otp, in mix.exs
  • rebar3 release: Fix ERTS path in ejabberdctl
  • configure.ac: Set default ejabberd version number when not using git
  • mix.exs: Move some dependencies as optional
  • mix.exs: No need to use Distillery, Elixir has built-in support for OTP releases (#3788)
  • tools/make-binaries: New script for building Linux binaries
  • tools/make-installers: New script for building command line installers

Start

  • New make relive similar to ejabberdctl live without installing
  • ejabberdctl: Fix some warnings detected by ShellCheck
  • ejabberdctl: Mention in the help: etop, ping and started/stopped
  • make rel: Switch to paths: conf/, database/, logs/
  • mix.exs: Add -boot and -boot_var in ejabberdctl instead of adding vm.args
  • tools/captcha.sh: Fix some warnings detected by ShellCheck

Commands

  • Accept more types of ejabberdctl commands arguments as JSON-encoded
  • delete_old_mam_messages_batch: New command with rate limit
  • delete_old_messages_batch: New command with rate limit
  • get_room_occupants_number: Don’t request the whole MUC room state (#3684, #1964)
  • get_vcard: Add support for MUC room vCard
  • oauth_revoke_token: Add support to work with all backends
  • room_unused_*: Optimize commands in SQL by reusing created_at
  • rooms_unused_...: Let get_all_rooms handle global argument (#3726)
  • stop|restart: Terminate ejabberd_sm before everything else to ensure sessions closing (#3641)
  • subscribe_room_many: New command

Translations

  • Updated Catalan
  • Updated French
  • Updated German
  • Updated Portuguese
  • Updated Portuguese (Brazil)
  • Updated Spanish

Workflows

  • CI: Publish CT logs and Cover on failure to an external GH Pages repo
  • CI: Test shell scripts using ShellCheck (#3738)
  • Container: New workflow to build and publish containers
  • Installers: Add job to create draft release
  • Installers: New workflow to build binary packages
  • Runtime: New workflow to test compilation, rel, starting and ejabberdctl

Full Changelog

All changes between 21.12 and 22.05

ejabberd 22.05 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub.

The source package and installers are now available in GitHub Release / Tags. To check the *.asc signature files, see How to verify ProcessOne downloads integrity.

The Docker image is in Docker Hub, and a new Container image at GitHub Packages.

If you suspect that you’ve found a bug, please search or fill a bug report on GitHub Issues.

The post ejabberd 22.05 first appeared on ProcessOne.

by Jérôme Sautret at June 21, 2022 13:27