XMPP/Jabber components: focus is non-viral licenses

[sidetone]

XMPP/Jabber components which use non-viral licenses, or which allow dynamic linking from.

XMPP libraries	License	About	Framework
net-im/loudmouth	LGPL2.1+	extensible, lightweight; client library; console clients net-im/freetalk & net-im/mcabber rely on it; also used by irc/irssi-xmpp & net-im/telepathy-gabble; doesn't come with OMEMO	C
net-im/qxmpp	LGPL2.1+	client & server library; used by net-im/kaidan; has Jingle support; installs security/libomemo-c by default	QT & C++
net-im/libstrophe	MIT	minimal, uses minimal XML parsing library; choice of libxml2 or expat; net-im/profanity depends on this	C
net-im/libmesode	MIT	previous fork of libstrophe; version depreciated upstream; suggests to use libstrophe; had removed MS Windows support, didn't need gmake, only had expat; provided extra TLS functionality; profanity once worked on this	C
net-im/py-slixmpp	MIT	fork of sleekxmpp	Python

XMPP Clients	License	Comment	Framework
net-im/xmpp-client	BSD 3-Clause	has OTR support	Go
net-im/jsxc	MIT	has: video calls, file transfers, encrypted communication	Browser based; Javascript

XMPP server	License	Comment	Framework
net-im/prosody	MIT	flexible, light, expandable, modern	Lua
net-im/openfire	Apache 2.0	security and performance focused; Real time Collaboration (RTC); uses plugins for expansion	Java; OpenJDK

XMPP misc	License	Comment	Framework
net-im/biboumi	ZLIB	XMPP gateway to IRC; depreciated port; relied on deleted botan2	Python; used SQLite3 or PostgreSQL
net-im/matterbridge	Apache 2.0	bridge to multiple protocols including hipchat which uses XMPP; used in gaming messaging too	Go
net-im/telepathy-gabble	LGPL2.1+	Jabber connection manager
net-im/telepathy-salut	LGPL2.1+	Link-local connection manager
net-im/telepathy-*	LGPL2.1+	Telepathy framework, lets people know presence settings	QT
textproc/iksemel	LGPL2.1	XML parser library; used by Asterisk	XML
net-im/prosody-modules	MIT	module components for prosody server
net-im/jitsi-prosody-plugins	Apache 2.0	prosody plugins for Jitsi
net-im/p5-Net-Jabber	LGPL2.0+	Perl access from Jabber to IRC or other services	Perl
net-im/p5-Net-XMPP	LGPL2.1	Perl access to XMPP	Perl

A lot of other p5 Perl components are dual licensed between GPL1 and ART10, which ART10 is considered to not have clearly defined rules for linking.

Pidgin/libpurple libraries are under GPL, and not under LGPL or to another non-viral license, which makes them complicated to link to.

As for client end programs, GPL is fine to use. The importance is that the libraries and other components allow wider use of them through dynamic linking. LGPL, other file-based license, and permissive licenses allow that type of dynamic linking for client end programs to use.

It seems that libraries not using LGPL2, Apache2.0 (with GPL2 linking exceptions or dual licensed with LGPL2), or permissive licenses hinders compatibility to other clients or other components which depend on them.

Aside from licensing, different programs for XML parsing are used. There could be more standardization here, but this is a minor detail, and makes no difference in performance, because XML is an open standard with one implementation.

Prosody under MIT gives more freedom of use of the server.

More: Thread xmpp-basics-security-constrained-networks.77220

 

[sidetone]

Security: OMEMO, OTR & PGP

XMPP security	License	Comment	Framework
security/libomemo	MIT	XEP-0384 v0.3.0; uses textproc/mxml; lurch library for pidgin depends on it; siacs OMEMO	C, SQLite3 optional
security/libotr	LGPL2.1	bitlbee, pidgin & profanity rely on this; version 4.x last released in 2016, but still used for OTR
security/libotr3	LGPL2.1	obsolete; a few deleted ports once relied on this: climm, kopete-otr, py-otr; version 3.x
security/py-potr	LGPL3	obsolete version 1.x; needed for weechat-otr which is for IRC rather than XMPP	Python

Other OMEMO implementations are under GPL. For reference, different OMEMO versions don't work with each other.

While XMPP without encrypted communication is standardized for compatibility across clients, OTR and different OMEMO protocols aren't compatible with each other. It's not advertised that XMPP clients use different OMEMO versions, so users are unaware why OMEMO doesn't often work between different clients.

