Planet Jabber

June 30, 2020

Anmol Chaudhary

User Interface

It’s been two weeks since my last blog post update, so there’s a lot of ground to cover here regarding my progress.

First of all the good news is that Real-Time Texting is working well now. Until last time I was using debug mode to view the incoming RTT as there was no user interface for that; since then I worked on a UI to display those incoming rtt messages. There were also a few minor bugs in both sending and receiving that sometimes led to the incorrect deletion of texts. These bugs have now been addressed. The third thing was to make sending compatible with multiple conversations at a time rather than a single conversation with that I also refactored some of the code to make it fit better with Dino’s codebase.

UI:

For the user interface, I did something similar to the already existing chat state items that are used to display the typing notification. Since in a MUC setting there can be several real-time texts from multiple users, therefore these items are kept stored in a hash map against their JID; to update them individually based on the new rtt received, or delete them if either the message body is received or the event received is reset or new.

Initially, when the UI was implemented, it didn’t work all the time or it completely froze the entire application especially when typing fast. Turns out as pointed by Marvin that I was updating the UI frequently even when there was no incoming RTT. This was quickly resolved by using Idle.add() instead of Timeout.add(). As the name suggests Timeout updated the UI every fixed interval (and that interval needed to be short so as to display the incoming real-time texts in “real time”), but this led to UI freezes. Idle only calls a function when there are no high priority events left to be executed in the default main loop and so this leads to the RTT UI elements updating frequently with no clashes with other high priority events.

There still may be some work related to the visual presentation that may need to be done in the UI department, maybe with some nice animation in transition between real-time text and actual message; and I reckon that UI for MUC would be another challenge as it will involve a seamless transition between several RTT UI elements.

Bug Fixes:

Even though sending and receiving were working fine most of the time, there were a few bugs present that made either sending the wrong action element or some edge case on the receiving side where the position was calculated incorrectly. This led to incorrect erasing of text. These issues were fixed and erasing text is now working flawlessly. Another issue was that if a was received as a prefix or suffix it was stripped in XML parsing and so sometimes spaces were not shown in the incoming rtt. This issue was resolved by Marvin and with that everything is working fine now.

Initially, I was thinking of generating action elements after every ‘n’ keystrokes or a combination of keystrokes with time, but now I discarded that and went with a purely timeout based approach as it’s working well. Generating action elements on basis of keystrokes also didn’t account for copy-pasting texts, but with a time-based approach, I’m now looking at changes in the buffer of input text field rather than keystrokes.

With that, a basic version of RTT is working perfectly (almost :p). Here’s a gif demonstrating it:

_config.yml

This week I look forward to implementing a toggle to enable/disable rtt for conversation. This will also involve accounting for cancel and init events.

June 30, 2020 00:00

June 28, 2020

Gajim

Development News June 2020

June already brought Gajim 1.2, python-nbxmpp 1.0, and many plugin updates. But there is more: Blind Trust Before Verification for OMEMO, drag and drop improvements, and a new translation service for Gajim.

Translations

Let’s start this post a little bit different by announcing an infrastructure update. In the past, translations for Gajim and gajim.org have been managed through Pootle, a web based translation software. Development on Pootle has been stalled for some time now, which made us look out for a replacement. Switching to Weblate brought us better quality checks, easier translation via string suggestions, and greatly improved support for working on mobile devices (to name a few). Since we changed many strings with Gajim 1.2, some parts of Gajim have not been translated yet. If you like to contribute some translations (no development skills required), you can start by having a look at translate.gajim.org. Any help is appreciated.

Changes in Gajim

Generally, a graphical user interface should be self-explanatory. Gajim’s ‘Start / Join Chat’ window is meant to become the starting point for many actions, thus offering many features. To help you discover these features, we decided to add a little info bar. If you decide to close this hint, it won’t bother you again (unless you reset all hints in Gajim’s preferences).

Info bar showing usage hint

Info bar showing usage hint

Did you know that you can invite people to a group chat via drag and drop? A new overlay makes file transfers and chat invitations via drag and drop a little bit prettier.

Drag and drop overlay for files and contacts

Drag and drop overlay for files and contacts

What else happened

  • fixed sort order for group chat participants when sorting by status
  • Server Info window now displays the server status address if one is supplied by the service operator
  • global group chat search now reuses the search term if you already entered one
  • idle status (away because of inactivity) and status display improvements
  • shortcut improvements for MacOS (removed Alt key mappings)
  • various bug fixes

Plugin updates

This month, Gajim’s OMEMO plugin received a new feature called Blind Trust Before Verification (BTBV). With BTBV enabled, Gajim will blindly trust any device a contact might be using, and new devices will be trusted as well. As long as you don’t verify a fingerprint, Gajim will mark any new fingerprint as ‘blindly trusted’. As soon as you verify a contact, you have to verify every new fingerprint (e.g. if the contact adds a new device). So, for those of you who are verifying each device’s fingerprint, this new feature won’t change anything. For people deciding to use BTBV, this means less fingerprint-checking and easier use. It’s a trade-off, but it’s your decision. If you like to learn more about BTBV, Daniel Gultsch wrote a piece about trust management.

More OMEMO: A bug has been fixed where messages would get dropped silently if there was a decryption error. The plugin also won’t include inactive devices while checking if there are devices with an undecided trust level. Furthermore, the shield icon is now used for both incoming and outgoing messages.

Plugin updates: Every time Gajim starts, the plugin installer will check if there are updates available. If there is an update for your plugins, the plugin installer would pop up a message asking you to update. Clicking ‘Update’ will now update directly, without showing the plugins window first.

Changes in python-nbxmpp

This month version 1.0 of python-nbxmpp has been released. The library has been rewritten in most parts and now features an example client for testing.

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

Gajim

June 28, 2020 00:00

Aditya Borikar

Chapter 6: A Part Of The Whole, Merged

Hi there,
  This week was exciting. I started off with polishing the XEP-0156 PR and got it production ready. With the help of continuous feedback from mentors I could get my XEP-0156 implementation merged. Yayy \0/ !

