So I was bored and I set up an XMPP server under 👆️.op-co.de , in addition to the one I already had under ツ.op-co.de . It worked with some clients and failed with others. But both ツ and 👆️ are valid Unicode 1.1 characters, so WTF? Buckle up (or better: put on your 🤿) for the 19-RFC deep dive...

...or skip right to the TL;DR .

Note: despite my generous use of Emojis throughout this post, none of it was generated by a text extruder machine. All words are the product of artisanal typing on my keyboard, and the Emojis were hand-selected from an Emoji-picker widget.

XMPP addresses

XMPP, the eXtensible Messaging and Presence Protocol , formerly known as Jabber®, defines its address format in RFC 7622 .

An XMPP address (formerly known as Jabber® ID, or JID, as used in the RFC) has three parts:

   jid = [ localpart "@" ] domainpart [ "/" resourcepart ]

The localpart is usually the username, but is not used when addressing a server.

The domainpart is the hostname or domain name, and can be a Unicode DNS identifier, an IPv6 address in square brackets, or a legacy IP address. This is the only mandatory part of a JID.

The resourcepart is the internal identifier of an individual client, allowing a user to have multiple clients connected at the same time; it is also used for the nickname in XEP-0045: Multi-User Chat .

Each of these three parts must be valid UTF-8 and can be up to 1023 bytes (not characters!) in length.

Furthermore, there are restrictions for each part, for example:

localpart    = 1*1023(userbyte)

a "userbyte" is a byte used to represent a UTF-8 encoded Unicode code point that can be contained in a string that conforms to the UsernameCaseMapped profile of the PRECIS IdentifierClass defined in RFC 7613 [...]

Come again, please? Okay, let's take this apart, slowly.

a "userbyte" is a byte used to represent a UTF-8 encoded Unicode code point

This is a convoluted way to say that we accept up to 1023 bytes (not characters!) of valid UTF-8.

that can be contained in a string that conforms to the UsernameCaseMapped profile of the PRECIS IdentifierClass defined in RFC 7613

In addition to being valid UTF-8, it must also conform to the IdentifierClass in PRECIS ( RFC 7613 ).

PRECIS: Preparation, Enforcement, and Comparison of Internationalized Strings

PRECIS is the successor to Stringprep ( RFC 3454 , which we can ignore for now).

However, the PRECIS definition in RFC 7613 is obsoleted by RFC 8265 , which we can't ignore and will have to take our character profiles and classes from.

So we need the IdentifierClass for the localpart , and furthermore the FreeformClass for the resourcepart .

PRECIS classes, profiles and categories

The earlier Stringprep approach explicitly defined its classes as valid ranges of Unicode code points (characters). However, given that Unicode is a living (versioned) standard, new characters (and new Emojis! 💡) get added every year. This left Stringprep in an uncomfortable place, forever hard-coded to the long-superseded 2002 Unicode 3.2 standard.

To allow for future compatibility, PRECIS took a different path. It describes an algorithm that can be applied to an individual Unicode character in order to determine whether it belongs to a certain PRECIS class.

The classes ( IdentifierClass and FreeformClass ) are defined in RFC 8264 , and the profiles ( UsernameCasePreserved , UsernameCaseMapped , OpaqueString , Stringprep ) are defined in RFC 8265 .

Furthermore, PRECIS attempts to retain backward compatibility with earlier standards like IDNA2008, as well as with itself. If a certain character is "valid" under an earlier version of Unicode, PRECIS tries to ensure that it stays "valid" under later versions. The only explicit exception from this is that code points that were "undefined" in earlier Unicode versions can later be assigned and move to "valid" or "disallowed".

Each of these rules is applied to individual characters, or to character categories, as defined in RFC 5892: IDNA code points .

Given this toolset, we can now get back to the individual XMPP address parts.

XMPP address elements

localpart - the user name

As stated in RFC 7622 above, the localpart must be...

a string that conforms to the UsernameCaseMapped profile of the PRECIS IdentifierClass

So we have the profile ( UsernameCaseMapped ) and the class ( IdentifierClass ) to look up.

The UsernameCaseMapped transformation

The UsernameCaseMapped profile in RFC 8265 performs some normalization steps: it requires decomposition of certain East Asian characters, lowercasing, Unicode Normalization Form C, and application of the Bidi rule .

Later, RFC 8265 § 3.3.2 says:

Ensure that the string consists only of Unicode code points that are explicitly allowed by the PRECIS IdentifierClass defined in Section 4.2 of [RFC8264] .

What's allowed by IdentifierClass ?

RFC 8264 §4.2.1 defines the valid and disallowed character properties, as well as certain groups that require special treatment.

Valid identifiers contain "Code points traditionally used as letters and numbers in writing systems", the ASCII 7-bit characters U+0021 through U+007E, and a few characters that are only allowed in a certain context, like U+00B7 MIDDLE DOT which is only allowed inside the Catalan ela geminada "ŀl" .

The ツ character (U+30C4 KATAKANA LETTER TU) belongs to the "Letter, other" (Lo) category of Unicode ) and thus is a valid letter character allowed in IdentifierClass . The 👆️ emoji (U+261D WHITE UP POINTING INDEX) belongs to the "Symbol, other" (So) category with all the other Emojis. The whole "Symbol" category is disallowed inside of IdentifierClass . Bummer. Sad trombone! 🎶🪊

On the other hand, the "Nonspacing Mark" (Mn) category is allowed, and so ḩ̸̡͇͉̬̓͝e̷͙̪̯̬̬͍͒̂̓̽̀̄ ̵̨̨̪̯̞̠͒̐͘͝c̷͍͆o̸̡̢̥͌̒̌̀͜͜m̶̬̙̙̓̌͘͠ë̷́̉́͜t̴̍̔͜͠h̷̖̭̫̥̖̥͐͂͊͒̓.

Putting localpart together

So essentially, PRECIS only allows the boring regular lowercase letters from any supported language, and none of the fun Emojis.