Implementation	Versions	Namespaces	Comments	Libraries
OTR (older)	1.x & 3.x	?	weechat for IRC also uses OTR 1.x	security/py-potr (1.x), security/libotr3 (3.x)
OTR (latest)	4.x	urn:xmpp:otr:0	4.x is the last major version from 2016	security/libotr, pidgin-otr
OMEMO:0	0.0.1 - 0.1.0	urn:xmpp:omemo:0	negligible use; obsolete; used Olm, came from Signal
Siacs OMEMO	0.2.0 - 0.3.0	eu.siacs.conversations.axolotl	most widely adopted, stewarded by Conversations.im	security/libomemo, security/py-omemo-dr, libomemo-c overlaps with 0.3.0
OMEMO:1	0.4.0 - 0.7.0	urn:xmpp:omemo:1		security/libomemo-c
OMEMO:2	0.8.0 - 0.9.0 (as of 2025)	urn:xmpp:sce:1 (for stanza content encryption) urn:xmpp:omemo:2 urn:xmpp:omemo:2:bundles urn:xmpp:omemo:2:devices	named Twomemo
OXIM	0.2.0	urn:xmpp:openpgp:0	OpenPGP for Instant Messenger (OXIM); XEP-0374; obsolete; https://conversations.im/omemo/
OpenPGP	?	urn:xmpp:openpgp:0 (modern version); jabber:x:encrypted (obsolete version)	Difficult to use, but considered most secure, not necessary for most purposes; https://conversations.im/omemo/	many implementations available, depends on messenger dependency

Many of the ports listed are under GPL, but the utmost importance here is functionality for available libraries.

There's lack of ecosystem wide standardization and lack of compatibility of encryption between clients due to different OMEMO implementations. OMEMO libraries aren't standardized, where different implementations can rely on a basic OMEMO library. Then, it's important for the version numbers of OMEMO to be documented of what works together, and written out in the library name. This isn't widely done. Not widely known if a client exists which has multiple OMEMO versions be available to be compatible with other clients limited to specific OMEMO versions.

It makes sense for a client to be compatible with OTR 4.x, siacs OMEMO and optionally a more recent OMEMO. The lack of understanding that there were OMEMO versions caused confusion as to why different clients didn't work together. For reference: Conversations.im uses siacs OMEMO. Uncertain if siacs OMEMO is compatible with clients which have newer OMEMOs.

Prosody through modules supports siacs OMEMO and OTR. Core modules are listed at https://prosody.im/doc/modules.

For a past discussion of OMEMO implementations: Thread omemo-for-xmpp-on-freebsd.90599.

Refs

• https://xmpp.org/extensions/xep-0384.html
• https://wiki.xmpp.org/web/Tech_pages/OMEMO
• https://conversations.im/omemo/
• https://otr.cypherpunks.ca/
• https://xmpp.org/extensions/xep-0364.html
• https://otr.im/
• https://modules.prosody.im/mod_omemo_all_access
• https://modules.prosody.im/mod_require_otr
• https://xmpp.org/extensions/xep-0373.html
• https://xmpp.org/extensions/xep-0374.html
• https://xmpp.org/extensions/xep-0027.html

 

[sidetone]

OMEMO & OTR by dependency

Security Dependency	Implementation	Library	Client
security/libomemo	Siacs OMEMO	net-im/lurch, net-im/libpurple	net-im/pidgin, net-im/finch
security/libomemo-c	OMEMO:1, some overlap with Siacs OMEMO	net-im/qxmpp	net-im/kaidan
security/py-omemo-dr	Siacs OMEMO		net-im/gajim
security/py-pyaxo	OMEMO type?		net-im/py-unmessage
security/libotr	OTR	net-im/pidgin-otr, net-im/libpurple	net-im/profanity, net-im/mcabber, net-im/pidgin, net-im/finch
security/libotr3 (obsolete version)	OTR	deleted: kopete-otr, py-otr	deleted: climm
security/py-potr	OTR		irc/weechat-otr
net-im/tkabber-plugins	OTR		net-im/tkabber
built in	OTR		net-im/jsxc
possibly builtin	OMEMO type?		net-im/xmpp-client
possibly combination of net/libsignal-protocol-c, graphics/libqrencode, or built in	OMEMO type?		net-im/dino
possibly built in	OMEMO type?		net-im/xmpp-client
possibly built in	OMEMO type?		net-im/profanity
security/py-python-axolotl	OMEMO type?	no longer used for IM	on FreeBSD anymore