But wait, this is not the highlight of the week ;)
  While going through XEPs, I realised that the abstract to XEP-0156 was incomplete. And thus my first ever pull request to make minor changes into the XEP came into existence. I have not been happier. Irrespective of the fact that there are possibilities in which the change doesn't get accepted, I am happy.

  It is true that one cannot have a tenacious grip on some context without having practical knowledge. So, I have started following more and more discussions on the xsf muc. The muc is quite active and the discussions provide me a perspective. All in all, it is an enriching experience.

  In coming week, I want to incorporate my XEP-0156 implementation in websocket transport along with other changes. I look forward to whats coming up next!

See you next week!

by Aditya Borikar at June 28, 2020 00:00

June 26, 2020

Erlang Solutions

Add value to your app with Instant Messaging. Here’s where to start.

Over the last ten years, we have helped A LOT of companies add value to their products using MongooseIM or XMPP based chat applications. This has allowed us to partner with, and get insights from companies spanning almost every industry and company size. You may wonder how much variety and complexity a team who specialises in scalable Instant Messaging is exposed to, but the truth is, the only thing that ties these projects together is MongooseIM, our scalable, customisable XMPP server. Once we dive deeper into the needs of our clients, we usually find deployments need new features, tailored to their specific need, to help them achieve their most critical business objectives.

Customisation is what sets the work we do apart. We make sure that your Instant Messaging is fit for purpose. Even when XMPP or MongooseIM offer a rich enough chat experience, there are other details we mare are right to deliver a reliable solution. This includes taking into consideration your workload and usage scenarios to ensure that you have the scalability to guarantee uptime. If you’d like a general introduction to our approach to building a chat application, watch our recent webinar.

How can we create or improve a chat experience for your business and its customers?

Building and maintaining a chat application is a continuous process. We join our customers at many different stages, and depending on their needs, we can help in different ways. Let’s take a closer look at some examples.

Building a bespoke solution.

We can become an embedded part of the team that builds the service. This allows us to architect and build the solution together from scratch. From the very first day, we learn about the unique properties of the customer and how instant messaging helps them to achieve their goals. As a result, we can use our expertise to make sure the system is built perfectly, from the start, before any less-than-ideal decisions are made. An added benefit of this for our customers is that their team gets to see how we go about architecting and designing a best-practice system. That way, there is a natural knowledge sharing of every step in the process, so when the product is launched and in-use, your team is familiar with how to operate and maintain your system. When possible, this is the perfect option for both the organisations we work with and us.

Improving and optimising before release.

We can’t always be there from the start. Sometimes, there is a proof of concept application ready which needs improving, often because there is a technical issue that needs to be solved before the release. At this stage, it’s still possible to help design the architecture of the entire chat system. We can also deploy it to the production environment and make sure it can cope with the increasing load introduced by new users. There are a number of common problems we help solve for companies looking to optimise their chat before release.

One of the most common reasons companies need help at this stage is that developers who have less experience with XMPP have implemented inadequate solutions which have already been solved by the existing, public XEP - XMPP extension.
We also often see problems arising when a custom extension is built on top of an existing one, which, when done incorrectly, can cause significant complications. In the lead up to the release of a chat solution companies often need help with custom integrations.
This is especially true for companies adding real time chat to an existing product. In many cases, this can be done outside of the MongooseIM code, on the other hand, it’s usually more scalable and efficient if it can be run within MongooseIM. Not every company has the need to hire full-time Erlang developers, especially for implementing a few integrations. Our team are experienced, ready and happy to help with custom integrations to ensure the reliability and scalability of the release.

To ensure success when working with an existing product that has yet to be released, we often need to take a step back and look at the product, its goals and its failures holistically. From there we can suggest the best solution. This may mean we need to rethink the existing implementation and change or reshuffle some of the code. In extreme cases, we may need to throw away large chunks of the existing solution to ensure the release is successful. This is the last resort and a decision that is taken collaboratively in the name of reaching an optimal solution.

Increasing the scalability of your chat to allow you to handle more users.

Your instant messaging is deployed and running. Your product is growing successfully. It should be a time to celebrate, but often increased adoption or use of a chat application comes with increased scalability issues. These need to be sorted fast and future-proofed to avoid giving your users a poor experience and damaging the growth you’ve worked hard to achieve.

Our role is to find the bottlenecks and fix them. We study the architecture, the server setup, configuration, enabled extensions and customised code. Then, we decide on the best possible solution together, in collaboration with our clients.

Improving or customising your chat application.

All right, the app is deployed, and users are chatting, so far so good. How can joining forces with us make things even better? There are many reasons companies will come to us to improve an existing instant messaging solution.

Many of our customers come to us to develop unique functionalities that are necessary for their success. We help by designing the extension on the protocol level and implementing it on the server. The public XEPs only cover use cases which are generic and where other people deploying chat services based on XMPP can also use them. So, if your chat needs a specific functionality, we’re always happy to help.

We also have projects where MongooseIM replaces another XMPP server. This is common when clients discover that the MongooseIM alternative technology they have chosen did not meet their expectations. A common reason for this is that out of the box functionalities can turn out to be black boxes that make it impossible to carry out necessary customisations or improvements.

Another common reason to switch to MongooseIM is to improve scalability when an existing solution reaches its capacity. In this case, we play the role of surgeons, carefully implementing a transplant to put MongooseIM at the heart, improving scalability but keeping the rest of the system running smoothly.

Tips to avoid common mistakes when using open-source MongooseIM:

Choose your XEP, and choose wisely.

X in XMPP stands for eXtensible. This means it might not be the simplest protocol, but there’s hardly a chat feature it doesn’t cover. There is a set of core RFCs on top of which custom extensions (XEPs) are built. There are usually no issues with the core functionality that is covered in RFCs. They are adopted by many client libraries and servers. XEPs are often isolated from each other, independent from the core functionalities. They add extra features or capabilities to the core of XMPP. Here comes the biggest challenge: deciding which XEP to choose (you can find more details in our XMPP use-cases guide). From our experience, developers starting their adventure with XMPP may have a hard time finding a suitable XEP. This can sometimes accidentally lead to your choice creating difficulties or limitations. Some examples:

Too many extensions are enabled on the server-side, but not used by the client app.
Certain XEPs like XEP-0012: Last Activity put extra load on the server, even when the client’s application is not using them. Enabling only used extensions helps to scale the MongooseIM cluster.

An outdated or rejected extension is used.
Often, different products with instant messaging functionality store the messages on the server. For this, there is extension XEP-0313: Message Archive Management. The majority of servers and client libraries have implemented the XEP for several years already. It replaces an old, more complicated and now deprecated XEP-0136: Message Archiving. Sometimes, developers choose the deprecated extension over the new one.

A custom extension is built even if an existing XEP covers the required functionality.
For instance, if a user wants to know if someone is active in a chat conversation. To achieve that, some extra XMPP stanzas need to be sent. Developers, me included, are creative creatures, and sometimes we rush to reinvent the wheel. In this particular case, XEP-0085: Chat State Notifications fulfils this need.

Reduce unknowns

When preparing for a wave of users using instant messaging functionality, we need to remember to load test. It’s very crucial to run load tests to know the capacity of your production setup. To my surprise, this is often neglected. Many people want an answer to the following simple question: “how many resources do I need to handle X number of users, sending Y messages per second”. There are too many factors and variables to accurately answer this question. To have a better idea about the capacity, you can run load tests simulating user behaviours. It usually starts with developing the scenario. After making sure that monitoring is in place, the load testing can start. Now we can learn how the system behaves and what to expect in the production environment.

Summing it up

It is very important:

  • to know what functionalities are needed and enabled on the server
  • to verify if a custom extension is already covered in a XEP
  • to only build a custom extension if necessary
  • to run load tests to find the capacity and be better prepared for the real traffic

All of the above may not be rocket science; many services run on MongooseIM without our help.
If you are up to the challenge, good, we are always happy to see our product in use.
But, when your time is critical, or if you stumble upon a problem you can’t fix, we’re happy to help. If hacking through 80K lines of unknown code is not your cup of tea, we can guide you through it. Stay safe and have fun adding real-time communication to your product, if required.

You may also like:

MongooseIM

Online Erlang and Elixir training

Our RabbitMQ services

Our next webinar

June 26, 2020 11:23

June 24, 2020

Monal IM

New betas out

There are new mac and iOS betas out. Mac should resolve a badge issue where the wrong number of unread was shown. Both have debug logging enabled

by Anu at June 24, 2020 20:37

June 21, 2020

Ignite Realtime Blog

Smack 4.4.0-alpha5 released

The Ignite Realtime community is pleased to announce the release of Smack 4.4.0-alpha5.

We decided for another alpha release after some minor issues have been found with the last release. Fixes for all found issues are now in 4.4.0-alpha5, and we additionally improved the DNS server lookup mechanism on Android (although, this is an improvement within minidns-android21, not Smack itself, to be precise).

If no major blockers are found, then we will in around 4 weeks create the ‘4.4’ branch in Smack’s git repository and prepare the first beta release. If there is a feature or API change you like to see in Smack 4.4, then you should use that merge window to get your changes into Smack.

More information about Smack 4.4 can be found in the release’s README.

Happy hacking!

2 posts - 2 participants

Read full topic

by Flow at June 21, 2020 11:06

Gajim

Gajim 1.2.0

Gajim is a fully-featured XMPP client. It enables you to chat in a decentralized network using one of the many providers available or even your own service. The choice is yours. Gajim offers End-to-End encryption, is extensible, and open-source. More than a year after the release of Gajim 1.1.3 it is finally time for Gajim 1.2. A year of developing new features, cleaning up old code, and bug fixing. Highlights of this release are (amongst others): improved group chat system, completely rewritten network code, and a new account creation assistant. But there is much more to discover.

Group Chats

Let’s start with a vital part of many instant messengers: group chats. Until now, group chat related actions, such as changing your nickname or inviting people were shown in separate dialogs. In Gajim 1.2, all of these dialogs have been reorganized into group chat ‘pages’ overlaying the chat. In addition to that, it is now also possible to view an info page for each group chat, containing the chat’s settings, description, topic, and so on (see November’s Development News). Inviting people has become a lot easier with the new invite page, where you can search and filter your contacts. It is now also possible to invite someone from your contact list by drag and drop. Furthermore, each group chat window now features an updated participants list, which fixes some nasty display bugs from the past. In case of an error (chat destroyed, service gone), Gajim will now offer to remove a faulty group chat permanently.

But how do you create a group chat? This wasn’t obvious in past versions, but now Gajim features a new group chat creation window, available through ‘Gajim’ > ‘Create Group Chat’. It allows you to create both private and public group chats and applies sane default settings. Additionally, you can set a name and a description.

Network Connection

Rewriting the network connection code of Gajim has been a major task for the past few months. These changes enable Gajim to establish connections faster (especially when running under Windows) and also to recover from network connection loss or other connection related problems. Proxy handling has been improved and WebSocket (RFC 7395 as a replacement for BOSH) is now supported as well. In the near future, Gajim’s Plugin Installer and URL Image Preview will also be able to honor the proxy settings your specified for your account. This proxy will also be used for file transfers via HTTP File Upload. March’s Development News cover most of the changes.

To get an insight into connection details, the Server Info window now lists transport protocol, transport security, and connection proxy. If needed, you can also inspect the server’s certificate. Contact addresses published by the server (e.g. for troubleshooting) are listed as well.

Account Creation Assistant

We would like to introduce Gajim’s completely rewritten account creation wizard. It features server suggestions, links to the conversations.im compliance tester, and server auto completion, which should help in the process of registering a new account. Input errors will be marked inline without disrupting error dialogs. Last but not least, the data form widget (server provided inputs for username, password, captcha, etc.) has been significantly improved. The underlying assistant window is also used to guide users through account removal and password changes.

Beta Improvements

The beta release last month lead to a few bug reports (thank you), and now it looks like the new version is ready for shipping.

With your feedback, we were able to improve multi-account setups by adding colored account badges. You can now name your accounts and assign colors.

Colored Account Badges

Colored Account Badges

The ‘Start / Join Chat’ window will now display a hint for first time users, introducing for example the new global group chat search. Gajim is now able to search for group chats globally, using the service of search.jabber.network. You can browse for new group chats and join them directly.

Additionally, anonymous login has been re-implemented and various small bugs have been fixed.