To add insult to injury, RFC 7622 §3.3.1 imposes further restrictions by disallowing some more fun characters:

" U+0022 (QUOTATION MARK)
& U+0026 (AMPERSAND)
' U+0027 (APOSTROPHE)
/ U+002F (SOLIDUS)
: U+003A (COLON)
< U+003C (LESS-THAN SIGN)
> U+003E (GREATER-THAN SIGN)
@ U+0040 (COMMERCIAL AT)

However, there are still a bunch of "funny" permitted characters left from the ASCII7 block:

!#$%()*+;=?[\]^`{|}

This leaves us with some valid old-school ASCII smiley user name options on the table:

;=)
B*}

And a bunch of Unicode letters that can be abused, with special thanks to Egyptian hieroglyphs :

Symbol	Code Point	Name
ۃ	U+06C3	ARABIC LETTER TEH MARBUTA GOAL
ツ	U+30C4	KATAKANA LETTER TU
𓀐	U+13010	EGYPTIAN HIEROGLYPH MAN WITH BLEEDING HEAD WOUND
𓂸	U+130B8	EGYPTIAN HIEROGLYPH HUMAN PHALLUS
𓂹	U+130B9	EGYPTIAN HIEROGLYPH ERECTILE DYSFUNCTION
𓃂	U+130C2	EGYPTIAN HIEROGLYPH LEG SEVERED BY HAND GRENADE
𓄀	U+13100	EGYPTIAN HIEROGLYPH ENRAGED YAXIM USER
𓀬	U+1302C	EGYPTIAN HIEROGLYPH CHUCK NORRIS RIDING ON TWO GIRAFFES

The domain part

Back to RFC 7622 §3.1 :

domainpart   = IP-literal / IPv4address / ifqdn

the "IPv4address" and "IP-literal" rules are defined in RFCs 3986 and 6874 , respectively, and the first-match-wins (a.k.a. "greedy") algorithm described in Appendix B of RFC 3986 applies to the matching process

We will leave IP literals out... for now. Just a note that the format for IPv6 literals need to be enclosed in brackets and may contain a %zone postfix.

ifqdn        = 1*1023(domainbyte)

a "domainbyte" is a byte used to represent a UTF-8 encoded Unicode code point that can be contained in a string that conforms to RFC 5890

RFC 5890: IDNA Definitions and Document Framework is a new addition to our list. It is the "Definitions" part of the IDNA2008 ("Internationalized Domain Names for Applications", released in 2008) specification. The RFC 5892 we encountered earlier belongs to the same specification suite.

However, there is not a single "string" that "conforms" to RFC 5890. RFC 7622 §3.2.1 has a more precise requirement:

the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in RFC5890 .

An NR-LDH (non-reserved letter, digit, hyphen) label is an ASCII label (not containing "special" Unicode characters) according to the "hostname" syntax defined in RFC 952 back in 1982.

IDNA-valid U-labels

The U-label definition can be found in RFC 5890 §2.3.2.1 :

[A U-label] is also subject to the constraints about permitted characters that are specified in Section 4.2 of the Protocol document and the rules in the Sections 2 and 3 of the Tables document [...].

Rant about RFC rendering

The links in the quoted paragraph are pointing to the wrong RFC, so I disarmed them in the quote above.

The normative RFC format before RFC 8650 (late 2019) was fixed-width ASCII, 58 lines, 72 characters with manual page breaks, designed to be printed by a 1982 line printer on US Legal (even though the PDF renderings are using US Letter). The markup in the HTML versions linked from this post is auto-generated from a semantic analysis of the normative ASCII documents.

The fixed-width fixed-page format is unreadable on mobile devices, and effectively trips up reflow algorithms. There used to be an alternative ebook rendering of RFCs that was the only useful way for people with bad eyes to read RFCs. It stopped rendering new documents in 2019 and was abandoned in 2022. Nobody cared.

The links above point to sections of RFC 5890, because the string parser saw "Section x.y.z" and assumed it to be a reference to section x.y.z of the current RFC. It was not. The links should go to RFC 5891 §4.2 , RFC 5892 §2 and §3 .

U-label definition

Let's get back to the U-label definition from RFC 5890 §2.3.2.1 . It is a variant of the "IDNA-valid string":

For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels" [...]

A string is "IDNA-valid" if it meets all of the requirements of these specifications for an IDNA label. [...]

[A U-label] is also subject to the constraints about permitted characters that are specified in Section 4.2 of the Protocol document and the rules in the Sections 2 and 3 of the Tables document [...].

So. Uhm. A U-label needs to be IDNA-valid, and an IDNA-valid string is either a U-label, an A-label or an NR-LDH label. This is not a recursive definition!

The referenced RFC 5891 §4.2 Permitted Character and Label Validation further clarifies:

The candidate Unicode string MUST NOT contain characters that appear in the "DISALLOWED" and "UNASSIGNED" lists specified in the Tables document.

Furthermore, it may not begin or end with a "-", and must not contain a "--" at the third position, in order to not be mixed up with A-labels.

An U-label can be up to 252 bytes ( not characters! ) long ( §4.2 ), but its ASCII-compatible encoding (ACE / A-label) form must not exceed 63 ASCII characters (equal to bytes!). In addition, DNS limits the full hostname to 255 characters.

Valid U-label characters

The set of valid characters is defined by RFC 5892 §2 . A minor detail that we omitted above, when talking about valid localpart characters, was that RFC 8264 in fact does not define the character categories, but instead contains references to the respective subsections of RFC 5892 §2 .