In this table, not all libraries represent the client. Some have a client or library that directly use the security dependency. finch and pidgin also rely on libpurple, pidgin-otr, and/or lurch. Other ports in the same row don't rely on those libraries.

OTR is still useful as a legacy way of encrypting chats. Also, it's standardized, and still useful, when the purpose is merely securing chats, when it's enough to accomplish that purpose. It's also still useful for when clients which use different implementations of OMEMO can't use chat encryption together.

There are several libsignal libraries related to OMEMO in ports: net/libsignal, net-im/libsignal-client, net-im/libsignal-node, security/axc. libsignal is used for XMPP, even though the original implementation is from Signal, which its named after.

Also: https://omemo.top/

Other OMEMO backends not in ports

Backend	Implementation	Namespace	Framework/Language	License
https://github.com/Syndace/python-twomemo	OMEMO:2	urn:xmpp:omemo:2	Python	MIT
https://github.com/Syndace/python-oldmemo	Siacs OMEMO	eu.siacs.conversations.axolotl	Python	AGPL
https://github.com/Syndace/python-omemo	various	uses other backends for different implementations of OMEMO	Phyton	MIT
https://github.com/mierenhoop/picomemo	OMEMO:2 Siacs OMEMO	eu.siacs.conversations.axolotl urn:xmpp:omemo:2	C	ISC
https://github.com/jomemo/jomemo	?	?	Java	Apache 2.0
https://github.com/wstrm/omemo-utils	for media sharing	?	C	MIT

Imagine if Picomemo were used as a backend for siacs OMEMO and OMEMO:2, so siacs OMEMO would be the standard fallback OMEMO. Then libotr would be used as additional fallback as a valid but legacy chat security mechanism. These are permissively or weak copyleft licensed. Then, there are file based and permissively licensed programs which are libraries for XMPP would could be forked to use those. Then, have file-based/permissive licensed command line clients, curses clients, and basic GUI clients. The frontend for GUI clients can be weak copy left, strong copyleft or Apache 2.0. Even existing GUI clients forked for use with those back ends and libraries. Gtk is also LGPL so much can be done with that as well to allow the license used unmodified for programs which use it.

 

[sidetone]

For widespread compatibility with odds that your client will work with what someone else is using, Siacs OMEMO is the one to use. Also, clients which were forked from Conversations tend to use Siacs OMEMO.

For open RFC standardized OMEMO, use OMEMO:2, known as Twomemo. Twomemo has better security than Siacs OMEMO. It would be better if clients could switch to either of the two depending on the best implementation the other communicating client has available. At this time, it seems like nothing in FreeBSD ports uses Twomemo, as everything uses either Siacs or OMEMO:1.

As a library, Picomemo is the way to go, because it has a permissive license, and it supports Siacs OMEMO and Twomemo. Hardly anything implements this software at this time.

I believe that OTR is needed as additional fallback on all clients due to it having a single version for compatibility regardless of being legacy. All OTR applications should use the highest version library, not libotr 3.x. Standardized legacy has its benefits. libotr is stewarded by https://otr.cypherpunks.ca. It's to consider that OTR is meant for 1:1 chats, while OMEMO can support group chats.

Climm, Kopete, Kadu, and irssi-otr which used otr have been depreciated upstream and thus in ports. Many other clients and libraries which have used otr have been canceled upstream as well.

• https://otr.cypherpunks.ca
• https://otr.cypherpunks.ca/otr-wpes.pdf
• https://soatok.blog/2024/08/04/against-xmppomemo/ has clues to find out which version is supported by a client.

 

[sidetone]

There's a project to add MLS from MIMI to XMPP: https://nlnet.nl/project/XMPP-MLS/. MIMI is an upcoming open standard for messaging, https://datatracker.ietf.org/group/mimi/about/, which has been mentioned in the forums before. Matrix is a major part of building the MIMI standard. https://www.rfc-editor.org/rfc/rfc9420.html is the MLS RFC

List of Omemo implementations by version: https://wiki.xmpp.org/web/index.php?title=Tech_pages/OMEMO&mobileaction=toggle_view_desktop

Siacs OMEMO, which Conversations uses and is most widely used OMEMO implementation, uses the Signal protocol. This version lacks security for metadata. https://conversations.im/omemo/audit.pdf is an audit for Siacs OMEMO.