More Changes

  • Many bug fixes and improvements for Gajim’s Flatpak version
  • Default avatars are now generated for every contact using Consistent Color Generation (XEP-0392) and the contact’s initial letter
  • It is now possible to paste an image from the clipboard to send it
  • File transfers via HTTP File Upload will now display filename, upload speed and remaining time
  • Maximum allowed file size for HTTP File Upload is shown in the Server Info window
  • It is now possible to drop a file on a contact to start a file transfer
  • In addition to viewing an OMEMO encrypted file, it is now also possible to open the folder containing it
  • Improved Theme Manager
  • Contrast and color improvements for both light and dark themes
  • Better icon for Message Delivery Receipts
  • Delivery errors are now shown in the tooltip of the corresponding message icon
  • Gajim’s logs database (which stores chat history amongst others) received some performance tweaks
  • Improved Audio/Video source selection in preferences (plus video preview)
  • Contact list tooltip cleanup
  • Many text strings have been revised (e.g. consistent use of terms like ‘Group Chat’, easier language)
  • Keyboard shortcuts for moving tabs have been added
  • New XML console features (filter XML stream by account, search within stream)
  • Global menu (appmenu) has been moved back to the menubar (GNOME)
  • ‘Invisible’ status has been removed
  • Chat: FuzzyClock feature has been removed
  • 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

Gajim

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

June 21, 2020 00:00

Aditya Borikar

Chapter 5: Discrete Http Lookup Method

Hello readers,
  In the previous week, I could interpret remote endpoints through the use of XEP-0156. This week my mentors, Florian and Paul have assigned me a milestone for the first month evaluation. Since XEP-0156 is by no means exclusive to the websockets subprotocol, it has been concluded that the implementation is an independent task in itself. So, for my first month evaluation I have to prepare the XEP-0156 implementation to be production ready and get it merged.

  I have started working for this implementation on a different branch altogether and have proposed a PR. The code is under continuous evaluation and improves with each review.

To check my pull request, Click here!

  I am expecting that this pull request will be production ready by the end of this week, so that I can incorporate these APIs in my websocket implementation. Along with these I have made few minor changes on the websocket tranport.

This was pretty much it for this week. See you until next time :)

by Aditya Borikar at June 21, 2020 00:00

June 20, 2020

Monal IM

New builds for 4.7

Sorry for disappearing. Covid either makes people not have work or have a lot more work. In my case it is a lot more work. There isn’t enough time in the day to do everything I need to do these days. That said there are others who have been working on Monal and I have tried my best to be helpful with getting builds out. There are new iOS and Mac betas up. Let me know how it goes.

by Anu at June 20, 2020 01:12

June 19, 2020

Peter Saint-Andre

Philosophy and Anger

The world is full of anger, both well-founded and ill-founded. In a future post I'll talk about well-founded anger, but this time I'll provide some reflections on ill-founded anger....

June 19, 2020 00:00

Dialogue and Deliberation

One of Aristotle’s characteristic methods for solving philosophical problems is dialectic: upon (i) reaching an impasse (aporia), he (ii) surveys existing explanations (logoi) and reputable opinions (endoxa), (iii) engages in analysis to remove paradoxes and draw distinctions, then (iv) formulates a synthesis that harmonizes the explanations and saves the appearances (phainomena)....

June 19, 2020 00:00

June 15, 2020

Anmol Chaudhary

Receiving Real Time Texts

Since the last blog, I have been able to integrate receiving real-time text in Dino. For that, I have implemented a receiving queue that first stores all action elements received from incoming rtt message stanzas in order. A queue is better than directly processing received action elements as the latter approach is prone to syncing issues. I’ve also implemented a basic method to counter out of sync issues by ignoring further rtt messages from a sender if the sequence is disturbed and will be resumed only when the event received is new. (More work needs to be be done to manage out of sync issues in further weeks).

The action element stanza nodes in the queue are then processed one by one and the changes are then processed using string-builder. The real-time texts received look promising. Since there is no user interface right now, I’m using debug to see incremental changes in the message being received.

For sending RTT I managed to do the scheduling along with the user’s typing action which is better than last week’s always on scheduling.

So what’s left now that I hope to accomplish in the next two weeks before the first evaluation? For one I will be implementing a user interface for single user chat; some code changes as suggested by Marvin (my mentor), handling issues and bugs, and error handling. With that, I hope to get basic real-time text working by then.

June 15, 2020 00:00

June 14, 2020

Aditya Borikar

Chapter 4: Fixing loose endpoints

Hi,
  Last week we witnessed successful SASL negotiation and this week I tried to improve code quality. The previously designed Websocket implementation went through 10 phases during handshakes. As pointed by my mentors, I realised that most of the phases involved similar funtions like sending TopLevelStreamElement, sending Open Stream element, etc. Moreover most of the phases were repetitive. Those repetitive phases are squashed together and now I have four phases only.

Those four phases are:
  1) ReadyToSendOpen
  2) OpenFrameSent
  3) ReadyToReceiveFeatures
  4) ExchangingTopLevelStreamElements

  Along with this, now I am able to discover remote connection endpoints through the use of XEP-0156. Currently I able to parse metadata only through XML files. It is also possile that servers provide host-meta information in the form of JSON files. This is one part which is yet to be worked upon.

  Recently I got stuck at an unexpected situation. OkHttp is terminating websocket connection with an exception in response to the presence stanza sent after SASL auth. The behaviour is quite unexpected. This situation has been tough to tackle because the throwable received doesn't provide any significant information regarding failure of the connection.

This has been my past week. See you in the next blog.

by Aditya Borikar at June 14, 2020 00:00

June 13, 2020

Ignite Realtime Blog

Openfire 4.6.0 Beta is Released

The Ignite Realtime Community is thrilled to announce the beta of our next major feature release of Openfire 4.6.0. The changelog details the issues resolved with some of the highlights including:

  • improved PEP/PubSub support
  • added XEP-0289: Federated MUC for Constrained Environments
  • improvements and bug fixes made after enhanced integration tests provided by the aioxmpp library

A tremendous amount of thanks goes to @guus for his continued development work pushing Openfire forward and bug fixes made.

