There have been two outages to the push server in the last two days. We are working on identifying the issue. It is related to some new code we are using that allows text and image previews in messages the Monal 4.8 rolls out. I apologize for the inconvenience the end result will hopefully make it worth it.

🥳 This month’s post marks one year of Gajim Development News! The rework of Gajim’s Preferences window has been completed. We improved group chat invitations and made group chat settings easier to access. Also, joining a group chat is now much prettier.

Changes in Gajim

After reworking Gajim’s configuration backend, it was time to redesign the Preferences window. During this month, a lot of work went into improving the settings framework, which will simplify coding and reduce the amount of code necessary to add new settings. Many of these changes won’t become visible instantly, but they will help future development.

Gajim’s Notification settings for event handling have been split up. You can now decide if you want notifications to be shown in general, and if you want new message to be opened directly (without a notification icon in the contact list). All settings around sending Chat States (e.g. ‘Composing…') have been moved from the Preferences window to the Accounts window, completing the migration of account-related settings. These are just a few of many improvements which you’ll discover in the next release. These changes should make it easier for you to handle all of Gajim’s configuration possiblities.

Gajim’s new Preferences window

Gajim uses a ‘Sync Threshold’ setting to decide how many messages should be synchronized when joining a chat. If you set a custom Sync Threshold, please make sure to check the setting after upgrading Gajim, since it could not be migrated.

Receiving a group chat invitation can sometimes be ambiguous. ‘ Do I really want to join this chat, or should I decline the invitation? ’ In order for you to make an informed decision, Gajim now shows some information about the chat (group chat’s picture, name, and description) before joining. Furthermore, many people want to join public group chats using a different nickname from the one they use for private group chats. Gajim now offers to choose a nickname directly before joining.

The new Group Chat Invitation window

You already now that many group chat actions (for example Information, Change Nickname…) are shown on group chat ‘pages’. Group chat settings (e.g. Minimize on Close, Show Status Changes) are now organized on a new settings page. This reduces the menu layers needed to click through until you reached the setting you wanted to change, and it also puts all settings in a single place for a better overview.

By default, Gajim will keep your chat history forever. However, if you want to cleanup your chat history from time to time, Gajim now offers to automatically reduce the amount of baggage you’re carrying with you. Of course it’s you who decides for how long Gajim should keep your chat history.

Gajim’s features (protocol extensions, called XEPs) are now listed on gajim.org/support/extensions . The table is automatically generated from Gajim’s DOAP (Description of a Project) file, which reduces the amount of maintenance significantly.

What else happened

• A/V menu entries are now updated (enabled/disabled) correctly when receiving the contact’s capabilities
• If Gajim fails to join a group chat, it now offers a Retry button (and also ‘Forget Group Chat’)
• When pasting images from the clipboard, a preview is shown before sending
• A ‘Send message’ button is now available for chat windows
• Notification for contact sign in/out has been removed
• VCard and Avatar publishing code has been reworked
• A bug has been fixed where the notification icon would stay after blocking/reporting someone who sent you a subscription request and a message ( #10264 )
• There have been speed improvements for SQLite operations concerning chat message processing ( #10027 )
• Escape key will not close chat windows by default in the future
• Some shortcuts now use Primary (Ctrl/Cmd) instead of Alt (which is often used by Window Management): Change Subject ( <Primary><Shift>S ), Emoji Chooser ( <Primary><Shift>M )

Plugin updates

Gajim’s URL Image Preview is now able to preview audio files. If you receive a voice message, you can play it directly from within the chat window. The Syntax Highlighter plugin now features a ‘Paste as Code’/‘Paste as Code Block’ entry for the chat input. ‘Paste as Code’ will surround the text you paste with backticks, which enables syntax highlighting.

Each chat message shows a little green shield icon if it is encrypted. Colors for these icons have been unified between OMEMO, OpenPGP, and incoming/outgoing messages. Additionally, some issues have been resolved with Gajim’s PGP/OpenPGP plugins on Flatpak.

Changes in python-nbxmpp

Support for VCard Temp ( XEP-0054 ) has been added. Furthermore, the code for VCard and Avatar publishing has been reworked. Tasks (using Python Generators) have been introduced, which should simplify the flow of many operations in the future. So far, Pubsub, Avatars, and Discovery are using Tasks.

As always, feel free to join gajim@conference.gajim.org to discuss with us.

Publishing and Subscribing with Halcyon

As you recall, Halcyon is multiplatform XMPP library written in Kotlin. In a previous article: “A look at Halcyon” we had a look at basic concepts in library and we created a simple client.

This time we will dive into more complex stuff. We will create simple solution to monitoring temperature at home :-) In this article we will not focus on measuring temperature. We will create a command-line tool to publish temperature provided as parameter.

First letter in XMPP acronym is from the word “eXtensible”. There is a lot of extensions for the XMPP protocol. One of them is XEP-0060: Publish-Subscribe - specification for publish-subscribe functionality. We will use it to create our temperature monitor.

You need to use XMPP Server with PubSub component. You can use your deployment (for example Tigase XMPP Server or use one of the publicly available servers, for example sure.im and its PubSub component pubsub.sure.im . A PubSub node with unique name (to avoid conflicts) will have to be created in the PubSub component. Please note that node created with default configuration is open, which means that everyone can subscribe to it (but only you will be able to publish data there).

Data structure

First of all we have to create data structure. In our case, it will be as simple as possible:

<temperaturetimestamp="1597946187562">23.8</temperature>

timestamp is time represented as a number of milliseconds after January 1, 1970 00:00:00 GMT.

We can use DSL (defined in Halcyon) to create such XML fragment:

val payload =element("temperature"){    attributes["timestamp"]=(Date()).time.toString()+temperature.toString()}

Publisher

Publisher is a simple XMPP client that connects to the server, sends information to PubSub component and immediately disconnects.

First of all, lets define global values to keep node name and PubSUB JID:

val PUBSUB_JID ="pubsub.tigase.org".toJID()val PUBSUB_NODE ="temperature_in_my_house"

It cannot be called a good practice, but is good enough for us right now :-)

In the previous article we explained how to create a simple client. Now we will focus on PubSubModule . This module allows publishing and receiving events as well as managing PubSub nodes and subscriptions.

This is the main code that publishes events:

pubSubModule.publish(PUBSUB_JID, PUBSUB_NODE,null, payload).handle{    success { request, iq, result ->println("YAY! Published with id=${result!!.id}")}    error { request, iq, errorCondition, s ->        System.err.println("ERROR $errorCondition! $s")}}.send()

But what if the PubSub node doesn’t exist (e.g. it wasn’t created yet)? It’s simple: we have to create it using method create() :

pubSubModule.create(PUBSUB_JID, PUBSUB_NODE).handle{    success { _: IQRequest<Unit>, _: IQ, _: Unit?->println("Got it! Node created!")}    error { _: IQRequest<PubSubModule.PublishingInfo>, _: IQ?, errorCondition: ErrorCondition, msgs: String?->println("OOPS! Cannot create node $errorCondition$msgs")}}.send()

The question is: under what conditions we should call this part of code and automatically create the node? One of the possibilities would be moment when item publishing fails with error item-not-found .

pubSubModule.publish(PUBSUB_JID, PUBSUB_NODE,null, payload).handle{    success { request, iq, result ->println("YAY! Published with id=${result!!.id}")}    error { request, iq, errorCondition, s ->if(errorCondition == ErrorCondition.ItemNotFound){println("Node not found! We need to create it!")            pubSubModule.create(PUBSUB_JID, PUBSUB_NODE).handle{                success { _: IQRequest<Unit>, _: IQ, _: Unit?->println("Got it! Node created!")}                error { _: IQRequest<PubSubModule.PublishingInfo>, _: IQ?, errorCondition: ErrorCondition, msgs: String?->println("OOPS! Cannot create node $errorCondition$msgs")}}.send()}else System.err.println("ERROR $errorCondition! $s")}}.send()

To simplify the code, publishing will not be repeated after node creation.

It is good to use client.waitForAllResponses() before disconnect() , to not break connection before all responses comes back.

Listener

Listener is also a client (it should works on different account) that subscribes to receiving events from specific nodes of PubSub component. PubSub items received by PubSubModule are distributed in the client as PubSubEventReceivedEvent in Event Bus. To receive those events you have to register an events listener:

client.eventBus.register<PubSubEventReceivedEvent>(PubSubEventReceivedEvent.TYPE){if(it.pubSubJID == PUBSUB_JID && it.nodeName == PUBSUB_NODE){        it.items.forEach{ item ->val publishedContent = item.getFirstChild("temperature")!!val date =Date(publishedContent.attributes["timestamp"]!!.toLong())val value = publishedContent.value!!println("Received update: $date :: $value°C")}}}

Note, that this listener will be called on every received PubSub event (like OMEMO keys distribution, PEP events, etc). That’s why you need to check node name and JabberID of PubSub component.

Your client will not receive anything from PubSub if it does not subscribe to specific node. Because subscription is persistent (at least with default node configuration), client doesn’t need to subscribe every time it connects to the server. Though, it should be able to check if it’s subscribed to the specific node or not. For that, you need to retrieve list of subscribers and see if the JabberID of the client is on the list:

val myOwnJID = client.getModule<BindModule>(BindModule.TYPE)!!.boundJID!!pubSubModule.retrieveSubscriptions(PUBSUB_JID, PUBSUB_NODE).response{if(!it.get()!!.any{ subscription -> subscription.jid.bareJID == myOwnJID.bareJID }){println("We have to subscribe")        pubSubModule.subscribe(PUBSUB_JID, PUBSUB_NODE, myOwnJID).send()}}.send()

NOTE: In this example we intentionally skipped checking response errors.

PubSub component can keep some history of published elements. We can retrieve that list easily:

pubSubModule.retrieveItem(PUBSUB_JID, PUBSUB_NODE).response{when(it){is IQResult.Success ->{println("Previously published temperatures:")            it.get()!!.items.forEach{val date =Date(it.content!!.attributes["timestamp"]!!.toLong())val value = it.content!!.value!!println(" - $date :: $value°C")}}is IQResult.Error ->println("OOPS! Error "+ it.error)}}.send()

Length of the history is defined in node configuration.

Sample output

Submitting new temperature in Publisher …:

yields receiving notifications in Listener :

Summary

We presented a simple way to create a PubSub publisher and consumer. You can extend it: for example you can run publisher on Raspberry Pi connected to some meteo-sensors. Possible applications of PubSub component are limited only by your imagination.

All source codes for this article can be found in GitHub repository .

In preparation for Monal 4.8, the push server has been upgraded. In addition to the usual fixes that come with a software update in this case, people using the Monal 4.8 beta should now see a single notification for every message that comes in with the message text in the notification. For those of you who used Monal in iOS 12 this will be very familiar. This should be functionally similar to how things were in iOS 12. Sorry this took so long, huge thanks to Thilo for doing the heavy lifting here and implementing both the server and the iOS extension that powers this.

The Ignite Realtime community is happy to announce that version 2.1.0 of the Monitoring plugin has been released!

This release is mainly a bugfix release. Message archiving functionality has been improved (fixes have been applied for both XEP-0136 and XEP-0313), full text search has been added to the personal message archives of users, and a variety of smaller bug fixes have been applied.

In this release, the feature of retrieving messages ‘out of order’ has been removed.

The new version of the plugin will become available for installation in the admin console of your instance of Openfire in the next few hours. Alternatively, it can be downloaded from its archive page right now.

Note that for instances that have a lot of archived messages in their database, the initial load of this plugin might require a significant amount of time, as some database updates will be executed. For reference: it took our test instance, that has approximately 11 million archived messages in an external database approximately 9 minutes to perform this update.

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic