iOS 4.8 beta is in review for testflight but the mac one is available now.

Monal 4.8 will be another huge update and the iOS beta should be available soon. Monal is actively being translated a variety of different languages. You can contribute too. In addition thanks to Thilo, the notifications have been improved to show the previews again in iOS 13 like they did in iOS 12. There are a massive number of changes in 4.8 that will need testing. Please provide feedback if you encounter issues especially with notifications.

We need as many testers as we can get for this, if you want to test Monal iOS beta anyone can use testflight to access the new builds before they go to the app store.

Our free , public XMPP installation: xmpp.cloud is packed with features: domain hosting, file uploads, TURN/STUN server for your audio/video calls, high availability due to running as a cluster with automatic recovery and all of this while scoring 100% XMPP compliance and perfect A grade in a popular test tools. And now it got even better !

Group chat - the problem

For a very, very long time MUC (defined in XEP-0045: Multi-User Chat ) was the only option available in XMPP realm that allowed people to exchange messages in a group. At the beginning, when it was typical to have constant connection to the server, everything was working just fine, but over the course of time new challenges arose. People started to use more and more their mobile devices and connections to the server became anything but permanent (be that because of spotty internet connection or limitations imposed by mobile device manufacturer). In that environment MUC started to show it’s architectural problems: if you are not connected you are not an occupant of the MUC room and therefore you don’t receive any messages. This was a problem!

Previous attempts to improve the situation

There a couple of attempts to mitigate this situation: XEP-0410: MUC Self-Ping (Schrödinger’s Chat) for the situations where federation link would get broken and user would be unaware that it’s not in a room anymore, Multi-User Chat Light , which would allow to permanently register to the room without presence or vendor specific non XSF variations of “MUC subscription”. There were also workarounds with with long-lived user sessions (terminating underlying network connection without closing XML stream) that were quite inefficient.

What is XMPP MIX

MIX stands for Mediated Information eXchange (MIX) and it’s basics are defined in XEP-0369: Mediated Information eXchange (MIX) :

“an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provide human group communication and communication between non-human entities using channels, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). MIX uses Publish-Subscribe to provide flexible access and publication, and uses Message Archive Management (MAM) to provide storage and archiving.”

Specification outlines several requirements of which those seems to be the most interesting:

• “A user’s participation in a channel persists and is not modified by the user’s client going online and offline.”
• “Multiple devices associated with the same account can share the same nick in the channel, with well-defined rules making each client individually addressable.”
• “A reconnecting client can quickly resync with respect to messages and presence.”

MIX itself serves as an umbrella for set of MIX-related XMPP extensions that specify the exact protocol. Two of them are required for the implementation to be considered as MIX compliant:

• MIX-CORE defined in XEP-0369: Mediated Information eXchange (MIX) - “sets out requirements addressed by MIX and general MIX concepts and framework. It defines joining channels and associated participant management. It defines discovery and sharing of MIX channels and information about them. It defines use of MIX to share messages with channel participants.”
• MIX-PAM defined in XEP-0405: Mediated Information eXchange (MIX): Participant Server Requirements - “defines how a server supporting MIX clients behaves, to support servers implementing MIX-CORE and MIX-PRESENCE.”

In addition to the above extensions, there are several other that are optional:

• MIX-PRESENCE defined in XEP-0403: Mediated Information eXchange (MIX): Presence Support - adds the ability for MIX online clients to share presence, so that this can be seen by other MIX clients. It also specifies relay of IQ stanzas through a channel.
• MIX-ADMIN defined in XEP-0406: Mediated Information eXchange (MIX): MIX Administration - specifies MIX configuration and administration of MIX.
• MIX-ANON defined in XEP-0404: Mediated Information eXchange (MIX): JID Hidden Channels - specifies a mechanism to hide real JIDs from MIX clients and related privacy controls. It also specifies private messages.
• MIX-MISC defined in XEP-0407: Mediated Information eXchange (MIX): Miscellaneous Capabilities - specifies a number of small MIX capabilities which are useful but do not need to be a part of MIX-CORE: handling avatars, registration of nickname, retracting of a message, sharing information about channel and inviting people, converting simple chat to a channel.
• MIX-MUC defined in XEP-0408: Mediated Information eXchange (MIX): Co-existence with MUC - defines how MIX and MUC can be used together.

How does it work?

The most stark difference to MUC is that MIX requires support from both server that hosts the channel and user’s server. This is done to facilitate the notion that the user (and not particular connection or client application) joined the group and allows for greater flexibility in terms of message delivery (which can be send to one or many connections, or even generates notification over PUSH). Another important difference is the flexibility to choose which notifications from the channel user wants to receive (that can be messages, presence, participators or node information).In the most basic approach, when user decides to join a channel, it sends an IQ stanza to it’s own local server indicating address of the desired channel and list of MIX nodes to which it wants to subscribe. User’s server then forward’s subscription request to the destination, MIX server. As a result user receives subscription confirmation and from this point onwards will receive notifications from the channel, independently of it’s current network connection.Another essential bit of MIX is the reliance on XEP-0313: Message Archive Management to control message history and the complementary interaction between MIX server and user’s server. Main channel history is handled by the MIX server, but user’s that joined the channel will retrieve and synchronise message history querying their local server, which will maintain complete history of the channels that user has joined (based on the received notifications). This also means that even if the channel is removed, user is still able to access it’s history through local MAM archive (limited to time when user was member of the channel).As a result, chatter between client, client’s server and mix server is also reduced and unnecessary traffic is eliminated.