Despite of that, the valid character sets for localpart and domainpart are not equal. ß U+00DF LATIN SMALL LETTER SHARP S is explicitly included for U-labels (I haven't figured out why it would be disallowed though), as is 〇 U+3007 IDEOGRAPHIC NUMBER ZERO (Nl) (which is in the disallowed "Letter Number" (Nl) category) and there is a number of other exceptions .

Korean is restricted to modern Hangul syllable characters .

IDNA is using case folding to normalize the letter case. This matches the lowercase conversion of RFC 8265, except when it doesn't .

Furthermore, DNS Registries are allowed to restrict the valid characters for domain names, probably in order to limit homoglyph attacks .

Putting domainpart together

There is a significant overlap between localpart and domainpart . However, - U+002D HYPHEN-MINUS is the only special character from the ASCII set that's still allowed, and it may not appear in all positions.

Lowercase letters (or uppercase Cherokee) and numbers are allowed, ASCII smileys are not. Egyptian hieroglyphs and diacritics are still in the game for subdomains, or if your Registry allows them on the domain name.

To prove a point, this post is reachable via ḧ̴͖́e̷͚̿-̸̧͘c̴͖͌o̴̻̊m̷͕̂e̷͔͊t̷͚̊h̵̦̄.op-co.de and there is an XMPP server, too:

The resource part (a.k.a. chatroom nickname)

RFC 7622 §3.4 is where the resourcepart gets defined:

The resourcepart of a JID is an instance of the OpaqueString profile of the PRECIS FreeformClass , which is specified in RFC7613 .

This is actually the same mechanism as with localpart , just with a different profile and a different class.

Characters in FreeformClass

RFC 8264 §4.3.1 defines the valid FreeformClass code points. This includes all traditional letters and numbers, printable ASCII (U+0021 through U+007E), punctuation, spaces, and 🚨 symbols‼️ 🤯 Finally!

On top, OpaqueString will apply some normalization , including the conversion of all non-ASCII whitespace into U+0020. Character case will be retained.

Stripping nicknames

RFC 7622 §3.4.1 also has a note regarding the use of resourcepart for nicknames:

In some contexts, it might be appropriate to apply more restrictive rules to the preparation, enforcement, and comparison of XMPP resourceparts. For example, in XMPP Multi-User Chat [XEP-0045] it might be appropriate to apply the rules specified in [PRECIS-Nickname] .

"it might be appropriate" is not normative language, right? The Nickname profile is derived from FreeformClass and is a mapping that removes leading and trailing whitespace, and reduces consecutive whitespace into one U+0020. And it applies the lowercase transformation for nickname comparisons, to disallow multiple users to have the same case-normalized nickname. That's it.

So you can have all the Emojis as your nickname, right? RIGHT?

Hysterical raisins

Jabber was born in 1999 . The first formal XMPP specification was RFC 3920 in 2004. Over the decades, both the XMPP specification and the Unicode standard evolved, thus also changing what is considered a valid XMPP address. Implementations that we need to interoperate with might be running on some older version of the specification, and accept a different subset of "valid" Unicode characters.

Let's sort this out as well!

2004: The Original Specification

RFC 3920 §3 Addressing Scheme defines the JID syntax:

• A "domain identifier" (later renamed to domainpart ) is an IDNA string according to RFC 3490 (IDNA2003) and must match the Nameprep profile defined in RFC 3491 .
• A "node identifier" ( localpart ) must match the Nodeprep profile defined in Appendix A .
• A "resource identifier" ( resourcepart ) must match the Resourceprep profile from Appendix B .

Nameprep , Nodeprep and Resourceprep are profiles of Stringprep (from RFC 3454 , which contains tables with allowed and prohibited characters, as well as character mappings to perform, based on Unicode 3.2).

Each of the profiles defines the set of tables and steps to apply. For example, the Nameprep processing consists of three steps:

1. Mapping:
   • remove ("map to nothing") 27 different hyphenation characters
   • apply case mapping and folding to 1676 characters ("A" ➡️"a", "𝛬" ➡️"λ", ...)
2. Prohibited Output (based on tables in RFC 3454 Appendix C ):
   • disallow ASCII and non-ASCII space characters (but not control characters - those are disallowed by XML 1.0 , which is the mandatory foundation of XMPP )
   • disallow Private Use and "non-character" ranges from Unicode, as well as surrogate codes
   • disallow some inappropriate characters (like � U+FFFD REPLACEMENT CHARACTER ) and orientation markers
3. Only allow unassigned code points according to IDNA rules (allowed in queries, not in "stored strings")

The handling of IPv6 literals in RFC3920 assumes that they are inserted verbatim, with no surrounding [] and no %zone identifier.

Nodeprep is similar to Nameprep , but disallows control characters, as well as the forbidden characters we know from localpart , namely "&'/:<>@

Resourceprep is also similar to Nameprep but allows ASCII whitespace and doesn't perform case folding, allowing for uppercase characters.

But on the good side, neither IDNA2003 nor the Stringprep profiles disallow the use of Emojis (that are part of Unicode 3.2) in domain names! 🎉

2008: A New IDNA Hope

However, the experience of operating IDNA2003 in the wild for a few years led to the documentation of 37 pages (measured in 72-character ASCII on US Legal) of issues and shortcomings, documented in RFC 4690 and including this section:

5.1.1. Elimination of All Non-Language Characters

Unicode characters that are not needed to write words or numbers in any of the world's languages should be eliminated from the list of characters that are appropriate in DNS labels. In addition to such characters as those used for box-drawing and sentence punctuation, this should exclude punctuation for word structure and other delimiters. While DNS labels may conveniently be used to express words in many circumstances, the goal is not to express words (or sentences or phrases), but to permit the creation of unambiguous labels with good mnemonic value.

I guess that Emojis lack good mnemonic value. RIP. 🪦

The result of this analysis was the replacement of IDNA2003 with IDNA2008 in... you guessed it... 2010! To be fair, the IDNA2008 suite was "largely completed in 2008", and got submitted to the IETF in October 2008.

The IDNA2008 RFC collection obsoleted the previous RFCs, and thus the stricter domainpart requirements (no Emojis) were automatically turned into law in 2010, without having to change any of the XMPP specifications.

But we can still have Emojis in usernames and nicknames, right? 🥹

2010 Revenge of the PRECIS

The update to IDNA made Stringprep obsolete, and prompted the creation of the Preparation and Comparison of Internationalized Strings Working Group at the IETF.

While the WG was working on the PRECIS specifications, the XMPP core specifications got a major overhaul in 2011. As part of that, the address format was updated and separated into its own document, RFC 6122 :

Because all other aspects of revised documentation for XMPP have been incorporated into [XMPP] , the XMPP Working Group decided to temporarily split the XMPP address format into a separate document so as not to significantly delay publication of improved documentation for XMPP. It is expected that this document will be obsoleted as soon as work on a new approach to preparation and comparison of internationalized addresses has been completed.

The updated address format still relied on IDNA2003, but developers were encouraged to look at IDNA2008.

RFC 6122 furthermore introduced the localpart , domainpart and resourcepart names and changed IPv6 literals to use the bracketed IP-literal syntax from RFC 3986 .

2015 The Next Generation

As announced in the intro of RFC 6122 , it was soon replaced by RFC 7622 , which we might vaguely remember from the beginning of this post. It was published in 2015, based on the still fresh RFC 7613 PRECIS specification.

The PRECIS suite and the updated XMPP address format introduced case folding, replaced the Stringprep profiles with the PRECIS classes, profiles and categories explained above, and effectively disallowed Emojis in the localpart and domainpart of XMPP addresses (following the IDNA2008 insights).

As mentioned before, RFC 7613 was obsoleted by RFC 8265 , which corrected a few things and went from case folding to lowercase again . 🤷

This happened in 2017 and, together with RFC 8266 (Nicknames) is the end of the evolution of the RFCs needed to understand XMPP addresses.

So you just told me that Emojis in nicknames are still allowed, yes?

XMPP address validation in the wild

The IETF is about "rough consensus and running code". We've seen the consensus and how it changed over two decades, but in the end it's the running code that will say "no" when you try to butt dial an XMPP address.

Consensus in distributed systems

Something that you enter might go through up to five different hops (and different XMPP implementations; I'm omitting protocol bridges, but the point should be clear):

1. Your own client, which is responsible for sanitizing (or refusing) your input, through its user interface or config file.
2. Your server, receiving your input through a client-to-server connection.
3. Optionally, a XEP-0045 Multi-User Chat (MUC) room where you are an occupant, through a server-to-server connection.
4. The recipient's server, through a server-to-server connection shared with other users.
5. The recipient's client, through its own connection to its server.

Your client is the easiest part, as it can simply reject forwarding something it disagrees with. If the "Add contact" button is greyed out, you've arrived at a dead-end. ⛔

The following hops on the path can't grey out the button if they consider your XMPP address, coming through an XML stream, as invalid. According to RFC 6120, they have to treat it as a (recoverable) stanza-related error, and reject the respective XML stanza (and not terminate the XML stream):

8.3.3.8. jid-malformed The sending entity has provided (e.g., during resource binding) or communicated (e.g., in the 'to' address of a stanza) an XMPP address or aspect thereof that violates the rules defined in [XMPP‑ADDR] ; the associated error type SHOULD be "modify".

So if a recipient disagrees about the PRECIS / IDNA version with your client or your server, it will reject the respective stanza before it can be processed.

Robot Face vs. the MUC Occupants

When joining a MUC, you send a presence stanza to your occupant address, constructed by appending your nickname as the resourcepart to the room address. If you choose an evil Emoji nickname and the room rejects it, it will send an error response, and you won't be able to join the room.

Now if the room does accept your nickname, it will forward the presence, sending it from your occupant address, to all other occupants.

I first ran into this issue, not knowing much about IDNA, PRECIS or Stringprep, back in 2017 :

11:28:50 ---> 🤖 joined the room
11:28:50 <--- T....s has left the room (Kicked: jid malformed: The source address
                                    is invalid: prosody@conference.prosody.im/🤖)
11:28:51 <--- N..........s has left the room (Kicked: jid malformed)
11:28:51 <--- d......n has left the room (Kicked: jid malformed: The source address
                                      is invalid: prosody@conference.prosody.im/🤖)
11:28:51 <--- d.......o has left the room (Kicked: jid malformed: The source address
                                       is invalid: prosody@conference.prosody.im/🤖)
11:28:51 <--- a..v has left the room (Disconnected: not-well-formed)
11:29:08 ---> a..v joined the room
11:32:18 ---> T....s joined the room
11:32:18 <--- T....s has left the room (Kicked: jid malformed: The source address
                                    is invalid: prosody@conference.prosody.im/🤖)

Any downstream server or client that does not accept this occupant presence will send a stanza error back to the MUC. The MUC will treat that error as a non-recoverable session error and remove the respective occupants.

As long as you stay in the room, the other clients will repeatedly reconnect, receive your presence, and get kicked out. If you send a message to the room, it will get pushed to joining clients as part of the room history even after you leave.

Today, the situation is only slightly different:

00:14:39 ---> 🤖 joined the room
00:14:39 <--- H....r (....) has left the room due to an error
            (Kicked: bad request)
00:14:39 <--- c...........s (Monocles) has left the room due to an error
            (Kicked: bad request)
00:14:39 <--- p......d (Conversations) has left the room due to an error
            (Kicked: bad request)
00:14:39 <--- E..a (Cheogram) has left the room due to an error
            (Kicked: bad request)
00:14:39 <--- m.....x (Conversations) has left the room due to an error
            (Kicked: bad request)
00:14:39 <--- y..h (Conversations) has left the room due to an error
            (Kicked: bad request)
00:14:39 <--- b.....a (.../Conversations....) has left the room due to an error
            (Kicked: bad request)

Most of the affected users seem to be running Conversations or its forks Cheogram and Monocles, and the clients(?) responded to the presence with a "bad-request" error.

In addition to that issue, ejabberd sends the error response over the wrong half of the server-to-server stream, so:

Jul 12 01:19:36 s2sout5e57d6de9d50      debug   Received[s2sout]: <presence to='test@chat.yax.im/🤖' type='error' id='noLNT-110871' from='georg@conversations.im/Conversations.jxm9v159lx' xml:lang='de-DE'> 
Jul 12 01:19:36 stanzarouter    warn    Received a stanza claiming to be from conversations.im, over a stream authed for chat.yax.im!
Jul 12 01:19:36 s2sout5e57d6de9d50      debug   Disconnecting chat.yax.im->conversations.im[s2sout], <stream:error> is: <stream:error><not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error> 

Looking at implementations

So it seems like there is a bit of inertia with implementations to follow a fifteen years old specification update. This warrants a look at the major implementations.

Scroll down for the summary table.

Server implementations

According to the s.j.n stats , the top 5 server implementations on the federated XMPP network are Prosody (60%), ejabberd (24%), Spectrum (6%), biboumi (4%) and "Multi User Chat" (1%). And while biboumi is the only one without its own .IM domain, we can still exclude it and Spectrum from the list, as they are bridges to other networks and need to adhere to the limitations of those networks. "Multi User Chat" is in fact the MUC component of the Tigase server .

A cross-match with the servers connected to yax.im also yields similar results, and adds Openfire as a candidate with 1.5% market share.

prosody

Lua isn't exactly friends with Unicode , so prosody went for a manual approach and implemented Stringprep in encodings.c using either ICU or libidn , based on a compile-time switch. The binary packages built by the prosody team use ICU, so we'll take that for the comparison.

libICU

ICU (International Components for Unicode) has a very turbulent history - initiated at a spin-off from Apple and IBM, and written in Java, the first version got integrated into the Java SDK in 1997, then developed in parallel and ported from Java to C++ and C. prosody is using the C version. ICU supports IDNA2008, which prosody started using in 2019. However, ICU only supports Stringprep, not PRECIS (probably due to the fact that Stringprep was a required part of IDNA2003).

libidn and libidn2

libidn on the other hand started out as libstringprep , and supports IDNA2003 and Stringprep. libidn2 was created to support IDNA2008, but it removed Stringprep support , so can't be used as a drop-in replacement.

You have the choice between IDNA2003 with Stringprep and IDNA2008 without PRECIS.

ejabberd

ejabberd is written in Erlang , a language that's as powerful as it is obscure. The ejabberd developers have implemented their own stringprep library and use erlang-idna which supports both IDNA2003 and IDNA2008, but haven't tackled PRECIS.

Tigase

Tigase is written in Java and seems to have forked and heavily reformatted the December 2004 libidn 0.5.12 release. There is no mention of IDNA2008, nor of PRECIS in the source, so I would assume IDNA2003 and Stringprep.

Openfire

Openfire uses Tinder for the XMPP stanzas, and that makes use of libidn 1.35 . As this is not libidn2, Openfire is at IDNA2003 and Stringprep. But there is an abandoned half-finished PR to implement PRECIS !

Client implementations

According to the JabberFR client stats , the top 5 client implementations are:

1. Conversations
2. Cheogram (a Conversations fork)
3. Monocles (a Conversations fork)
4. Gajim
5. Monal
6. Pidgin
7. Blabber.im (an abandoned Conversations fork)
8. Dino

Conversations

Conversations is a modern Android client that's making use of jxmpp-stringprep-libidn , which is using libidn 1.15 which gives us IDNA2003 and Stringprep.

Gajim

Gajim was in fact the client that told me that I'm holding it wrong and that made me write this blog post.

Gajim is using nbxmpp and nbxmpp is using precis-i18n , which implements the trifecta of 8264 , 8265 , and 8266 ! In addition, idna is used for full IDNA2008 support.

So far, Gajim is the only client that will allow Unicode >3.2 emoji in nicknames (and nowhere else)!

Monal

The authentication code is doing manual stringprep , but other than that there is no support for Stringprep or PRECIS. IDNA2008 is handled by the underlying iOS core library.

Pidgin

Pidgin. My nemesis. The formerly most-widely used XMPP client that made a generation of users believe that XMPP is stuck in 2004. Pidgin is using libpurple , which was famously called "a flock a zero days flying in formation" a decade ago.

A 2009 patch implemented IDNA2003 and Stringprep support based on libidn, and it seems to have survived in the 2.14 "stable" branch, which was last released in January 2025.

The 3.0 development branch does not contain any traces of IDNA, Stringprep or PRECIS.

Dino

Dino , a modern client written in Vala, uses a binding to libICU, but without the UIDNA_USE_STD3_RULES flag that would enable IDNA2008.

Implementation overview

The analysis of the client and server implementations shows that most implementations lag behind by a decade. There are two notable exceptions: Gajim implements the current state-of-the-art, and Monal allows everything and lets the server sort things out.

Implementation	username	hostname	nicknames
Servers
prosody	👆️ Stringprep	❌ IDNA2008	👆️ Stringprep
ejabberd	👆️ Stringprep	❌ IDNA2008	👆️ Stringprep
Tigase	👆️ Stringprep	👆️ IDNA2003	👆️ Stringprep
Openfire	👆️ Stringprep	👆️ IDNA2003	👆️ Stringprep
Clients
Conversations	👆️ Stringprep	👆️ IDNA2003	👆️ Stringprep
Gajim	❌ PRECIS	❌ IDNA2008	🤖 PRECIS
Monal	🤖 anything goes	❌ IDNA2008	🤖 anything goes
Pidgin	👆️ Stringprep	👆️ IDNA2003	👆️ Stringprep
Dino	👆️ Stringprep	👆️ IDNA2003	👆️ Stringprep

❌ = not allowed | 👆️ = legacy Unicode 3.2 | 🤖 = modern Unicode

Summary / TL;DR

The original XMPP specification (2004-2010; IDNA2003 + Stringprep) didn't forbid Emojis in any parts of an XMPP address, but was limited to Unicode 3.2, which only had around 150 Emojis. xmpp:👆️@♻️.❤️/⁉️

When IDNA2003 was replaced by IDNA2008 in 2010, hostnames were restricted to characters from actual human languages. The two most widely deployed server implementations enforce this limit, but might support pre-existing legacy hostnames. xmpp:☹️@𓀐.𓂸/☢️

When the XMPP specification implemented PRECIS in 2017, usernames were also limited to human languages, but the resource / nickname part was left permissive, and opened up to all existing and future Unicode specifications. xmpp:𓀬@ツ.ۃ/🤖

So after going through 22 years of development, 19 RFCs and 17 Unicode standards, I have to say: the internet was right and I was wrong. 👆️.op-co.de is not a valid JID, but it was unti 2010.

Read state that actually syncs

0.17.0 introduced synced read markers (XEP-0490), but we shipped a bug: the payload we published used the wrong shape, so other XMPP clients ignored our read state, and we ignored theirs. 0.17.1 sets this right:

• Spec-accurate XEP-0490 payloads. Fluux now publishes the shape other clients expect, and migrates the legacy markers 0.17.0 wrote.
• Notifications follow your reading. When you read a conversation on one device, its native notification banner is dismissed on your other devices. Read markers synced while a room was inactive are now applied too.
• Your place is kept. A room no longer discards your read position on launch. Fluux anchors on the last-read message, the way other modern chat apps do, and the marker advances correctly once you reach the live edge of a conversation.

A Pure theme for OLED and e-ink

New in this release: the Pure theme , in pure-black and pure-white variants. Flat, high-contrast chrome with no gradients or translucency, designed for OLED displays and e-ink screens.

There is also a new "Play notification sounds" toggle in Accessibility settings.

Group chats

• Slash commands in the composer , including /nick to change your nickname. The change is reflected in the occupant list and as a timeline notice.
• Typing indicator in the sidebar for joined rooms. It only appears when a caught-up room lights up; busy or unread rooms keep their badge.
• Impersonation hardening. Nicknames padded with whitespace or invisible characters can no longer masquerade as another occupant.

Aurora refinements

• Shields and locks now mean different things. A shield shows encryption status; a lock is reserved for content that cannot be read. The two metaphors are applied consistently across the chat header, message indicators, composer, and security panel.
• Cleaner outgoing bubbles. Consecutive messages you send hug their content and form clean rectangular groups.
• Calmer motion. Space is reserved for the typing indicator so it no longer overlays the last message or fights an upward scroll, and Aurora gradients now harmonize with your accent color in each theme.

Reliability and platform fixes

• Jumps always land. Jumping to a reacted, replied-to, or poll message works even when the target is outside the loaded history window, and search previews stay centered on the match.
• Linux. The system tray dependency is standardized on libayatana-appindicator so tray menu labels render, Flatpak installs auto-pull the GNOME runtime, and modals stay solid where WebKitGTK advertises backdrop blur it does not actually paint.
• Link previews are now attached in the interoperable OGP format, so other XMPP clients display them correctly.

The full list of changes is in the changelog on GitHub .

Get it

Fluux Messenger 0.17.1 is available for macOS, Windows, and Linux, or directly in your browser. As always, it works with any standards-compliant XMPP server, and it remains our day-to-day client at ProcessOne.

If you upgrade and something feels off, tell us. A lot of what shipped in this release started as a user report — bugs and ideas are welcome on GitHub Issues .

Here is a new version for slixmpp, the python XMPP library.

This release has one major deprecation, two bug fixes, several new features as well as plenty of improvements under the hood.

Thanks to everyone involved!

The Ignite Realtime community is pleased to announce the release of Openfire 5.1.1, a maintenance update to our open-source XMPP real-time communication server!

Following last month’s 5.1.0 feature release , we’ve been gathering feedback and tracking down the issues that inevitably surface once a bigger release meets the real world. Openfire 5.1.1 is the result: a focused round of bug fixes and improvements, with a particular emphasis on PubSub correctness and connection handling.

A good chunk of this release tidies up PubSub behaviour. We fixed excessive memory consumption caused by a bloated ofPubsubSubscription table ( OF-3306 ), alongside various smaller issues related to pub/sub functionality.

Connection handling gets some attention too. We resolved a nasty case where IQBindHandler could busy-wait up to 20 seconds on a resource conflict, causing thread starvation and misbehaving ( OF-3319 ), fixed a NullPointerException in outbound S2S DirectTLS connections ( OF-3332 ), and a number of other networking-related issues.

Certificate SANs now encode IP addresses correctly as iPAddress rather than dNSName ( OF-3324 ), which should fix an issue that popped up under certain network configurations with recent versions of the Conversations client.

We also cleaned up a couple of migration-related issues carried over from 5.1.0’s database work, such as XML properties failing to save during PBKDF2 migration ( OF-3305 ). This should guard against accidental loss of the encryption keys, preventing installations that become effectively unusable when migration happens while the file system is in a faulty state.

The full changelog has all the details, with 24 items resolved in total.

You can obtain Openfire 5.1.1 for your platform from its download page . The sha256sum values for the release artifacts are:

dc887032619b7ecf66cc8c17dc5cedc13c2479525cd93b41e5d999e4ec942adf  openfire-5.1.1-1.noarch.rpm
4f6c5ccfe44fdd494760ae5a6f00f971ea000ec6c69e1481d3546bed994598e2  openfire_5.1.1_all.deb
17eafa2641a5cbe226328d54e115fd1780a90d6fedb6d63d8bcea048f91f23ab  openfire_5_1_1.dmg
68b69309f22435e4996b18b21a451d8c3b98a543aa8680436694bf4a235b8299  openfire_5_1_1.exe
d930be11c93c995ee0a045118d0539629bd27d983ad99e6f174ded6453612a0d  openfire_5_1_1.tar.gz
b55659388274deedde92813ed830e1060c89b48fc3d61e6227c153bd4d96b57e  openfire_5_1_1_x64.exe
9faa8900c8aa56822deb83c82339842794b6e2e58be61ca08dbdf948ee931cd6  openfire_5_1_1.zip

Many of the issues fixed in this release were reported by our community members, and several of those were instrumental in finding and fixing bugs and applying improvements. We greatly appreciate everyone’s feedback! We’d love to hear from you! Please join our community forum or group chat and let us know what you think!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

Aurora: a new identity for Fluux

Fluux has a new face. The app icon, logo, and the entire interface have been redesigned around Aurora, a teal-to-violet gradient identity with display headings, softer avatar shapes, and frosted-glass modals.

Aurora is more than a color swap:

• Per-person sender colors. Each participant in a group chat gets a stable, readable color, tuned for WCAG AA contrast in both light and dark themes.
• Curated accent presets. Pick the accent that suits you; the whole interface follows, including the encryption affordances, which now use one consistent color from the chat header to the message locks and the composer.
• Calmer chrome. Thinner scrollbars, consistent focus rings, quieter notification badges. Unread indicators now follow a simple two-tier model: red means something needs you (a direct message, a mention, a contact request), grey means ambient room activity.

If you preferred the previous color scheme, it is still there as the “Indigo classic” theme.

Conversation-first navigation

We removed the standalone Events view. It was a place you had to remember to check; now events come to you, in context:

• Contact requests, room invitations, and message requests appear as headed sections at the top of the relevant lists.
• A message from someone not in your roster opens as a read-only preview with an Accept / Ignore / Block banner, so you can see what it is before you commit to anything.
• Contacts moved down to the navigation cluster, with a badge when requests are pending.
• Archived conversations are one toggle away in the Messages header, and archiving now syncs live across your devices.

The result is fewer top-level destinations and less bookkeeping.

Jump anywhere with the command palette

Press Cmd-K (Ctrl-K on Windows and Linux) to jump to any conversation or action. The palette puts your unread chats and mentioned rooms first, shows avatars and unread badges, and never proposes the conversation you are already reading.

Unlimited scroll-back

The fixed 1,000-message cap on conversation history is gone. History is now a sliding window: scroll back as far as you like, and messages load incrementally from the local cache and the server archive (MAM). Combined with message-list virtualization, now on by default, long conversations stay fast, and typing no longer reflows the message list on every keystroke.

While we were in there, we fixed a long tail of scroll issues: new messages reliably stick to the bottom on WebKit, returning to a conversation restores exactly where you were reading (even deep in history), and jumping to a search result lands the message a third of the way down the viewport instead of hiding it under the date header.

Your reading position follows you

Read markers now sync across devices (XEP-0490). If you read a conversation on your desktop, it opens at the right position on your laptop, and its notification is dismissed. Together with live archive sync and the carbons and MAM work from previous releases, your devices now agree on what you have read, what is pending, and what is filed away.

A friendlier admin console

For those who administer their own ejabberd server, the ad-hoc command list is gone, replaced by purpose-built screens: a server overview dashboard, a searchable user list with online status and last login, a redesigned user detail view with a Ban account action, and a mobile launchpad. Only a few server admin commands are available so far, but we plan to grow the list with each new version.

Desktop and everyday polish

• Window app bar. The desktop app gets back/forward navigation in a proper window bar, with correctly centered traffic lights on macOS.
• Calm updates. Instead of reloading the app under your feet, a new “Update available” button appears in the icon rail when a new version is ready. You decide when.
• Reduce motion. A new accessibility setting minimizes animations and follows your system preference.
• Advanced mode. The XMPP console and expert settings are now behind an in-app toggle, keeping the default settings approachable.
• Redesigned contact details. A person-forward view with cards for devices, groups, and security, and fingerprint verification in its own focused panel.

And the usual pile of fixes

Almost 300 commits went into this release, so the full list is long. Some favorites: your own encrypted messages now show their real trust level instead of a grey lock under some circumstances; whispers in group chats keep their corrections and reactions private; animated avatars are frozen so they stop competing for your attention, even if they are PNGs; reactions from ignored users are hidden; and rooms are sorted correctly the moment the app launches.

The complete list is in the changelog .

Try it

Fluux Messenger 0.17.0 is available for macOS, Windows, and Linux, or directly in your browser. As always, it works with any standards-compliant XMPP server, and it remains our day-to-day client at ProcessOne.

If you upgrade and something feels off, tell us. A lot of what shipped in this release started as a user report.

0.16.1 is our quick turnaround on that: a focused round offixes for the issues that have been reported, across encryption, connectivity,message history, and the desktop apps. Nothing dramatic here, we mainly want to show that we&aposre listening and addressing reported problems fast.

End-to-end encryption in daily use

With people now encrypting real conversations, a few practical details surfaced —and they&aposre sorted:

• Verification works across clients. Fingerprints are published and compared in a consistent case (XEP-0373 expects upper-case), so the green "verified" lock appears reliably whatever XMPP client your contact uses.
• Cleaner previews and placeholders. Encrypted reactions now show up properly in the conversation list, and you&aposll see a "decrypting…" placeholder while the encryption plugin finishes loading.
• Complete archive. Encrypted messages without a plaintext body now come through correctly from server history (MAM).

Smoother connections

Field reports pointed to a handful of connection scenarios, now improved:

• Happy Eyeballs. Fluux races IPv4 and IPv6 when connecting, so a slow or broken IPv6 route no longer holds things up, whichever answers first wins.
• More reliable reconnection. Stream Management handling and the desktop&aposs local proxy hop were both tuned to resolve reconnection cases users reported.
• Clearer status. Presence pills stay grey while reconnecting, and the reconnect spinner and countdown are back in the sidebar status chip for a calmer interface on unstable networks.

More complete message history

• Gap recovery. Some users reported missing stretches of history after long periods offline. Catch-up now closes those gaps in both group chats and 1:1 conversations, with a "load missing messages" marker to bring back anything that was skipped.
• Reliable scroll-up. Loading older history by scrolling up now works as expected.

A more polished desktop experience

• Notifications open the right chat. On macOS, clicking a notification takes you straight to the conversation it belongs to.
• Single window. Relaunching the app focuses the window that&aposs already running instead of opening a second copy.
• Linux tray fallback. When the system tray isn&apost available, closing the window quits the app, so it can always be reopened.
• Image downloads use the native save dialog, and Settings now links straight to your system notification settings.

Lots of smaller fixes

And plenty of smaller refinements from everyday use: consistent empty-state icons, reply quotes that match the original sender&aposs color and render as nested bars, opening a contact profile no longer bouncing you back, link-preview images that retry once before hiding, a smoother composer resize, local JID validation on the login screen, and group-chat performance improvements on room join.

---

Thanks to everyone who reported issues and shared feedback – that&aposs exactly what shapes a release like this one. 0.16.1 is available now on our website , and the full changelog is on GitHub . Keep the reports coming!

Over the past few months, our team has been exploring what happens when systems come under pressure.

Through a series of webinars, we’ve looked at everything from concurrency in the BEAM to traffic spikes, real-time communication platforms, and resilient system design.

Maybe you’ve been following along, or maybe one or two of these webinars slipped past you. Either way, this is a chance to catch up on the ideas shaping how modern platforms are built and scaled.

Concurrency, Understanding the BEAM Limits

Modern systems can handle huge amounts of concurrent work. But sooner or later, every system reaches a point where performance starts to suffer.

In “Concurrency, Understanding the BEAM Limits”, Lorena Mireles Rivero explores how concurrency works inside the BEAM and where those limits begin to appear. Using examples from web applications and e-commerce platforms, she looks at how schedulers, mailboxes, CPU usage, and latency behave under load.

The session also explores common signs of system saturation and practical ways to keep applications running smoothly as demand grows.

Watch the webinar to learn more about concurrency in the BEAM and how to build systems that perform under pressure.

Keeping Real-Time Communication Platforms Online During Peak Demand

Real-time platforms don’t get a second chance. When demand spikes, messages still need to be delivered instantly and reliably.

In this webinar, Bartłomiej Górny explores what happens when systems are pushed to their limits. He looks at common bottlenecks, overloaded services, and how failures can spread across a platform when demand suddenly increases.

The session also covers practical approaches to scaling real-time systems, from service decoupling and back pressure to monitoring and load testing.

Watch the webinar to learn how real-time platforms can stay reliable during periods of peak demand.

How to Build Systems That Stay Online When Everything Spikes

Traffic doesn’t always increase gradually. Sometimes it arrives all at once.

In this session, Camjar Djoweini explores what happens when systems come under sudden pressure and why failures can quickly spread across services. He looks at where problems typically start and what makes some architectures more resilient than others.

The webinar focuses on designing systems that can absorb spikes, tolerate failures, and continue operating when conditions become unpredictable.

Explore the webinar to learn more about building resilient systems that stay online under pressure.

How to Build Platforms That Don’t Let Audiences Down

For gaming, betting, and entertainment platforms, traffic spikes are part of everyday life. The challenge is making sure users never notice them.

In this webinar, Lee Sigauke explores why systems fail during sudden surges in demand and how teams can build platforms that remain reliable under pressure. Drawing on principles from transactional systems in Erlang and Elixir, she shows how concurrency-first design helps systems cope with unpredictable workloads.

The session covers common failure patterns, resilience at scale, and practical ways to build platforms that continue performing when demand reaches its peak.

Watch the webinar to see how concurrency-first design helps platforms remain reliable when traffic surges.

To conclude

That wraps up our latest webinar round-up. We hope this guide helps you catch up on some of the ideas we’ve been exploring over the past few months.

If something here has sparked your interest, whether it’s concurrency in the BEAM, building resilient architectures, or keeping platforms reliable during periods of peak demand, we’d love to continue the conversation. So get in touch.

Here’s to building systems that stay stable, scalable, and ready for whatever comes next.

The post Erlang Solutions Webinar Round-Up appeared first on Erlang Solutions .

Here is a new version for slixmpp, the python XMPP library.

This release has one specific breaking change and two new XEP plugins. Thanks to everyone involved!

We are pleased to announce a new minor release from our stable branch.

This release fixes a handful of bugs which were discovered and fixed since the 13.0.5 release. Most of these are minor, but a few of them are important fixes.

A summary of changes in this release:

Fixes and improvements

• mod_cloud_notify: Use correct stanza id when clearing table entries (mem leak)
• mod_admin_shell: Don’t echo new password back to the client
• util.pubsub: Remove JIDs not permitted to be subscribed on affiliation change (fixes #1709 )

Minor changes

• mod_account_activity: Don’t traceback when called without options
• util.jsonschema: Always accept 0 for multipleOf properties
• util.paths: Fix check for adding installer path to package.cpath
• util.datamanager: Fix listing of host stores
• util.crypto: Use post-Lua 5.1 buffer API for improved memory safety
• util.dataforms: Don’t treat invalid jid-multi fields as missing
• util.crypto: Ensure signing parameter is a string
• util.poll: Reject unsupported file descriptors when using select() backend
• util.pubsub: Ensure deleted node stays in memory store deletion failed
• util.ringbuffer: Fix incorrect returned position from :find() for #needle~=1
• util.pposix: Fix incorrect syslog facility mapping
• util.ringbuffer: find(): Fix find logic bugs
• util.signal: Fix signalfd closure on non-Linux systems
• net.websocket: Fix traceback in client if server doesn’t respond with Connection header
• net.server_event: Fix incorrect flag logic for watchfd handles
• mod_debug_stanzas: Only clear active_filters when there are no subscribers
• mod_carbons: Fix ‘to’ attribute of stanzas to own account
• net.stun: Fix parsing of STUN packets with 0-length attributes
• mod_storage_memory: Fix assignment to ‘with’ when calling archive:set()
• net.http.parser: Include final component in path normalization check
• mod_register_ibr: Use set_password() instead of create_user() for resets
• mod_vcard: Ignore invalid photo data
• util.timer: Fix incorrect rescheduling of some kinds of timers

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!