XMPP extensions

How would one know certain XMPP extensions are enabled? or how would they be enabled? For security, for cool features, and for purposes of reducing overhead on constrained networks.

Core specifications carry the same XEP number throughout their entire cycle. Final and Draft extension protocols are suitable for production systems. These XEP (XMPP Extension Protocols) specifications can be found here, https://xmpp.org/extensions/index.html.

Here is a diagram of the process and hierarchy of XEP standards, https://xmpp.org/extensions/xep-0001.html#approval-std.

Some XMPP extensions are only supported for production use on commercial products and/or for organizational implementations. Often these extensions are categorized as Deferred.

Reducing bandwidth

An important feature would be ensuring that compression is enabled both ways. XML leads to duplicated data for elements and attributes. That additional XML data is great for 1 way documents, but not for real-time conversations when any party has a slow or unreliable network. Compression may solve this by making transmission of XML data negligible with the messages. However, compression within XML elements may perhaps only be able to compress data contained in those elements.
  • XEP-0138: Stream Compression (Final)
  • XEP-0229: Stream Compression with LZW (Final)

Is there an XMPP extension that can make a more direct P2P connection route after the handshake, than passing each message through both user hosting servers? Negotiating a connection/handshake through all XMPP servers is a must to prevent or reduce spoofs. Aside from offline messages, which may be better being held on the servers used until the client can receive the message.

TURN/STUN was mentioned as a way to decouple from XMPP servers for more direct communication. However, TURN/STUN appears to be for Jingle working through NAT, and I couldn't find an extension related to this at https://xmpp.org/extensions/index.html.

The XEP-0361 (Zero Handshake Server to Server Protocol) extension was deferred. It was intended to reduce data overhead. However, commercial products may have this specification.

When all parties have reliable Internet, then the additional bandwidth and distance is inconsequential. This is about being able to use XMPP worldwide including for those with low speed Internet and in countries with poor Internet infrastructure (constrained networks). A messaging application shouldn't add additional load to such a network, and the connection shouldn't drop regularly for times of the day. A connection dropping may be unavoidable, but the messaging should be minimally impacted as can be.

For High Frequency (HF) Radio, the XEP-0365 extension looks really cool: https://www.isode.com/whitepapers/low-bandwidth-xmpp.html. This one is deferred. However it's usable as experimental and perhaps in military organizational use and commercial use. Maybe not for this cool feature, but how would another cool extension be enabled and ensured that it's being used.


As for security, some XMPP clients have the option to make encryption mandatory for chats. OTR is another security feature than can be enabled to ensure both sides use it. A client must come with OTR to make use of it, or a plugin (if available) must be installed and enabled to make use of chats if one party chooses. OTR is also intended to prevent spoofs.

OTR is used in some XMPP clients, despite that the only OTR mention is that of "deferred".
  • XEP-0378: OTR Discovery (Deferred)

Availability of Features

pkg info example-xmpp-client can be used to find out which options are compiled into an XMPP client, and some can indicate built-in features.

Also, check the settings of your XMPP client, perhaps under plugins, preferences, options or settings. Use psearch -c net-im -s <search terms> to search for additional XMPP extensions.

From https://xmpp.org/about/myths.html, "XMPP is designed to be extensible, and many extensions have very broad deployment." Some features are already enabled throughout, but I need to know that they are regardless of messenger client and on both ends for certain features. For some users with other OS's, it would have to be seen if the other side is using the same capabilities.

Additional Common Extensions
  • chat state notification - available, typing, paused typing
  • XHTHML-IM - light set of XHTML inserted into XML
    • doesn't have a head section, thus reducing potential for malware
    • vulnerabilities can still enter through attachments
  • vcard - profile that can be queried from server
  • privacy/block lists - block lists and privacy settings
  • receipts - receive a receipt when message has been received
  • message archiving
  • service discovery protocol - find services on a server, such as chat services
  • advanced message processing - how message will be sent to client device
  • extended stanza addressing - send a message to multiple recipients without open chat
  • MUC protocol - multi-user chat
Last edited:
  • Like
Reactions: a6h
Jingle extensions