Benefits for mobile-first applications relying on push

All of this helps especially with clients that relay on constrained environment - be that unreliable network connection or operating system that limits time that application can be running. Because there is no dependency on the dynamic state of user presence/connection the issue with occupant leaving and (re)joining the room is eliminated - user gets the notification always. What’s more, thanks to shared responsibilities between MIX and user’s server, and the latter getting all notifications from MIX channel, it’s possible to generate notifications without relaying on workarounds (that most of the time are not reliable or impact resource usage).

In case of Tigase XMPP server it gets better thanks to our experimental filtering groupchat notifications feature, which allows user controll when to receive PUSH notifications from group chats (always, only when mentioned or never)

Is MUC obsolete?

We think that MIX is the way forward, but we also know that this won’t happen overnight. Because of that MUC is still supported in all our applications and Tigase XMPP Server implements XEP-0408: Mediated Information eXchange (MIX): Co-existence with MUC to allow all non-MIX client to participate in MIX channel discussions using MUC protocol.

Tigase xmpp.cloud service with MIX support

Our xmpp.cloud installation offers MIX today! It supports MIX-CORE, MIX-PAM (with MAM), MIX-ADMIN, MIX-MUC, MUX-MISC (message retraction)

For now, neither MIX-PRESENCE (we only inform about channel participants without explicit publication their presence) nor MIX-ANON (there is only support for ‘private messages’) are available.

How to use it

First of all - you need an XMPP client that supports MIX, for now this is limited to BeagleIM for macOS and SiskinIM for iOS. Creating and joining channel is not different to joining MUC room:

1. select open channel :

1. fill out the form:

1. start chatting!

Other benefits of xmpp.cloud

As mentioned at the beginning of this article, in addition to MIX, xmpp.cloud offers a lot:

• never worry about server downtime - it’s a clustered installation, which means that at every point in time there will always be at least one server to connect to
• host your own domain for free - it’s enough to point your domain’s DNS SRV records to tigase.me and add it in xmpp.cloud system (as described in the documentation )
• better PUSH for your mobile devices - more granular configuration and encrypted notifications
• anti-SPAM mechanism to squash unwanted messages
• free audio/video server (STUN/TURN) for you calling needs
• perfect A security grade:
• 100% XMPP compliance

The Ignite Realtime community is happy to announce the availability of Spark version 2.9.0!

Note that this version has a lot of changes, especially in certificates management area. We suggest to first test it on a small batch of test machines before deploying it to all users.

2.9.0 was long time in the making, so the list of changes is rather long. To mention a few: a new certificate management system that was long overdue, migration to Maven (instead of Ant), HTTP File Upload plugin support, new Smack library version and many other bug fixes and improvements.

A few plugins are currently not working because they use old libraries not available for Maven: Spellchecker, OTR. During the poll on this website most users told us that they are not using these plugins.

We are thankful to all the contributors and Google Summer of Code students who provided their patches to help us release this version. And we encourage developers to get involved with Spark project by providing feedback in the forums or submitting pull requests on our GitHub page.

Here is the list of contributors to this release:
@guus
@Alameyo
Michael Klein
@speedy
@flow
@Dele_Olajide
Alexander198961
Manassé Ngudia
@wroot
Grigorii
Vipin Raj

You can download Spark from the Downloads page. Below are the sha1 checksums:

73d30728b216440667e6741373def5aba0088f84  spark-2.9.0.rpmf1b997a401fa71f06b77633ce0161c46ac4e8eab  spark_2_9_0-with-jre.dmg4097a34d255556c5f8b60f77cd83bfda7bbe3c8a  spark_2_9_0-with-jre.exe6230c8f3fc3042448028a7186c8c277dda45d81b  spark_2_9_0.deb117ba72f48132afbfa20b1adf7cd5193879456c7  spark_2_9_0.dmg640d1fe1682830adb3ff6a9a8eede20f3ce2ba8a  spark_2_9_0.exe4f0bc7abb0f0131dd325cb3363255f668bd7fe0f  spark_2_9_0.tar.gz

For other release announcements and news follow us on Twitter

3 posts - 3 participants

Read full topic

The Ignite Realtime community is happy to announce the immediate release of version 2.1.5 of the Client Control plugin for Openfire!

This update adds a new setting for a newly released 2.9.0 version of Spark, changes one setting’s behavior, adds a Russian translation and fixes a few issues.

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

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

The Ignite Realtime Community is pleased to announce the release of Openfire version 4.5.3. We wanted to make one final bug fix release of the 4.5.x series of Openfire before a final 4.6.0 is made soon. You can find a listing of bug fixed within our changelog .

Download artifacts are available here and have the following sha1sum values:

