======================
 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 (though can't say I liked JSON that much 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
don't include 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's so, and had the
opinion that it's 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 isn't suitable for importing a C API,
or that library just doesn't aim doing that, it's 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's no way to implement
those bits properly without forking. If a library just uses awkward
architecture and decisions, likely sorting it out wouldn't 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's pretty good at establishing and
maintaining a connection, loading and updating a roster, and
delivering messages, though it's 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'll spill some notes and musings here as
well.

As at many earlier stages, currently I'm 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 don't
view file transfer as an essential IM feature, so perhaps it'd 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