Hacker News Reader

I run my own ejabberd instance for a group of friends and it obviously works.

I do manual account creation and know people there (or they are vetted by my friends). The server federates with any other server that supports s2s encryption so they can talk to whoever they want.

On windows probably the most mature client is Gajim. You can use it on Linux too, but there are more alternatives (such as the more modern Dino.im) On Android there is the excellent Conversations, with a few more to choose from. Or you can go with a platform-independent web-based client and use Movim. All support OMEMO. I am not invested in the Apple ecosystem so I don't know about that (Beagle IM? Monal?).

Typically the XMPP naysaying is a mix of bad experiences in the past and NIH syndrome. Things like server-side message archiving, message carbons, message delivery receipts or MUCs are long solved. You want to make a stand for open, federated internet you need to put your money where your mouth is.

About the only sore points are cross-platform VoIP (Windows lacking here) and direct file transfers (SOCKS5 bytestreams are wonky which leaves http uploads) although arguably neither have to be a part of a chat application.

Good reply, thanks. I am very pro #XMPP. Which is also why I yearn for a couple real areas of improvement & focus:

* MIX. there's a new standard for group-chats/rooms that is far less ad-hoc/special-case, that uses other XMPP extensions (XEPs) very well & enables features people expect in chat these days. it's a good standard. MIX (XEP-0369) support is still alpha level or non-existent. this is needed for a quality experience, with reactions, chat history, & as a technical advancement out of a bad shifty early legacy solution.

* Video. There are not a lot of video supporting clients. I think the spec is mostly ok for 1:1 video. But "Muji" multi-user video got demoed a decade ago & works but is more or less unimplemented. This is not cool. I think Muji also should probably be rebuilt anyways atop MIX.

* web integration. i'd like to be able to use my XMPP account online in a well-defined way. xmpp should start to define ways to make user accounts also OpenID Connect (OIDC) providers, & begin to define interoperation for webrtc & XMPP & the web to work together harmoniously.

