======================
 XMPP implementations
======================

I was interested in getting a nice IM for a while now, perhaps since
the time I was actually actively chatting online. With "nice"
including an open and sensible protocol (both facilitating software
implementations and not disappearing suddenly), preferably a choice of
existing software (for personal use, as well as something that is
viable to recommend to less tech-savvy users, including those on
mobile devices), no control by a single entity.

Distributed systems seemed to me like the way to go, and I followed
(and poked, and wrote prototypes of) those for about a decade, but now
it looks like quite a mess out of which nothing usable comes so far.
Federated systems, on the other hand, work fine since the early days
of the Internet, and have many of the same advantages (and usually can
be used in a distributed fashion as well). So 2-3 years ago I focused
on those instead. That is, I was actively using them before, but
hoping for future use of distributed ones, so the change was just in
the plans for a future setup.

Fortunately the choice was quite simple, since the only major and
mature federated IM protocol was XMPP. Then Matrix appeared and gained
some popularity, but the awkwardness of the protocol itself, coupled
with fragmentation it introduces, makes it easy for me to ignore.

In addition to the past focus on distributed systems, I used to
dislike XMPP because of its XML usage, but then noticed (or perhaps
acknowledged) that XML makes sense for both extensibility (via
namespaces) and stream processing, and generally started appreciating
XML more: maybe after observing JSON infrastructure awkwardly
repeating its path (not that I liked JSON before: DSVs and
s-expressions seemed neater, for instance, though more ambiguous and
less specified), or just after working with XML (and particularly with
its sane applications) more.

The first thing a user would notice even on basic XMPP usage is client
UIs, of course, followed by different sets of their features, and then
features (even most basic and obvious ones, such as message delivery)
not working properly or at all, in general or with particular servers
and/or clients on the other end. Investigating that usually shows that
the standards and extensions for those exist and are fine, but
implementations are quite incomplete (even though there are compliance
suites and generally recommended extensions, but some implementations
miss even the required bits of the core RFC). A rather strange thing
here is that despite common inability to implement a usable subset of
XMPP, most of the clients still use custom implementations; it
certainly looks like a problem that could be solved by a library. Yet
the libraries are very incomplete, and/or impose awkward restrictions
(most often on the programming language that can be used, sometimes on
the main loop).

In the past couple of years I wondered why it is so, and had the
opinion that it is better to spend the time trying to improve existing
implementations, rather than to introduce yet another half-baked and
non-reusable one. But improvement is tricky: for instance, if the
language a library is written in is not suitable for importing a C
API, or that library just does not aim doing that, it is virtually
impossible to provide such an API. If a library aims some particular
client or the same API for multiple protocols, which imposes
restrictions preventing proper XMPP implementation, there is no way to
implement those bits properly without forking. If a library just uses
awkward architecture and decisions, likely sorting it out would not be
easier than to write one from scratch.

So, a couple of months ago I finally gave up and started writing yet
another XMPP library: in C and asynchronous, aiming for it to be
fairly complete. I think by now it is pretty good at establishing and
maintaining a connection, loading and updating a roster, and
delivering messages, though it is still in a very early stage of
development.

The project turned out to be quite interesting: there were challenging
design decisions to make, and the overall library is somewhat unusual
(although not unique) in implementing a rather interactive protocol
while being asynchronous. Perhaps more technical details should go
into its manual and annotations (which are far from complete at the
moment), though maybe later I will write some notes and musings here
as well.

As at many earlier stages, currently I am not sure what to do next,
but the primary options are file transfer and a reference client
(beyond a very basic example; maybe as a plugin for some IM). Actually
I do not view file transfer as an essential IM feature, so perhaps it
would make more sense to focus on polishing it and making usable
clients with it already; although it still lacks many features, it
already has the ones for connectivity and reliable message delivery
that many others lack.


----

:Date: 2020-04-09