You can find download artifacts for this beta release having the following sha1sum checksums.

aa1c503808d54904456d9f41ba715f85eb1925d3  openfire-4.6.0-0.2.beta.i686.rpm
1732df79b0fa8e5359df313e56314e728e8dd3e6  openfire-4.6.0-0.2.beta.noarch.rpm
8e2ef7835da4d094099357ac7137fb848f30f376  openfire-4.6.0-0.2.beta.x86_64.rpm
d7425999ae0d39362b1a11e60c7ec3215b0e6efc  openfire_4.6.0.beta_all.deb
231601705ada84c465c1942c56fc8c49f7fb7239  openfire_4_6_0_beta_bundledJRE.exe
0e326b6d6df89a3ccb9e09a199ed97eef40cd358  openfire_4_6_0_beta_bundledJRE_x64.exe
b20c6fffff57b970c465e3d8ba010bac94e9df15  openfire_4_6_0_beta.dmg
c244234d55d9e37907b2901e5c1dc22cad833221  openfire_4_6_0_beta.exe
06ff956ba1f1faa7b889ab4be0fad80062475844  openfire_4_6_0_beta.tar.gz
c66fa82bafcf8039b22e148fc95ef8938ece200a  openfire-4.6.0beta.tar.gz
71f2bd20ad41c317b760e8b07b4870c534dc6b6a  openfire_4_6_0_beta_x64.exe
dbda855fd20a23b7e66839349571ca3fa2826758  openfire_4_6_0_beta.zip
cd72160b919510e6379b69900f8e7cfd2a9d76e8  openfire-4.6.0beta.zip

Often folks want to know when to expect the full 4.6.0 release? The answer greatly depends on the amount of community testing and feedback we get! Please drop by our web support chat or post a message in our discourse forums letting us know how the beta is working for you.

Thanks for your usage and interest in Openfire!

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

by akrherz at June 13, 2020 10:41

June 09, 2020

Profanity

Profanity 0.9.0

Four months and 350 commits after 0.8.1 we are happy to release 0.9.0.

7 people contributed code to it: pasis, wstrm, DebXWoody, toogley, pmaziere, moppman and jubalh.

Thanks to everybody who was involved, be it testing, writing documentation, updating the website or whatever you did! I also would like to express my gratitude to my sponsors mdosch and wstrm!

Profanity

LMC

We support XEP-0308: Last Message Correction now. Enable it with /correction on. If you mistyped a word just type /correct and hit tab to autocomplete the last sent message, then fix it and press enter.

Slashguard

In our MUC we often see messages like “q/uit” or people having whitespaces before a command " /quit”. To help you to avoid such mistakes we introduce slashguard. Once enabled (/slashguard on) Profanity won’t send messages that contain a backslash in the first four letters.

New parameters

You can specify a logfile upon startup via the new -f option: profanity -f TEST will log to ~/.local/share/profanity/logs/TEST.log.

Hopefully this is useful for our testers!

The new -t option will let you select a theme right at startup: /profanity -t bios. This is useful if you run multiple instances of Profanity. Maybe you have multiple accounts and want to visually destinguish between them.

Did you know we have a blogpost that should help you create such a setup with tmux?

Titlebar

Previously you could choose whether to display the MUC name or MUC title in the titlebar. Now you can choose to do both or neither. /titlebar use name|jid became /titlebar show|hide name|jid.

What software is this server running?

You can now use XEP-0092 not just to request client software information but also server software information. Use /serversoftware domain.org.

Theming

You can now colorize your trackbar by using main.trackbar in your theme.

And you can use UTF-8 symbols as your OMEMO char.

You can now choose not to colorize your own nick if you enabled XEP-0392. Use /color own off if you want consistent color generation for everybody else but not for yourself.

MUC history messages were colored in one uniform color (grey by default). Many users would just like to get the same coloring and hilighting for freshly received messages. So we removed the uniform color feature #1261.

And there is a new theme based on default: jubalian. Check it out ;)

Avatars

Avatars can not only be downloaded but also opened automatically now. In 0.8.x you used /avatar odin@valhalla.org. Now you can either just download it /avatar get odin@valhalla.org or open it: /avatar open odin@valhalla.org.

By default we rely on xdg-open, so your default image viewer will be used. But you can choose to configure it yourself. For example to use feh instead: /executable avatar feh

Open URLs

People often had issues with URLs that were too long and then broken into several lines. If they were in a MUC and had the occupants panel enabled, this made it impossible to click on the URL to open it because it was not one consecutive string.

If you run Profanity locally (not on a remote machine where you log in via ssh) you can use use /urlopen to open an URL in your browser.

We use xdg-open again. But you can configure it with /executable urlopen firefox.

OMEMO

OMEMO autocompletion had some quirks. We fixed them! We also stopped requesting the device list in non anon MUCs.

Scrolling

Sometimes it happened that you scroll up a window to read up on something. Then switch to another application and later forget that you actually scrolled up. Why is noone saying anything in this MUC anymore?

In this version of Profanity we display a hint in the titlebar if a window is scrolled. Use titlebar.scrolled to theme it.

Legacy authentication

Some servers still only allow legacy authentication #1236. If you want to connect to them you will need libstrophe 0.9.3 and Profanity 0.9.0.

Use /connect <account> [auth default|legacy] or /account <account> set auth default|legacy.

Too many tabs

In case you many opened windows you might want to only display the ones that have something going on in them. Use /statusbar show|hide read to configure this to your liking.

Bookmarks

We now print the boomark names when using /bookmark list. You can also now add a name when using /bookmark add.

Gajim uses a custom way to save whether (autojoined) bookmarks should be minimized. When we updated a bookmark in Profanity we didn’t respect this flag and it was overwritten. Now Profanity works nicer with Gajim #1326.

When you use multiple clients you probalby have some MUCs that you want to join on all devices. You use the autojoin flag for these cases. If you want to ignore the autojoin flag in a Profanity instance you can use /bookmark ignore.

Narrow terminals

We can’t support all edge cases and users will need to have a reasonable window size to use Profanity properly. We fixed a bug about a messed up titlebar if a user had a very long resource name #715.

Change in default settings