Draft (production environment) status
  • XEP-0166: Jingle
  • XEP-0167: Jingle RTP Sessions
  • XEP-0176: Jingle ICE-UDP Transport Method
  • XEP-0177: Jingle Raw UDP Transport Method
  • XEP-0260: Jingle SOCKS5 Bytestreams Transport Method
  • XEP-0261: Jingle In-Band Bytestreams Transport Method
  • XEP-0262: Use of ZRTP in Jingle RTP Sessions
  • XEP-0266: Codecs for Jingle Audio
  • XEP-0293: Jingle RTP Feedback Negotiation
  • XEP-0294: Jingle RTP Header Extensions Negotiation
  • XEP-0320: Use of DTLS-SRTP in Jingle Sessions
  • XEP-0338: Jingle Grouping Framework
  • XEP-0339: Source-Specific Media Attributes in Jingle
There are more XEP specifications in the Deferred category.

There's no specifications in Final and Experimental for Jingle, at this time.
  • Like
Reactions: a6h
In constrained networks text messaging is the way to go. Right?
When there's natural disasters or other localized emergencies (which often results in constrained networks), they recommend using text messaging than phone (they're referring to non-secure SMS texts). A text message is sent, and a connection doesn't have to be held open (requiring more data, also for the duration of the call). More information passes through texts using less data. More texts pass through for a given time than calling. Texting is more efficient for communicating when the importance is simply the message. As the information comes available for a person to send it, or when it's ready to be sent, or to send a lot of information at once.

During rush hour as well, phone calls often drop off, have static or don't go through.

Texting (when replacing non-essential voice calls) takes a lot of relief off of constrained networks. Normally, a few things need to be communicated, which doesn't require a voice conversation. Sometimes voice communication is required, but it isn't for all communications.

On XMPP, text messaging may take up less bandwidth than emails. The presence setting could be the thing that causes use of higher bandwidth in constrained networks. How often does data have to be sent to indicate presence of the users on the other end of an XMPP chat?

When an XMPP message with additional XML data is sent once, that's actually a lower overhead than email. For multiple short messages, it may be weight on constrained networks. Also, when the servers are far away, and all data must be passed through them for communication, that's another constraint. For a conversation, bandwidth may be much higher to make a difference on constrained networks.
  • Like
Reactions: a6h
On XMPP, text messaging may take up less bandwidth than emails. The thing that could cause a lot of bandwidth in constrained networks, is the presence setting. How often does data have to be sent to indicate presence of the users on the other end of an XMPP chat?

In comparison with OTR, the OMEMO protocol offers many-to-many encrypted chat, offline messages queuing, forward secrecy, file transfer, verifiability and deniability at the cost of slightly larger message size overhead.

Offline messages queuing is like sending emails. You send it to your server. There it is stored and queued for further delivery.

In comparison with OTR, the OMEMO protocol offers many-to-many encrypted chat, offline messages queuing, forward secrecy, file transfer, verifiability and deniability at the cost of slightly larger message size overhead.
So, each event is one message at a time.

A song playing isn't important on constrained networks. Maybe an event message isn't sent when the song stops or they figure when it ends based on the time length is sent on the first event. Maybe an event is sent when a song stops playing.

For online presence, if that event gets dropped, perhaps it assumes the presence based on the last event received. Pinging (more data on a constrained network) every so often couldn't do much better than that, except to confirm if the user is still there or if the conversation got dropped.
There's a book available for XMPP!

XMPP: The Definitive Guide - Building Real-Time Applications with Jabber Technologies from O'Reilly.

This is what was needed!

Their Asterisk book is free online by the publisher/author. I don't know if this one is. Then, I bought a paperback copy from a book store, then learned about the online version offered by Digium. The Asterisk book did touch on XMPP.

The title of the chapter is Asterisk and Jabber (XMPP)

According to its Appendix, jabber.conf is used to configure XMPP on Asterisk.
I doubt that it will be useful for your problem as it is from 2009 thus being pretty old.
Better eat what you can find on https://xmpp.org
They're still good books. Current information has to be replaced by what's at xmpp.org. A lot of older information is relevant, and hasn't been replaced.