# XMPP extensions



## sidetone (Oct 1, 2020)

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.


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


----------



## sidetone (Oct 2, 2020)

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.


----------



## getopt (Oct 2, 2020)

sidetone said:


> How would one know certain XMPP extensions are enabled?








						XEP-0030: Service Discovery
					






					xmpp.org
				




See what XEPs servers may offer:





						Comparison of XMPP server software - Wikipedia
					






					en.wikipedia.org
				



Notice that the XEPs listed there may not be complete.

In constrained networks text messaging is the way to go. Right?

Also see XMPP Compliance Suites 2020:





						XEP-0423: XMPP Compliance Suites 2020
					






					xmpp.org


----------



## sidetone (Oct 2, 2020)

getopt said:


> 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.


----------



## sidetone (Oct 2, 2020)

sidetone said:


> How would one know certain XMPP extensions are enabled?





getopt said:


> XEP-0030: Service Discovery
> 
> 
> 
> ...



How does one use that XML/XMPP code from their XMPP client or otherwise to query available protocols? on both XMPP client ends, my client too. Also, which ones are being used (aside from security) when a chat is taking place.


----------



## getopt (Oct 2, 2020)

sidetone said:


> 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?


See





						XEP-0163: Personal Eventing Protocol
					






					xmpp.org
				




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.


----------



## sidetone (Oct 2, 2020)

getopt said:


> See
> 
> 
> 
> ...


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.


----------



## getopt (Oct 2, 2020)

There is a list of clients with the OMEMO feature:





						Are we OMEMO yet?
					

Tracking the progress of OMEMO integration in XMPP clients.



					omemo.top
				




Now what of that list is in the FreeBSD ports and usable?

net-im/profanity
net-im/gajim

net-im/psi from ports is lagging behind on what is advertised upstream.


----------



## sidetone (Oct 2, 2020)

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.


----------



## getopt (Oct 2, 2020)

sidetone said:


> How does one use that XML/XMPP code from their XMPP client or otherwise to query available protocols?


I.E with net-im/gajim you can see XEPs listed with  Accounts-> <your server> ->Extended-> Server information

Gajim has there also a XML-Konsole to watch what's going on the protocol level.


----------



## getopt (Oct 2, 2020)

sidetone said:


> from O'Reilly.
> 
> This is what was needed!


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


----------



## sidetone (Oct 2, 2020)

getopt said:


> 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.


----------