This is the gap Snikket[1] is aiming to fill. A preconfigured XMPP server that you can safely and easily run yourself (it's invite-based registration), with "blessed" apps provided for each platform that are guaranteed to be maintained to a common standard.

It's early days and there's still some way to go, but the current release (server + Android client) is receiving excellent feedback from those using it.

The next primary focus is iOS. There are several XMPP clients available on iOS, but none yet fit the bill. That's where most of the work ahead lies for the coming months.

[1]: https://snikket.org/

So you took Conversations, renamed them, and call it a day, focusing next on iOS? Then I've got rather bad news for you. You'll need to be focusing for a long, long time.

It took us 'only' 2.5 years to build a good XMPP client for iOS (which we plan to release this month, finally), and while building it we had to break down XMPP down almost to a core and replace most of its components with better thought through solutions that account for real life scenarios.

We had to throw away MUC garbage, do push notifications differently, make different video calling, etc. - and that requires modifications on the server-side. Now it works acceptably, just some rather little quirks/bugs remain. It is no coincidence that not one released XMPP client today can be called 'working'.

However, to make it work _really_ great we'll have to do 'break' XMPP even further and rethink how presences work. Currently, they are a major pain.

Hi Andrew, I'm familiar with your team's work, and don't doubt your determination to build a quality product. From what I've seen, that appears to be your priority above and beyond XMPP, self-hosting, and interoperability with others in the ecosystem. There is nothing wrong with that choosing that as a primary goal, but it's a different goal to Snikket.

Snikket is building on and improving (pushing upstream whenever possible) existing projects in the ecosystem, not starting from scratch. The smooth invite-based onboarding flow for example originated from Snikket work, and is now upstream in Conversations and other clients are adopting it too.

I've been working with and on XMPP for 15 years, and have no illusions about the challenges we (or any fully open decentralized messaging system) face in today's world. However we can never give up on free, open and interoperable technologies.

Quick scan of the website & the github. Did not find direct mentions of XMPP. Does this interop with other XMPP systems or is this based-on-XMPP but standalone? I would not adopt or recommend this, framed as it is as it's own thing.

If your primary criteria is "must support XMPP", you are very likely not amongst the target audience of Snikket, or you are at least in a minority of it. There are many XMPP servers and clients already out there easily discoverable by someone who knows that's what they want.

Snikket is aimed at people who primarily just want an out-of-the-box self-hosted secure messaging service. "XMPP" is not a feature for this crowd, but the benefits of XMPP are (federation, free choice of client software, etc.). For the same reason Mozilla doesn't advertise Firefox as a "HTTP client", the Snikket marketing is focused on features and not how the underlying tech is implemented - what we do, not how we do it.

The fact that Snikket is built on XMPP is not something we aim to hide however, it's discussed in [1] for example. It's just not what we lead with when introducing the project to general users.

Many good open-source projects fall into a trap of their developers marketing their project in a way that they would want to see it marketed to themselves. The truth is that nobody outside certain internet communities cares about open standards. They should, of course, but they don't realise it. We're trying to reach these people with Snikket.

[1]: https://snikket.org/network/

When I used it professionally it was always a pain. XMPP was very chatty for mobile. Multi user chat and chat history was a pain to get working. Clustering was also dark magic. This was Ejabberd which was considered the best option at the time.

At the time, it felt like every feature was stuck in beta/RFC mode with very poor cross server compatibility. How is a federated protocol supposed to work like that?

I think XMPP just failed to cater to any audience. The Googles and Facebooks could roll their own and for everyone else it was too cumbersome. It's not as "easy" as running an email server and no one wants to do that either. It wasn't even agile enough to woo small communities with whiz-bang features.

I worked on an XMPP client for a while, many years ago, for a proprietary chat system that used ejabberd as a back end. The protocol is/was awful.

On a related note, AOL should've open sourced and federated AIM. Everyone in the late 90's, early 2000's was on it.

> AOL should've open sourced and federated AIM

afaik AIM was a derivative of ICQ, but yea those were the good times. today i know more ppl that won't touch whatsapp then there were w/o icq numbers back than, probably the closest we've got to a ubiquitous instant messanging. i still remember my icq# althou i havent used it in like 15y and have burned throu like five phone numbers since.

Not all parts of the protocol are awful. Many stupid extensions (XEPs) sure are bad, chiefly, MUCs.

However, this breaking down of the protocol to small components is the strength of the protocol, not a weakness.

Yes, I was actually working quite a bit with MUCs, now that I remember it!

> Everyone in the late 90's, early 2000's was on it.

Outside the United States, very few people were on it. When I signed up to play some video games with some US friends from a forum, I remember having to Google a valid US address and it's matching ZIP code as it wouldn't even let me sign up without one.

MSN was more popular in western Europe and as I understand it ICQ (eventually federated and shared some tech, but not the same network) was the top early IM in eastern Europe. Can't comment on the rest of the world at that time but I doubt the sign-up form was any more accepting of Korean addresses for example.

ICQ was also huge in Italy and, I understand, most of western Europe, at the turn of the millennium. Then MSN took over.

Imagine if the global phone network was balkanized like messaging networks...

We asked them to. I was in the room. They said no.

TBF, we asked them to let us use the protocol, or make it part of IMPP, or get actively involved in IMPP.

Running an XMPP server is much easier than running a mail server.

I know, I've run both for a number of years.

Very few people need clustering support.

My use cases were a large social app with chat and a AAA game with team chat. This was almost a decade ago but in both cases a single server was deemed insufficient by our ops people. I suppose you're right, though. I've never had to maintain a mail system of similar scale.

Mail is async in nature, XMPP has some expectancy to work as fast as possible (avoiding the term realtime here).

the MUC is not good. this is true. there is MIX, XEP-0369, that has a way better under-the-hood approach that re-uses a lot of the existing XEPs (whereas MUC was early & kind of it's own thing).

alas MIX adoption is very low. ejabberd got MIX support in 2016 but it's stayed at 0.1.0. and, more pressingly, i don't think any clients support it. this has to change for XMPP to pass MVP muster. https://www.reddit.com/r/xmpp/comments/arpruf/what_clients_s...

1. there are a bunch of public servers that have been running for a long time. Including one by the CCC (Chaos Computer Club, German privacy and security advocacy NGO).

2. IMO the biggest hindrance with XMPP. So which XEPs do I need to support on the server? Okay, got what I wanted. How do I find out exactly which are supported on which client?

3. Manual account creation, thanks to federation I don’t need external users to be on my server.

4. OMEMO works with every halfway decent client. Of course, closed ecosystems like iOS might be different, but that’s what you get for locking yourself in.

on 1. the mentioned server was(is?) suffering from to much publicity. the ccc tried very hard to get ppl to use different ones.

> 2. If you do (or don't!) run your own server, how do the end users find a halfway decent application on their fancy iPhone 18 Pro++ that supports push notifications?

That's a problem with the iphone, not xmpp. Apple restricts what you can do with your hardware and offers no other options than their push notification approach. You cannot blame existing protocols for apple's distributed-software-hostile whims of the day. Blame apple for only offering an anemic subset of the internet.

As an iPhone user, I'm very happy that apps can't implement their own push notification systems, or have persistent background connections open, as it's one of the main reasons I get good battery life.

As an iphone user, I am not, and I am sure that apple could find a way to allow push notifications on the web without the battery taking a major hit.

For example, Apple could allow an app to register as a receiver for a class of push notifications, and then require all the pushes to go through the Apple-maintained background process.

Certain that Riot.im does these things, doesn't destroy battery.

Riot uses the platform’s push server unless you’re using the F-Droid version on Android. That version will indeed destroy my battery if I leave it running with my (rather large) account.

League of Legends chat, WhatsApp and early versions of Facebook chat were build with XMPP and Ejabberd and they were able to handle massive loads with it.

Obviously for an internal company chat app this is not the best option as it will require some maintenance, and the app support is not great, though there are some good options now.

But for heavy chat load it is a great choice that will save you a ton of money, time and resources.

1) Host your own server, don't make it public. 2) The fact that there were so many non-mandatory and sometimes competing XEPs was a major setback indeed. 3) There were measures for that, such as that unknown users should answer "how much is pi*0" kind of questions

Matrix seems to solve items 2 and 4, lets see how much traction it gets.

Multiple government and large nonprofits have adopted it, what more traction can you ask for in free open source?

Adoption by "normal" users instead of Telegram/Whatsapp/whatever.

I count 20 OMEMO supporting clients:

* https://omemo.top/

I use an android phone, so this may be out of date, but every time I check, the iOS XMPP clients are terrible in at least one important way, and often in several.

OMEMO just works for me. I use OMEMO XMPP SMS with JMP.chat

Just started using this and love it. I think I may be able to finally ditch Hangouts/GV.

I built Siashable with ExtJS and xmpp4js in 2008 against Openfire. I’ve run it at various times against Tigase and Prosody and it works, and even ran the XMPP lib I made for it in iOS JS Core recently, and it has its own everything down to DOM with namespace support in JS so works back to early IE versions. I’d say XMPP with BOSH works pretty good.

I've been using Riot to connect to Matrix.

Works very well and Riot is on: iOS, MacOS, Windows, Google Play, F-Droid, Linux, and has a very nice web application.

This is what got me started: https://matrix.org/blog/2020/04/06/running-your-own-secure-c...