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.
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.
Security
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".
Availability of Features
Also, check the settings of your XMPP client, perhaps under plugins, preferences, options or settings. Use
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
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.
Security
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: