XMPP doesn't "work", but on the other hand, the alternatives probably worse:
1. Don't run your own server? A co-worker once operated a fairly popular "public" XMPP server with a decent number of typically active users, a couple hundred. Some eastern European "darkweb" drug sellers had an account on the server, so their competitors thought it worthwhile to threaten the XMPP operator with very directed violence. If you don't host your own, who is running your XMPP server? What will they do when the government/yourThreatActor threatens them?
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? Their Windows 10 desktop? Ubuntu Linux?
3. If you run your own server, what do you do in the unlikely event of spam?
4. Crypto? OTR sucks for multi-device, OMEMO isn't extensively supported.
XMPP obviously doesn't work, but I can't suggest anything that's better.
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.
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.
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.
> 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.
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.
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...
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.
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.
> 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.
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.
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.
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.
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.
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 told Amazon was going to post a video to social of the third bad delivery at my apartment. It was so comical because even Amazon had posted signs on our property telling the delivery drivers what not to do. Yet the drivers did exactly that right in front of the sign.
The first two email complaints went unresponded to. After threatening to put on tiktok, I got a phone call from the regional director in charge of the deliveries within two days.
I don't think that was necessarily due to your threat. I've noticed that often the first one or two or even three messages about an issue that I send to Amazon seem to be answered by bots (or people following a poor script) and they miss the point of my message completely, each time, no matter how clear and exact I am.* It's only after multiple messages that a real (free-thinking) human seems to actually read it and respond appropriately.
* I swear it seems like there's a simple algorithm that scans the message for trigger words and then chooses a response based solely on those trigger words. I've received responses to issues completely unrelated to my entire message, except for the fact that they're about something I briefly mentioned in an aside or something like that. It's horribly horribly frustrating, even when I know it's going to happen.
No, the person who called me specifically said they were freaking out trying to get ahold of me because the social threat had caused the email I sent to be bounced around internally. She called me to talk me down from doing it and make reassurances, even though I had forgotten about it by that point.
Because they only had my email address and building location, Amazon repeatedly called the property agency, who (stupidly) gave them my phone number and details.
The beginning of the document says "Inspecting the file and testing my findings with initial hand‑crafted POST requests, I discovered that this script allows clients to specify a custom filename which is susceptible to path traversal. To make matters worse, the script does not protect against overwriting existing files": Great, you have path traversal and upload on an old-school PHP platform. You've already won! Report it and move to a bug bounty that actually pays.
Next, "Using this vulnerability, I uploaded a custom .htaccess file (with Options +Indexes ) into the /media directory": This is going too far.
Next, "Further leveraging the insecure upload script, I managed to deploy a custom index.php into an exiting /media subfolder": This is going to far.
Next, "To expedite further testing, I uploaded a copy of the p0wny‑shell. (Note that I slightly modified the file to circumvent common anti‑malware signatures.)": This is going to far.
"Knowing SlickWraps' website was powered by Magento 1.8, I located and decrypted the local configuration file. In here, I found MySQL and Redis credentials, and thus had full access to their entire database... Investigating the complete 17 GB MySQL dump gave me access to the following": Ah, so you knowingly breached real customer data. I think even you know you've gone way too far by now.
I could continue to the next steps in the exploitation chain, but won't. Per their initial Medium writeup, they didn't report it to Slick Wraps until they had walked past a not-so-thin line half a dozen times and extracted the full database content.
I found this article after receiving an email from (him?) telling me slick wraps had been hacked and were doing nothing to prevent the loss of my data.