To give a better experience to new users we changed the default settings for some popular features.

  • Allow message correction
  • Send receipts
  • Enable carbons
  • Enable type/chat states

Under the hood

Plenty of memory leaks where discovered and fixed. Profanity should run a lot smoother now. The UI and message functions were cleaned up in preparation to add MAM support.

Messages are now logged in an sqlite database which is located at ~/.local/share/profanity/database/accountname/chatlog.db. All later retrieval (history) is done using this database from now on. We still output regular chat logs in ~/.local/share/profanity/chatlogs if the user enabled it (/loggin chat|group on) but don’t rely on them anymore. They are just for the users convenience.

This will also benefit us when implementing message searching #206 or MAM #660 for example.

We always send delivery receipts and not just if the other client advertises it #1268.

Some users experienced connectivity problems. Several things were done by DebXWoody to improve this.

We also had an edge case where the roster only displayed offline contacts because we received the presence after the roster.

June 09, 2020 13:46

June 08, 2020

The XMPP Standards Foundation

XMPP@home - 9 June 2020

Welcome to the XMPP newsletter covering the month of May 2020.

Subscribe to the newsletter

We suggest you Subscribe to receive the next editions in your inbox as soon as it is published! Promote this newsletter to whoever may be interested.

Help us to build the newsletter

We started drafting every new issue in the XSF Github repository. And we are always happy to welcome contributors. Just 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) write about it? Please consider sharing your news or events here, and promote it to a large audience! Even if you can only spend a few minutes, these would already be helpful.

Tasks which need to be done on a regular basis are for example:

  • Aggregation of news in the XMPP universe
  • Short formulation of news and events
  • Summary of the monthly communication on extensions (XEP)
  • Review of the draft
  • Translations: especially French, German and Spanish

Newsletter translations

Translations of the XMPP Newsletter will be released here:

Software releases

It has been almost a year since the release of Gajim 1.1.3. A year of developing new features, cleaning up old code, and fixing bugs. This month, it is finally the time for a first beta release of Gajim 1.2. Highlights are (amongst others): improved group chat system, completely rewritten network code, and a new account creation assistant. But there is much more to discover.

Log in: Gajim 1.2.0-beta1 log in

Sign up: Gajim 1.2.0-beta1 sign up

Create account: Gajim 1.2.0-beta1 create account

Clients and applications

Gajim Development News May 2020: New account badges and the great plugin overhaul. In preparation of the upcoming 1.2 release, many plugins have been revisited. Check out the new file preview!

Goffi released Salut à Toi progress note for calendar week 21!

Poezio released 0.13.0 and 0.13.1 which now requires python 3.7. These versions bring Poezio into the club of OMEMO supporting clients and also enable HTTP upload via dedicated plugins. Check the full changelog to look at all the improvements of these versions.

Biboumi, the XMPP/IRC gateway, was released in version 0.8.5, fixing compilation issues with GCC 10.

The python based XMPP automatic file sender Errol has been updated to v2.0.1 which modernizes its async I/O calls and adds more privacy. By moving from 'aionotify' to the better maintained 'watchdog', Errol theoretically extends its support (from Linux only) to Windows, Mac OS X and FreeBSD.

Services

blabber.im now supports IPv6. The service operators created an invitation link which works for their server but also for every other ID. If you moved to an XMPP based chat client, you can now conveniently put this link into the status of your previous non-XMPP chat clients. This link offers your contacts all the necessary infos to be able to reach you and (if they want to) follow you into the XMPP world.

Jabber.org

jabber.org migrates its server to Prosody. Stay informed!

yaxim.org rolled out new anti-spam measures. You may be interested in the 'The Jabber Spam Fighting Manifesto', too.

Libraries

The XMPP library for Python 3.7+, Slixmpp, was updated to version 1.5.0, with minor releases 1.5.1 and 1.5.2. The changelog shows improvements of numerous XEPs and preliminary support for OMEMO.

Quite some time has past since the last official Smack release. Now there are some very early alpha releases of Smack 4.4. Among additional support for more than a dozen new XEPs, the new release will contain a new architecture for modular transports, as well as a modified API that applies the builder pattern to stanza types. A date for the final release is not yet known, but it is now time to give feedback to make sure to get your changes into the next stable Smack release! Read the detailed list of changes.

Google Summer of Code

Since beginning of May students all over the world are working on many open-source projects within the Google Summer of Code Season. We would like to introduce the students who work on GSoC XMPP projects and share their first blog posts:

Aditya Borikar is working on WebSocket support for Smack. Blog history: - Chapter 1: Handshake - Chapter 2: Modular Shift

Anmol (wolfie_anmol) is working on implementing Real Time Texting in Dino (XEP-0301). Blog history: - GSoC 2020 begins - Introduction to RTT - RTT stanza and message comparision

Thank you for joining GSoC XMPP projects and keep up the good work! To be continued.

Extensions and specifications

Updated

  • Version 0.4.0 of XEP-0414 (Cryptographic Hash Function Recommendations for XMPP)
  • Make Blake2b-256 SHOULD and Blake2b 512 MUST (rion)

  • Version 1.1.0 of XEP-0402 (PEP Native Bookmarks) -Add schema + other editorial changes (mb)

  • Version 0.5.0 of XEP-0389 (Extensible In-Band Registration) -Overhaul document for readability. -Add JID and username information to success element. -Always require disco/caps feature. -More examples. (ssw)

  • Version 1.3.0 of XEP-0068 (Field Standardization for Data Forms) -Clarify field type handling of the FORM_TYPE field on submission forms. (fs)

  • Version 0.2.0 of XEP-0436 (MUC presence versioning) -Incorporate feedback from the standards list -Create a separate tag for sending the version number. -Include a reset token. -Remove the "Additional measures" section and merge parts into "Requirements". -Mandate that presences are always sent for affiliated users. (jcb)

  • Version 0.2.0 of XEP-0437 (Room Activity Indicators) -Assign urn:xmpp namespace instead of xmpp:prosody.im namespace (this was missed during acceptance) (XEP Editor (jsc))

  • Version 0.1.1 of XEP-0438 (Best practices for password hashing and storage) -Fix reference to external document (ssw)

  • Version 1.2.0 of XEP-0167 (Jingle RTP Sessions) -Introduce element to signal the ability to multiplex RTP Data and Control Packets. (dg)

  • Version 2.10.0 of XEP-0004 (Data Forms) -Clarify that fields which are not required may be omitted on submission. (fs)

