Good introduction to modern XMPP. Is there a cross platform, desktop client that strives to implement these XEPs? Something like Conversations.im for Android.
21 XMPP use-cases and the best ways to achieve them
11–20 of 23 posts
Re: 21 XMPP use-cases and the best ways to achieve them
#12Good introduction to modern XMPP. Is there a cross platform, desktop client that strives to implement these XEPs? Something like Conversations.im for Android.
Re: 21 XMPP use-cases and the best ways to achieve them
#13Re: 21 XMPP use-cases and the best ways to achieve them
#14Earlier quoted context omitted.
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)
Re: 21 XMPP use-cases and the best ways to achieve them
#15Sad, 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.
Re: 21 XMPP use-cases and the best ways to achieve them
#16Earlier quoted context omitted.
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/
Yes, feature-wise Gajim is one of the best. Unfortunately the UX is pretty bad :(
Conversations indeed is very decent.
Re: 21 XMPP use-cases and the best ways to achieve them
#17Good introduction to modern XMPP. Is there a cross platform, desktop client that strives to implement these XEPs? Something like Conversations.im for Android.
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.
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.
Re: 21 XMPP use-cases and the best ways to achieve them
#18Good introduction to modern XMPP. Is there a cross platform, desktop client that strives to implement these XEPs? Something like Conversations.im for Android.
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?
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.
Re: 21 XMPP use-cases and the best ways to achieve them
#19XMPP protocol is so open, that different implementations offer so distinct features, so the lowest common denominator barely includes sending messages to each other.
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-...
Re: 21 XMPP use-cases and the best ways to achieve them
#20Sad, 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.
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.