82b41141c5f9c5139606c1de879c9e5f546060b7  openfire-4.5.3-1.i686.rpm178d6fb4c8c65a6e1dc88daf75f1599634cd14cf  openfire-4.5.3-1.noarch.rpme2342b8aabfa28ba927ac7bbc24d2a19bb095574  openfire-4.5.3-1.x86_64.rpm0b79b5fdc92c73ec0b016b20cf8ea5a14fc2d771  openfire_4.5.3_all.debe869f49dd5c28587406ee5233c68fe75271c2855  openfire_4_5_3_bundledJRE.execb95afc6b8e1738d085124b95765e0bcdc26117c  openfire_4_5_3_bundledJRE_x64.exec9c728013f9fbd59e6d353542f5c1dcc685fcf93  openfire_4_5_3.dmg92848fe42acfe515e22a9b13861bded7dd65b568  openfire_4_5_3.exe7e873e0a3f78d8025cbebb117fbd259837429bf5  openfire_4_5_3.tar.gz82c2a432102ab457f2943b1ca55b25ad0797e9ff  openfire_4_5_3_x64.exe638fecb2b9c423275ad0ca79b6d6084836df0d82  openfire_4_5_3.zip44bc28c159a039aa054c559390a47e6d0345f105  openfire_src_4_5_3.tar.gzf617a5001874475c7edea3cb90be64fffefbdbe5  openfire_src_4_5_3.zip

Thanks for your interest in Openfire.

1 post - 1 participant

Read full topic

We have an implementation for translations on Weblate now! The first big languages are added. We are happy for your contributions.

Link:

https://hosted.weblate.org/access/monal/

This release brings an automatic update check for Gajim on Windows/MacOS, a big status message overhaul, and many improvements.

What’s New

Starting with this release, Gajim features an automatic update check on Windows/MacOS. If you enable it, Gajim will search for updates once a week. As soon as a new version is available, you will get a notification offering to download the latest release.

Over time, Gajim grew a lot of options to set up status messages, and it became cluttered at some point. We decided to do some cleanup, and started by removing ‘default status messages’ (default message for each status) in favor of status presets. An example: you choose to go ‘away’ (your daily walk). Instead of typing your status message each time, you simply select a status preset. A status preset can also include your Activity ( XEP-0108 ) or even your Mood ( XEP-0107 ). Removing a status preset is now possible from the status change window, further reducing the Preferences settings count. While reworking the status change window, we took the opportunity to improve Gajim’s status selector as well. Depending on where the contact list was placed on your desktop, the old status selector would sometimes not open correctly. We fixed this bug and also improved the layout a bit. Cleaning up the status message logic inside Gajim also lead to the removal of the ‘Free for Chat’ status option, because it is essentially Online/Available nowadays.

New status window

More Changes

• Server Info window now shows which IP/Port and DNS record are in use
• Preferences: Keyring (password storage) can now be disabled
• Password storage with Gajim from Flatpak now works with kwallet
• XHTML: Support for <img> tags has been removed
• DBus: ability to change settings has been removed
• Connection: ability to ignore TLS errors has been removed
• Support for drag and drop from KDE notifications (and other elements) has been added
• HiDPI improvements for the group chat participants list
• A bug has been fixed where Gajim would fail to connect after suspend
• And much more: Have a look at the full changelog

Known Issues

• Zeroconf (serverless messaging) has not been re-implemented yet
• Client certificate setup is not possible yet
• Some work has been done to get Audio/Video calls working again, however, this feature is highly experimental at the moment

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

Since the last update, I have been able to implement cursor support for real-time text, support for multiple devices, and started with MUC implementation.

Cursor Support

Since with the support of wait action elements, the received real-time texts are processed and displayed more realistically; keeping the typing patterns of the peer, the next step was to implement cursor support to display where the changes are taking place.

Implementing this was pretty straightforward, just insert | character in the latest position in the label and remove the old one if present.

Support for Multiple Devices

With multiple device support, if a user is using multiple instances of Dino in separate devices then whatever is that they are typing in chat input will be synced with the other clients. This means that a user can start composing their text in one device and finish it in other.

This is done by checking if the bare JID of user account and the bare JID of message carbon stanza is the same for single user chat or by checking the resourcepart in case of MUCs. If the condition passes then just update the text input buffer with the rtt instead of creating an rtt element on the conversation view.

I faced two problems while implementing this:

First: I was using different conversations (conversation with peer JID and conversation with the same account JID) to store and retrieve action elements from Hash-Map.

Second: The chat input kept on updating in a loop for both the clients. The reason was that RTT generation is tied with updation of text input. So syncing text input resulted in the transmission of RTT which updated text input in other clients and so on the loop continued. This was resolved by using a bool variable, which does not let RTT generation in this scenario.

MUC support

For MUC only 3 Real-Time Text widgets would be displayed at a time. This is done to ensure that in case of highly active MUCs with multiple people typing at a time it does not cause any problems with user experience and to keep the UI clean and free of clutter.

If there are already more than three RTT widgets present then the priority of the new incoming RTT and the previous ones present is checked on the basis on MUC affiliation with the owner having a greater priority than admins and so on.

Other than that I resolved for removing typing notifications for those whose RTT is being displayed.