Vendor-independent chat based on international standardized protocol is a recommendation in the Quick Overview!
If someone knows the chat standard under the name “Jabber”, it should be noted that the system has undergone major changes in recent years and has adapted to the current requirements of modern “instant messaging”. However, the name is still often used today - which is interesting for smartphone users: In the normal address book, there is often a field “chat” for each contact in which you can store the chat address of your contacts. For standardized chat simply choose “Jabber” as system.
Table of contents:
There are no exact user numbers - however these lie in the multi-digit million range:
Thanks to the pioneering role of “Conversations”, it is possible to “text” on 80% of smartphones with a modern and intuitive user interface. Beyond that, however, there are other inteoperable free messengers for a wide variety of operating systems and for browsers:
* The multi-messenger Pidgin can only be recommended with restrictions (as of 2021). It is intuitively usable and supports OMEMO - not however the XMPP extensions “MAM” (XEP-0313) and “Message Carbons” (XEP-0280): These are required so that chat history and messages are reliably distributed even on multiple owned devices.
Equally restricted is the desktop client “coy.im”, which also does not support the extensions XEP-0313 and XEP-0280. This client has committed itself to OTR as encryption method. coy.im according to its own statement not suitable for the exchange of sensitive content: https://github.com/coyim/coyim#security-warning (external)
It is even possible to write an OMEMO-enabled Jabber client yourself using Java, which does not require 200 lines of source code:
However, no matter which messenger is chosen - through the common basis one can communicate without having to have the same messenger installed. As with other programs (e.g. browsers, file managers, image editing, music programs, …), the user can choose the one he likes best! The “system” works independently of this.
The outstanding feature (for some a flaw) of standardized chat is that it can be adapted to changing requirements and kept modern by extensions/“XEPs”. However, not every client needs every extension and if extensions are to be supported, appropriate programming work is required. The following overview provides an overview of this:
| PDF file (approx. 0,2 MB): >> here <<
Kindly provided by: ‘kikuchiyo’ / CC-BY-SA-4.0
English background information on OMEMO: https://conversations.im/omemo (external)
Thoughts on end-to-end encryption
Besides classic chats with normal contacts (2s chats / “1:1”), there are also private chat rooms (“groups”) and even public chat rooms. For and in each chatroom there are therefore different …
Not every server offers its chatroom administrators the same settings options; there are sometimes differences here.
Roles and rights of people present in the chat:
In unmoderated public chatrooms there is no visible difference for visitors and participants - only if e.g. due to garbage messages (“spam”) the chat is switched to “moderated”, writing rights are possible or not.
However, bridges should always be used with caution and are not always legal - it is better to use standardized interfaces.
Cross-reference: Are bridges and their use legal?
XMPP can also be used within an own network without internet access. The corresponding technology in the background is called “Bonjour”. A useful application for this are larger user groups in a closed network (LAN/WAN) such as work networks, lecture halls, dormitories. But also as a fallback level for internal company communication, if there is no internet connection due to outages/maintenance work at telecommunication providers.
… The development as well as the use and operation of an own messenger service in church and diaconia based on established and freely accessible protocols on federated servers would be the best solution in the view of the Data Protection Officer of the EKD and is therefore recommended.
Question: Why do calls not work in some constellations?
If I am on the same WLAN with my contact, we can make calls via the app - if I go online via mobile, it no longer works. The other person rings, but no conversation is established. Chatting works smoothly in any combination.
Since security settings (of firewalls or NAT) often take effect for external data traffic or there is appropriate hardware (e.g. Fritz!Box) between the two conversation partners, another service (STUN-/TURN-Server) is needed for direct connection establishment, which mediates the actual IP addresses required for direct transmission (without the respective chat servers). Otherwise calls outside the same WLANS will work only in some (rare) cases.
Whether the own server offers the help of STUN-/TURN can be seen here: https://compliance.conversations.im/test/turn (external)
Or directly e.g. in Conversations in the account settings over the menu the point “server details” activate. Here “XEP 0215 External Service Discovery” must be set to “yes”.
Other causes could be:
TOR is used or a throttled data speed. So 32/64kbit are theoretically sufficient after used up data volume - but are often throttled pulsed. In other words, you only get decent bandwidth for data transfer every few seconds, but then you have long dropouts, which means A/V doesn’t work.
Difference “Jabber” / “Cisco Jabber “
Even though both have the same origin, “Cisco Jabber” is not identical to the free “Jabber (XMPP)”. “Cisco Jabber” is an implementation of Cisco’s XMP protocol for enterprise communications using Cisco devices. It is not open source and has received its own extensions from the Cisco company, which are not available to the general public.
Nevertheless, it is technically possible to exchange messages based on the “free” protocol with “Cisco Jabber”. However, this federation (open collaboration) only works if the appropriate settings/shares are set up on the respective company’s own Cisco server.
Originally XMPP was developed by Jabber, Inc. Then handed over to XSF, and Jabber Inc was sold to Cisco.
The State of XMPP in 2019 (external) with information to:
The State of Mobile XMPP in 2016 (external) with information to:
Often it is not at all obvious that XMPP is used as a basis in the background. For example, there are really large applications with several million users, such as online games or messengers, which use an individually modified XMPP internally - but do not open it to the outside world.
Isode (external) is a company that develops commercial off-the-shelf products (client and server software) for secure messaging and directory systems for government, military and aerospace customers in over 150 countries. For mission-critical solutions, emphasis is placed on the use of international standards and open protocols (IMAP, XMPP, LDAP):
Graphic representation of military use
Source for graphic: https://www.isode.com/solutions/military-xmpp.html (external) - will be forwarded to actual site (external; 10.12.2022)
Excerpt from the NATO paper “MAJIIC - Multisensor Aerospace-ground Joint ISR Interoperability Coalition”:
”… In areas where no STANAG is available, such as Instant Messaging tools for distributed operator collaboration, the project will assess widely used commercial standards for potential use in coalition operations, such as the XMPP standard used in the Jabber chat tool …”
Source: https://www.nato.int/docu/update/2007/pdf/majic.pdf (external)
The US intelligence service also uses the standard protocol.
Open Source is free of charge - however, companies can be commissioned with development and the result is then available to the general public. There is also e.g. a job exchange around XMPP: https://xmpp.work/ (external)
Links to external information:
The “XMPP” system has been around for about 20 years. Nevertheless, or rather because of this, there are various opinions/viewpoints on this:
Jabber and the problems with OMEMO encryption: https://privacy-handbuch.de/handbuch_62.htm (external)
Why disroot relies on XMPP: https://disroot.org/en/blog/matrix-closure (external; English)
“XMPP simply can’t compete with the feature set of WhatsApp and its alternatives.”
(Original page is no longer online.)
Opinion by Signal (English-language) on 05/10/2016:
‘Reflections: The ecosystem is changing’ / ‘Reflections: The ecosystem is moving’ (external)
Opinion of XMPP.org (English language) on various prejudices:
Myths and legends about XMPP / Myths & Legends (external)
|Cooperation with Matrix through functioning bridges would be ideal. This would allow companies/agencies to enjoy the benefits of failsafe chat rooms and team chat capabilities internally - while still allowing for standardized message exchange to/from the outside world.|
For system comparison of standardized chat (XMPP) and Matrix: >> here <<