21 XMPP use-cases and the best ways to achieve them | Hacker News Reader

21 XMPP use-cases and the best ways to achieve them

erlang-solutions.com

72 pointsliotier21 comments

Sad, neither MongooseIM, nor ejabberd use proper Erlang/OTP SASL release system, so hot updates can be done with relup (http://erlang.org/doc/man/relup.html)

Smaller modules can be upgraded from Erlang shell, but it's seems to be impossible to update a server without shutting it down.

MongooseIM (and ejabberd) are too big and complex to allow full hot code reloading. Moreover this feature is quite rarely used in any Erlang software.

I'm not sure how you've measured how often hot code reloading is used? I use it for almost all of my production pushes.

However, I agree that it's generally hard to use it for third party software; upgrades would either become cumbersome because you have to follow the same piecewise upgrade process the developer followed, or the developer would have to do a lot of extra work to ensure upgrades between releases were solid; the recent addition of atomic loading of multiple modules would probably help.

I could point to this: https://stackoverflow.com/questions/31080970/erlang-hot-code...

Good introduction to modern XMPP.

Is there a cross platform, desktop client that strives to implement these XEPs? Something like Conversations.im for Android.

Gajim [1] implements a lot of modern XEPs (directly or through easy to install plugins), including OMEMO. I don't know how well it works on non Linux systems (they provide Windows binaries at least).

[1] https://gajim.org/

it works. doesn't feel very native, but then neither do a lot of the big names in chat right now

It is worse, actually, because it uses GTK, and is only available on Linux and Windows (not macOS, although there have been attempts).

Most of the "big names" who provide modern and contemporary desktop IM apps deliver on the 3 platforms (Linux, macOS, and Windows), and use mostly web "technologies" (sometimes "pure browser", and sometimes with electron-like desktop "packaging")... so as a consequence, it is very native, indeed, but it is a generally consistent and continuous UX (user experience) between mobile/tablet and desktop/laptop.

Yes, feature-wise Gajim is one of the best. Unfortunately the UX is pretty bad :(

Indeed Gajim is quite stuck in the past, and I regret to say this as it hurts me, since I used to be a hardcore fan.

Conversations indeed is very decent.

There is dino: https://github.com/dino/dino

It's still very early in the development but it looks pretty good.

I don't think it's cross-platform, though. At least, not yet. (Would be happy to be mistaken)

Is GNU compatible and thus can run on all platforms (e.g. Windows via MinGW). Some features might require special handling for Windows / OS X (GPG, Audio/Video) and Linux is for now the "official" target platform...

https://swift.im/ is cross platform client that strives to do things right. Some of the more modern features are available in the latest beta.

Swift implements - like Gajim discussed above - a very old and outdated UX, and thus cannot be relevant these days.

I speak harsh words, and I am sorry for this, but I was expecting much from Swift at its birth, but that was not delivered over time.

Speaking of modern XMPP... Is there a way to have a shared history for a group these days? Say the server has three users — A, B and C. If A and B is chatting and C is not currently present in the chat, can C see the conversation that took place in the group chat when C was not present when she returns?

Yes and no. The only production-ready of such a requirement is "MUC light". Basically, it is a very simplified version of MUC, that does not rely on user's presence. It exists in the MongooseIM server, in Smack library for Android and in XMPPFramework library for iOS, as well as in Mangosta iOS and Mangosta Android, two free/libre/opensource clients soon to be released. So it is ok to develop a solution based on this approach.

The "open extensions" is available here: https://mongooseim.readthedocs.io/en/latest/open-extensions/... We call this "open extension" because it was not accepted by the XSF, but it is very close to an open standard.

I think Pidgin should fit the bill. Awesome client with a lot of useful plugins.

I realise this isn't actually relevant to the article content, but it seems weird that the TOC doesn't contain links to the relevant section. I know it's pretty short so I can scroll through it quickly, and numbered so I can even just ctrl+f it, but I don't think I should have to do either of those things.

XMPP protocol is so open, that different implementations offer so distinct features, so the lowest common denominator barely includes sending messages to each other.

One cannot not say something is "so open that..." ;-)

But indeed, XMPP is open, very open.

And indeed the major clients usually rely on the old era's ways of thinking messaging... They a far from contemporary, not only talking of features, but also the UX (User eXperience) and the general philosophy.

I would recommend the reading of XEP-0387: XMPP Compliance Suites 2017 (and its successors): https://xmpp.org/extensions/xep-0387.html

But I insist, this one is quite good, honestly: https://www.erlang-solutions.com/blog/21-xmpp-use-cases-and-...

Reply on news.ycombinator.com