Proposed

The XMPP Extensions Editor has received proposals for new XEPs.

Miscellaneous

Experimental

  • Version 0.1.0 of XEP-0439 (Quick Response) -Quickly respond to automated messages. -Accepted by vote of Council on 2020-04-22. (XEP Editor (jsc))

  • Version 0.1.0 of XEP-0437 (Room Activity Indicators) -This specification describes a lightweight mechanism for activity notifications in MUCs -Accepted by vote of Council on 2020-04-15. (XEP Editor (jsc))

  • Version 0.1.0 of XEP-0436 (MUC presence versioning) -This specification defines a versioning mechanism which reduces the amount of presence traffic in a XEP-0045 MUC -Accepted by vote of Council on 2020-04-01. (XEP Editor (jsc))

Draft

  • Version 1.0.0 of XEP-0320 (Use of DTLS-SRTP in Jingle Sessions) -Move to Draft as per Council vote from 2020-05-20. (XEP Editor (jsc))

  • Version 1.0.0 of XEP-0339 (Source-Specific Media Attributes in Jingle) -Move to Draft as per Council vote from 2020-05-20. (XEP Editor (jsc))

Thanks all!

This XMPP Newsletter is produced collaboratively by the community.

Thanks to emus, nyco, pmaziere, SouL, vanitasvitae, wurstsalat3000 for their help in creating it!

Spread the news!

Please share the news on "social networks":

License

This newsletter is published under CC BY-SA license.

by emus at June 08, 2020 22:00

June 07, 2020

Aditya Borikar

Chapter 3: SASL Negotiations

Hello everyone,
  This week has been pretty amazing. Prior to GSoC, I had some commits which added support for a particular XEP, but I had always been curious to know what exactly happens under the hood, how these connections are established, etc.

  As of now, I am able to achieve success SASL authentication. This means that the code snippet actually works,

ModularXmppClientToServerConnection connection = new ModularXmppClientToServerConnection(config);
connection.connect();
connection.login();

To monitor the course of SASL authentication, I have introduced `WebsocketConnectionPhases`. These phases keep track over status of the connection, right from `attemptingWebsocketHandshakes` till the connection is in phase `exchangingStanzas`.


  In the coming week, I would want to make methods more modular to remove redundancy and find a way to make websocket base library pluggable.

That is all for now. See you next week!

by Aditya Borikar at June 07, 2020 00:00

June 05, 2020

Anmol Chaudhary

Sending RTT

In last week’s blog, I introduced you to message comparison and an optimized algorithm to compare between two strings already being present in Python, which is an implementation of gestalt pattern matching, an algorithm published in 1988 by Ratcliff and Obershelp.

This week I managed to implement the said algorithm in Vala to compare the current and previous versions of the message being typed and used it to generate the relevant action elements. The results produced are good with the correct action elements being generated.

I also implemented a queue to store these action elements and send all action elements present in the queue in scheduled intervals in a single RTT message stanza.

With that, I am mostly done with sending a basic version of real-time text and am able to send rtt message stanzas. There is still some work left for sending RTT before it becomes useable; like right now the event is always set to “new” and the rtt schedule method is always executed in a fixed time interval even when the user is not typing. This leads to Dino crashing eventually. These issues will be addressed this week.

This is the result produced by my build for sending rtt:

_config.yml

For now, I’ll be looking into receiving real-time texts.

That’s it for this week.

June 05, 2020 00:00

May 31, 2020

Aditya Borikar

Chapter 2: Modular Shift

Hello everyone,
  In the previous blog I have mentioned about some work on handshakes. I have used this week to understand Florian's newly introduced Modular Transport Architecture and update my previous progress by introducing Websocket Transport \0/.

  The modular architecture to me looks like a sophisticated approach which suggests that everything in between and beyond entering credentials and succesful authentication is a state. And each of these states are accompanied by state descriptors, serving metadata. And such states are a part of the Finite State Machine.

 This week I have been able to partially define websocket transport along with the accompanying states and descriptors.

 At the moment, I am making use of okHttp library to perform ground level websocket operations. Incase in future if we plan to replace okHttp with another websocket implementation, we would easily be able to achieve that through the help of interfaces.

 This week for me was less about coding and lots and lots of debugging. With every iteration, I was able to understand the module in a better way.

That is all for now. See you next week!

by Aditya Borikar at May 31, 2020 00:00

May 28, 2020

Anmol Chaudhary

RTT stanza and message comparision

It’s been a week and a half since I started working On Real-Time Text. Firstly I have established a framework to generate RTT message stanza and send them over the network. This includes generating relevant action elements as per requirement.

My initial goal is to get a basic real-time text model for single chat users. For that, I have planned a series of steps which are as follows:

_config.yml _config.yml

One of the important steps to achieve that is message comparison. This step will produce a difference between the previous text stored in the buffer and the new one being typed. This text difference will be translated in the form of action elements that will be sent in the element.

A correct algorithm is required to produce the right action elements. An inefficient message comparison will lead to either generation of many action elements that could lead to bandwidth issues or action elements that will make real-time texts to appear unnatural.

I found a JavaScript implementation of the XEP-0301. The message comparison method there is not efficient for our purposes. For instance, if someone makes an edit in between their text then it would first erase everything from that point and replace it with new text. This will seem unnatural to the end-user who is receiving RTT.

As planned before I was thinking in terms of either a linear scan to compare changes or some minimum edit sequence algorithm.

Fortunately, in my search, I found that Python has a standard library called difflib which offers exactly what I want for my purpose. The algorithm behind is basically a version of Longest Common Subsequence (LCS) and produces a good result that is more “human friendly”, unlike traditional LCS. Here’s a small script I ran in python inspired from this StackOverflow answer:

_config.yml

And the result:

_config.yml

Pretty neat, right!

So right now I’m looking over at implementing something like this for Dino In Vala. Instead of color-coded text to show the difference the Vala code will call methods that will generate insert and erase action elements.

May 28, 2020 00:00

Peter Saint-Andre

Crisis Investing

Exactly four years ago I wrote a post entitled "Investing for the Rest of Us", in which I discussed the permanent portfolio investing method, invented by Harry Browne. The permanent portfolio has two additional benefits that I've come to fully appreciate only this year: uncorrelated assets and forced rebalancing....

May 28, 2020 00:00

May 27, 2020

Jabber.org Notices

Server Software Migration

After many fine years of running Isode's M-Link server software, the jabber.org admin team is currently working to migrate to the open-source Prosody server. Although we will strive to make this transition as seamless as possible, performance might suffer temporarily as we run migration scripts and the like. We apologize for any inconvenience.

May 27, 2020 00:00

May 26, 2020

Gajim

Development News May 2020

This month brought new features and many improvements for Gajim plugins (checkout the new file preview)! On the other side, we had to decide which plugins to keep and which ones have to go before the 1.2 release. During this month, Anonymous Login has been re-implemented and account badges have been added. If you’re using multiple accounts with Gajim, you should now be able to quickly recognize which account you’re chatting with.

Changes in Gajim

After Gajim’s network connection code has been rewritten, many features had to be adapted in order to work correctly with the new code. One of the last missing features has now been re-implemented: Anonymous Login. The new Account Creation Assistant allows you to login anonymously, if the server offers support for this feature.

Last month we introduced account colors for people using multiple accounts in Gajim. To improve recognizability, we swapped the colored icon with a colored badge showing the account’s name. This badge is shown in the Start Chat window, in the Group Chat Invite page, and in the chat window’s banner if you have more than one account enabled.

One of the bigger changes for upcoming Gajim versions will be an overhaul of the way conversations are displayed. To start the transition, we changed the chat window’s default tab position to ‘left’, and increased the size of avatars.

What else happened

  • ‘Reconnect’ menu entry for group chats in the contact list has been removed
  • mnemonics for accessing menu items in Gajim’s main menu have been added
  • fixed contact list tooltip showing wrong status infos
  • Preferences: reintroduced ‘Merge Accounts’ setting
  • XML console now shows stanzas from Account Assistant
  • various code improvements and bugfixes

Plugin updates

In preparation of the upcoming Gajim 1.2 release, we had to decide which plugins to keep and which ones have to go. Some plugins didn’t work anymore (because software changed) and Gajim integrated features which rendered some plugins obsolete. While adapting the plugins to the changes in Gajim, we took the opportunity to add some features or improvements here and there. One of these new features is the file preview of Gajim’s URL Image Preview plugin. It now features a preview icon for every file type plus file size, name, and buttons for ‘Download’, ‘Save As’, and ‘Open Folder’.

Gajim’s new file preview

Gajim’s new file preview

Most plugins now use the new plugin configuration window and and should be fully translatable. But there is much more:

  • Rewritten plugins: Anti Spam, Now Listen, Syntax Highlight
  • OMEMO, OpenPGP, PGP, Form Handler, Set Location, Birthday Reminder, Latex, and Tic Tac Toe have been adapted to changes in Gajim
  • Triggers plugin has received code improvements and a GUI update
  • Set Location plugin received some GUI improvements
  • Length Notifier can now be enabled for specific JIDs or Domains
  • Client Icons plugin will show icons in the contact list tooltip only (not directly in the contact list)
  • OMEMO now uses migration routines to update (very) old key databases
  • URL Image Preview and OMEMO plugins have been added to Windows builds
  • plugin translations have been updated
  • Flatpak plugins have been updated

The following plugins have been removed from Gajim (full list): Banner Tweaks, Flashing Keyboard, GUI for /me, Juick, Roster Tweaks, Server Status Icons, and Wrong Layout.

Changes in python-nbxmpp

This month, python-nbxmpp received some bugfixes. Sometimes it happens that servers send malformed data. This can potentially result in an error report window popping up in Gajim. To avoid this, python-nbxmpp has to deal with malformed data before Gajim processes it (#10097).

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

Gajim

May 26, 2020 00:00

May 24, 2020

Aditya Borikar

Chapter 1: Handshake

Hi,
 It has been a week since I have been working on preliminary websocket stuff.

  The client is expected to initiate a websocket handshake by sending a HTTP GET upgrade request. During this, the client MUST include the value 'xmpp' in the list of protocols for the 'Sec-WebSocket-Protocol' header.

 If a client receives a handshake response that includes 'xmpp' in the 'Sec-WebSocket-Protocol' header, then the XMPP subprotocol webSocket connection was established successfully. In case the header is absent in the response, it means that the 'xmpp' subprotocol connection has failed and so the client must close the websocket connection immediately.

 I am able to complete this handshake procedure against a local openfire server. I have provided below the headers sent and received during handshake,



 But for this handshake to take place, we first need to discover its websocket connection endpoint for the server. For this we use RFC 7395, section 4 .

 Sending a request to "/.well-known/host-meta" at an HTTP origin that matches the XMPP service domain. For eg: If the domain is "example.org", we should send a request at the URL "https://example.org/.well-known/host-meta".

 Server responds to this request and provides a websocket endpoint under "urn:xmpp:alt-connections:websocket" link relation. Servers MAY expose discovery information using host-meta documents, and clients MAY use such information to determine the WebSocket endpoint for a server.

  As of now, my implementation fetches connection endpoint in case the endpoint isn't configured explicitly by the user inside `XMPPWebsocketConnectionConfiguration`. If user provides websocket URL, we directly move on to sending the HTTP upgrade request as explained earlier in this blog.

That is all for my progress as of now. Thank you for spending time and reading it!

by Aditya Borikar at May 24, 2020 00:00

May 23, 2020

Ignite Realtime Blog

Smack 4.4.0-alpha3 released

The Ignite Realtime community is pleased to announce the release of Smack 4.4.0-alpha3.

This is scheduled to be the last alpha release of the upcoming Smack 4.4 series. In 4-6 weeks, we will create the ‘4.4’ branch in Smack’s git and prepare the first beta release. If there is a feature or API change you like to see in Smack 4.4, then you should use that merge window to get your changes into Smack.

Happy hacking!

6 posts - 3 participants

Read full topic

by Flow at May 23, 2020 17:40