They have things they want done, like chatting with a friend. They want a solution that delights them in doing that. What delights people has generally changed (like more people care about others not listening in these days).
Whose the user and what's their experience? This is where XMPP always failed me. The clients had a poor experience.
If someone wants that to change now... focus on a great experience for the people you want to be users.
> Web3 revolves around the idea of a decentralized Internet. Proponents often contrast this to Web 2.0, where large amounts of the web's data and content are centralized in a fairly small group of companies (often referred to as Big Tech). [0]
> Specific visions for Web3 differ, but all are heavily based in blockchain technologies, such as various cryptocurrencies and non-fungible tokens (NFTs). Some visions are based around the concepts of decentralized autonomous organizations (DAOs), which seek to enable many people to have equal ownership and governance in an organization. Decentralized finance (DeFi) is another key concept, in which users exchange currency without bank or government involvement. Self-sovereign identity allows users to identify themselves without relying on a centralized authentication system like OAuth.
Note how the common thread is that these are all working around the scalability and reliability issues inherent to the popular blockchains. It's perhaps survivable for an identity system to be that slow when making changes if you don't do that very often, although it's definitely a risk for the overall network, but there's no way you're building an XMPP competitor on top of it even before you think about handling audio/video content, and privacy would of course preclude that as well.
That means that you're really building a system which looks a lot like the competitors except using something like a wallet ID to login. Beyond being rather less disruptive than the Ethereum salespeople like to tell you, that's going to look a lot like XMPP — a traditional networked service running a protocol of some level of standardization, only with a different login option. There are some natural trends which are hard to avoid: users will gravitate to the more reliable service offered by the larger companies who can invest more time in optimization, various parties will add extensions which either aren't well documented for competitors or favor their infrastructure choices, and abuse will be a problem which leads to some combination of arbitrary moats being created or users leaving to services where they don't get spam.
That last point is key: imagine if your web3 messaging startup starts to see enough usage that spammers descend en masse? Your real users will leave unless you do something about it. You can add entry fees, which will tank your user growth (which is probably already dangerously limited if you require a blockchain ID), or restrict federation to peers whom you trust to control abuse by their users.
I don't really see this taking off and succeeding in the long run sadly. Don't get me wrong, I'm rooting for it. But I'm pretty sure the game is already rigged.
Decentralization sounds like a great idea but I've been watching that generally fail since the 90s and I think there are some challenges beyond aggressive acts by big players. Part of this comes down to how the terms are used to cover different levels: most of the advantages of decentralization at the infrastructure level are less pronounced in an era where a single entity can easily run code around the world and there are some drawbacks related to things like caching or security. “Distributed, run by one party” is probably going to outperform “Distributed, run by many parties” for most users and the things which are going to make them switch to something else would be high-level things like decisions about the product direction.
The higher-level organization trade-offs are less clear cut, I think. There's an advantage in having more than one party making decisions but it also harms your overall reaction time somewhat substantially. Other than the web and email there aren't all of that many success stories and I wouldn't feel too secure about email long-term. That suggests to me that we might be prone to give the drawbacks insufficient weight when we're thinking about decentralization, especially when it comes to the challenges of controlling abuse. I ran my own Jabber servers for a while and it worked well at work (centralized) but basically all of my personal messages came either from people on Google Talk or spammers. It wasn't just that Google put more money into running servers or building apps but that there wasn't a great path forward for a lot of features which federated services offered.
Re: spam, think a bit longer about that — how much spam do people get in email versus Facebook or Twitter? Those platforms have a lot of users who value their control of user signups, monitoring, and ability to arbitrarily remove spam messages after delivery.
Email is one of the most distributed systems in the world but a rather large fraction of users self-centralized on Gmail. That wasn’t just spam control but I think it’d be really useful to think about why some new system wouldn’t follow the same arc: if your argument is “cyberpunks wouldn’t accept it”, remember that we had that ethos arguably even stronger back then and it didn’t have the predicted effect.
[1] https://f-droid.org/en/packages/eu.siacs.conversations/
[2] https://gajim.org/download/
[3] OMEMO is an XMPP Extension Protocol (XEP) for secure multi-client end-to-end encryption based on Axolotl and PEP. Might want to go through https://dev.gajim.org/gajim/gajim-plugins/-/wikis/OmemoGajim....
Check out these files:
- src/main/java/eu/siacs/conversations/ui/RtpSessionActivity.java
- src/main/java/eu/siacs/conversations/services/AppRTCAudioManager.java
- src/main/java/eu/siacs/conversations/services/AppRTCBluetoothManager.java
For the most (or all?) part it seems like it is related to Bluetooth audio. There are stuff about establishing connection to headsets and whatnot.
[1] https://f-droid.org/repo/eu.siacs.conversations_42023_src.ta...
I've been looking for a modern self-hosted chat solution. I want it to be XMPP so badly (running XMPP with something like prosody is so convenient). The clients are really letting me down though. Desktop clients are old-fashioned and awful (I could get behind that, but I don't think my kids could). The mobile situation is even worse.
The new-fangled chat solutions (Matrix, Zulip, etc.) are interesting, but the operational requirements are insane (in the case of Matrix, I'm also very nervous about reliability).
I can't say I'm super hopeful, but I'm rooting for you, XMPP.
Sending push notifications, which is broadly necessary for achieving both performance and battery efficiency, has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Federated systems with multiple apps were pushed out because there was no sane way to achieve that with the push architecture, and that's still the case. You see the same thing with nearly any third-party app, they're nearly always partly-crippled experiences because the first-party will not send push notifications to anything but their own app.
If there was, it wouldn't take much to make an XMPP extension or three for the client to provide a push url to the server. Client devs would (probably) need to standup a push proxy, so xmpp server pushes to client server pushes to client, because I don't think many platforms give out push urls that can be securely passed on to 3rd parties. There's some expense there, but not a whole lot, IMHO.
What I really like about XMPP is that I can do precisely this. Also, setting up and running prosody is dirt simple if you have any UNIX experience. IMO it's even simpler than running your own web server.
While it's been an awfully long time now, I seem to remember that services like AIM didn't successfully move to mobile because they required stateful connections similar to telnet/SSH, and that was something that just wasn't (and largely still isn't) possible under iOS.
AIM is a lot like AIM, and it worked fine on BlackBerries.
Google had an xmpp system (google talk) for which they have a first-party app which they send push notifications to. No other xmpp app can take advantage of that for google accounts - they all need to run, essentially, an xmpp-bouncer + their own push notification infrastructure and client implementation.
In ye olden days, a google-free version for google-free xmpp accounts could not be built in many cases, as the mobile device's APIs wouldn't let you hold open connections in the background like that - that was unique to the platform-owner (Android / iOS). Now you basically can, but each implementation increases battery use, so there's a fair bit of pressure to use the built-in one instead... which you can't do, Google won't send your app any push notifications that are intended for their apps.
---
The same thing applies to email apps, for example. IDLE just plain doesn't work well enough on phones, so email apps build their own email backends so they can use google's push notification infrastructure to push notifications for google-owned email account events. Google is the first party here, owning the email account and infrastructure, but not sending notifications to other email applications.
And also for basically any third-party app for basically any service. E.g. Talon (a third party twitter app) has to resort to polling Twitter's API to do anything. But those at least aren't federated systems, so though I'm still a bit sad about that, it's much more understandable that it happens.
yep, that's the downside of xmpp, isn't it? How could that be mitigated?
Still, battery is important to consider, so what have we done in XMPP to improve energy efficiency in the past 15 years?
One of the first things we did was define a way for clients to reconnect a session that suffered a broken connection - the classic "I just went through a tunnel" scenario. With this optimization we gained two things: a way to quickly reconnect without resynchronizing everything, and a guarantee that no traffic was lost in the process due to the network interruption.
Secondly, we've implemented traffic optimization in servers. Clients will tell the server when they are idling in the background, and the server will stop sending any traffic that isn't time-sensitive. As soon as the user focuses the app, it tells the server and the connection switches back to "real-time" delivery. This behaviour helps keep network activity low when the client is in the background, and prevents continuously waking up the device's radio (such wake-ups can be quite power hungry over the course of a day).
Finally, modern mobile XMPP clients support push notifications, which is the Apple/Google sanctioned way of solving this problem. It means that you can safely close the XMPP client entirely and still get notified when you receive messages.
There's probably more besides these things that I've forgotten but I think these changes are the highlights!
Not understandably at all, the reason for the lockdown is not for your benefit even if it is portrayed as such. Push notification can be run just like SMTP and is subject to the same type of abuse with the big difference that it actually easier to keep the spammers out since you know up front which senders are allowed to send notifications. It would be fully possible to self-host a push notification daemon which connects to those services which are meant to send you notifications, to which your devices connect for notifications. If you don't want to self-host it would be possible to choose a notification service just like you can choose an email provider. Things could be just as hands-off as they are now without being forced to open an Apple/Google/Microsoft account and hand over your communications to them.
Don't be fooled by these 'for your protection' lockdowns, they are for the benefit of the one doing the lockdown, not for your own.
And tbh I'm not sure SMTP serves as all that positive of an example. It works, sure, but the reputation system and extreme complexity that has sprung up around it makes it difficult for newcomers to join - I can't just host one from my house, most email hosts will reject my emails. It works in spite of all this because it has too many large actors already using it for any new ones to stand any chance of rejecting (or improving) it.
> Signup for an XMPP service anonymously
Unmoderated networks quickly degenerate spam pits from Hell. It worked in 90s when everyone was still polite in Internet.
I'm ashamed to admit this but I even wrote software what ran on Windows 95 and would spam chat rooms with thousands of phrases generated on the fly from a dictionary. The intention was it would run over a RAT (also of my creation) and get other people booted off the chat room. ie the spam would be posted by other people in chat rooms against their will and channel admins would then kick them. I wrote this because at college we "only" had dual ISDN lines and kids in chat rooms would slow down my warez downloads.
I know, I know, the justification is worse than the tool itself. But we were young, I've grown up since and these days the lessons I've learned from my college exploits are put to good use :)
There were plenty of mobile applications that supported multiple chat protocols. There might even still be. The issue is proprietary protocols would often change breaking support -- I suspect intentionally breaking support for 3rd party client.
Linux / Unix nerds running FOSS would be tolerant of that but I suspect your average smart phone user who might have spent 99c on the client would be less understanding.
kaidan.im is also a new KDE client.
Yeah! I ran my own XMPP server on my home network and used it to accept status messages from other boxes on my network. Worked really well. The clients were generally horrible though, especially the IOS ones. I've now switched to MQTT.
These days I believe very much in identifying and serving a specific set of users. XMPP is just a protocol, it has lots of potential applications, but it's nothing unless you channel that into a tangible usable product for real people.
This epiphany came to me after more than 10 years of working on XMPP as a server developer and spending time promoting open communication protocols to people. It was soul-crushing that at the end of a day I would still see my own family communicating with each other via WhatsApp.
Six months after the initial Snikket prototypes, and after a little user testing, I migrated my family over to XMPP by sending a simple invitation link (the start of the Snikket onboarding journey). They're now using it daily and totally happy with it. I'm beginning to hear similar stories from others who have repeated this with their own families/groups and their own Snikket setups.
All it took was to look at the issue through the eyes of "normal people" for a moment, and it changed my approach (and success rate) significantly.
My focus with Snikket is on making it as easy as possible for people to run their own server (hosted or self-hosted), and to avoid a repeat of the Google situation where 99% of the network was controlled by a single (volatile when it comes to messaging apps) entity.
Snikket may not be for everyone, but that's kind of the point of XMPP. Snikket users can text and call Quicksy users with E2EE, and vice-versa, despite using two different systems.
What do you think the best path is to that feature? Element seemed to have audio calls already, but not voice channels.
Also basic features like push to talk and noise thresholds are key.
Do you know any alternative Linux clients?
I'll have a dig in the conf files, perhaps I can configure an account manually.
Siskin seems to be the best of these three, but is neither as reliable nor as feature-complete as Conversations on Android or Gajim on the Desktop.
I think Android is the only platform that currently has a good user experience with Conversations or Quicksy for the less technical people.
The iOS app hasn't yet been through a thorough visual review, though it is planned in the coming months (a number of fixes are already in beta builds though).
Thanks for the feedback!
If we got a nickel from everyone that complained about XMPP client fragmentation, we would have funding to pay enough man-hours to get high-quality clients for every major platform and even the minor ones.
It's a nice protocol, but if you're missing all the conversations it doesn't help. When it was popular, it was the system that let you connect Yahoo to Google to MSN to Facebook to Zephyr to... it's network effects, people have to be on it for anyone to want to use it.
It's a variation of the prisoner's dilemma. If one party shares and the other doesn't, the market becomes lopsided. It's why every big permissively licensed non-copyleft product so far hasn't managed to build an ecosystem outside of a few select distributors.
With protocol specifications the problem is much harder. Market dominance can be maintained by slight incompatibilities.
So I could connect to all the networks from one app
Today the would connect Facebook, Teams, Slack, Whatsapp, signal, etc etc...
That would be the dream....
Most people, including myself, don't really care about the proprietary nature of Discord. I can fairly trivially move off Discord if it fails me so I don't really see the point in working harder to use Matrix.
[1]: https://cinny.in
The XML schema felt bloated (baring in mind a lot of people were still on dial up, and later the data caps of early feature/smart phones), chat client support was rubbish, linking to other servers was non-trivial (they'd often be running extensions you weren't. In fact the whole extension system was broken). And IIRC the leading XMPP server was written in Haskell and the only way to configure it was to edit the source. It was just a horrible experience all round.
I had Skype, MSN, AOL IM, IRC, and another (possibly IRQ?) all linked together -- most of which are proprietary -- under one server and the only protocol I couldn't get working properly was XMPP. Which really says a lot about the state of XMPP at that time.
Maybe things have improved. But now that Google Talk, Facebook Messenger and others don't use XMPP any more, there is even less reason to bother trying.
Suffice to say; go and download a modern client like conversations.im and install ejabberd.im on a machine somewhere (or just use a throwaway account on a public server). The ecosystem has significantly improved since you last tried it... 15-20 years ago?
> Maybe things have improved. But now that Google Talk, Facebook Messenger and others don't use XMPP any more, there is even less reason to bother trying.
There's no shortage of chat protocols out there. As far as I'm concerned XMPP had it's chance and failed to deliver. While I'm not a fan of NIH (not invented here) syndrome, I'm even less of a fan of polishing a turd, because that's what leads us to monstrosities like STARTTLS, FTPES and so on and so forth.
I myself have rediscovered XMPP in the past two years (whilst using other tools like Matrix for other roles). The experience has revolutionized the way I view chats apps and even I host my own server on my own bare metal.
The thing quite simply flies and is rock solid. I've also seen multihour WhatsApp and Signal outages go by whereas my friends and I have kept chatting on my reliable server. Never had an issue with STARTTLS.
XMPP has silently evolved with the times and is far better than ever and should simply be the go to if you want to have control over your own comms.
No need to be abusive. And lets not forget I'm basing my views on technical arguments, which is the opposite of being narrow minded. If you want to convince me that XMPP is worth trying then you need to provide me with technical reasons why I should.
> I myself have rediscovered XMPP in the past two years (whilst using other tools like Matrix for other roles). The experience has revolutionized the way I view chats apps and even I host my own server on my own bare metal.
Good for you. I wasn't suggesting nobody should use it though. I was only answering why I wouldn't be investing any more of my own finite amount of free time on it. That doesn't make me narrow minded. That just makes me busy enough that I need to make trade offs with my time.
> The thing quite simply flies and is rock solid. I've also seen multihour WhatsApp and Signal outages go by whereas my friends and I have kept chatting on my reliable server.
You can't compare a personal chat server for friends with a service with multi-national infrastructure used by millions. Problems grow exponentially with scale.
> Never had an issue with STARTTLS.
Then you've not spent enough time working with SMTP. :) But my point wasn't that STARTTLS sucks (though it does) but rather that STARTTLS should have been a warning sign that we need to abandon SMTP for something better.
> XMPP has silently evolved with the times and is far better than ever and should simply be the go to if you want to have control over your own comms.
Maybe but I haven't yet heard what any of these improvements are from you though. You've talked about how XMPP makes you feel, you've talked about how my previous post made you feel, but you've not actually talked about XMPP itself. For a technical conversation your reply lacked a lot of detail about the tech and a lot of abuse towards the person you're trying to persuade.
You're not, you just simply have a strong opinion about something you haven't even tried (in the last decade) and thus basically know nothing about it. It's a view based on ignorance.
If you want a grown up conversation then I'm happy to engage. But don't waste my time with petty insults and vague claims of greatness when you're unwilling or unable to add any technical detail to back up your bluntness.
Have you even tried reading the original article that this thread is literally linked to at the very top?
- They talk about evaluating extensions but extensions was one of the things I raised as being a turn off.
- They talk about clients, but there's no shortage of other chat solutions out there with decent clients these days. A list of platforms and links to clients doesn't tell me whether XMPP clients are buggy or well polished. Let alone why I should use XMPP over another solution with a well polished client.
- They talk about privacy but even on XMPP that's not a given and there are other solutions out there if you're interested in privacy.
- They talk about voice and video calls, and that at least is new from when I last tried. So that's one thing in favour of your point. However I already have a half a dozen platforms that do that -- platforms that already have my friends and family on it. Why should I set up another? And moreover how am I going to convince my friends and family to install this other chat client if you can't even convince me, a fellow technology geek, to try it?
This is why I talk about XMPP missing the boat. People gave XMPP a try and moved on. And for all my asking, neither the article nor yourself can explain why XMPP is a cut above the rest. Worse yet, all the talk in the article of "evaluating extensions" and "reviewing privacy" doesn't convince me that it's any less annoying to set up either.
They can be daunting at the start (as it is with learning any new technology ecosystem), but once configured; it's not something one thinks about.
> - They talk about clients, but there's no shortage of other chat solutions out there with decent clients these days. A list of platforms and links to clients doesn't tell me whether XMPP clients are buggy or well polished. Let alone why I should use XMPP over another solution with a well polished client.
My personal favourite is conversations.im, but these days, with the notable exception from Pidgin, they all tend to interoperate fine. iOS clients still has issues with push notifications (thanks to the OS level) that are being fixed: https://snikket.org/blog/snikket-ios-public-release/
> - They talk about privacy but even on XMPP that's not a given and there are other solutions out there if you're interested in privacy.
Disagree on this point:
- Other solutions generally require a number or email address. On XMPP, you can simply create an account by pointing a client at a server and asking for an account (you can even create a completely random pseudonym).
- Other solutions do not generally allow you to self-host (Slack, WhatsApp, Signal, etc), so they're not private even to begin with.
- Other solutions don't generally have the flexibility of federation to let you talk to other servers (such as Mattermost).
- XMPP clients also have optional support for Tor, and servers can be hosted on hidden services and can talk to servers over Tor too - which is much better than Signal and others should you desire an elevated level of privacy (I do not bother with this point, but if I met someone who did - good to have as an option)
- Things like Briar that do P2P do exist, but their clients are lacking in other areas such as voice calls, multi-platform support, etc.
> - They talk about voice and video calls, and that at least is new from when I last tried. So that's one thing in favour of your point. However I already have a half a dozen platforms that do that -- platforms that already have my friends and family on it. Why should I set up another? And moreover how am I going to convince my friends and family to install this other chat client if you can't even convince me, a fellow technology geek, to try it?
It's just chat at the end of the day, and as I said - I did not want to rely on a third-party for something as crucial as my personal, private comms.
Another thing that I enjoy about XMPP is that the clients support multiple accounts as a first-class feature (something you cannot do on Signal/WhatsApp). Theoretically; from the same app; I could have accounts for personal, work, a neighborhood chat, and an account over at sfconservancy[1], whilst being able to enable/disable as and when I want to.
This last point is more pertinent as people become fatigued and bored of having to have multiple apps for different contacts across multiple platforms (a pain point made worse as new chat apps come into life every other year and contacts decide to move over). In my case, I know that there will be open-source XMPP clients that I can use to log into my server and still have the same contact list.
Tools like https://quicksy.im/ also exist to make it easier for normal people to adjust to an XMPP client before moving them over to non-number based accounts.
[1]: https://sfconservancy.org/blog/2021/jun/21/chat-options/
It’s not falling out of fashion a bit with many of the trading clients moving to web based interfaces but it have a sense it will still stick around for a long time.
And there are federated networks like the one from Markit
https://www.businesswire.com/news/home/20131007005587/en/Glo...
I don’t think there is a single major financial messenger today that isn’t based on XMPP.
In the end I left the project before they got it working. I have no idea if it ever got deployed.
Quite the opposite: users actively do not want federated systems, as federated systems allow anyone on the internet to spam them. This is why Google Talk stopped supporting federation: 99.9%+ of users never used it to talk outside of Google instances, and 99.9%+ of the inbound messages from the outside world were spam.
Large walled garden IM platforms have the spam problem potential. It's solved by using whitelists (via invites) instead of blacklists. The same mechanism is trivial to accomplish using XMPP, and I'm sure there are already XEPs for that. (Multiple, even!) You can end up with invite spam, but that's exactly the problem you see on Facebook, WhatsApp, etc.
As for me, I ran my own XMPP server for years along side an SMTP server and never received XMPP spam. Both my XMPP and e-mail addresses were the same, and my e-mail address had been in use since circa 2000 and exists on countless spam lists. I doubt the spam problem could have been very significant. I never used a GMail or GTalk address, but of the people I know who did, some of whom I chatted with over federation, I never once heard of GTalk spam.
Anybody who cares about privacy should care about federation and should advocate for federation. Being cynical about the potential is counterproductive. If you think federation is impractical because centralization is required to prevent abuse, then you must admit that privacy beyond the current status quo is also impractical; just give up. If you don't want to give up on privacy, don't give up on federation. The technical problems to federation will never go away, but the will to solve them is entirely voluntary. (Though, if we legally mandate federation then that's at least a substantial, long-term commitment.)
Facebook/Messenger? Not a week goes by without some sexy lady wanting to have intercourse with me.
This does not seem like it’s a federation issue.
But both Facebook and Google refused federation, and then phased out xmpp.
I assume all the big players are equally eager to kill email, but haven't quite figured out how yet.
First, I can't remember who said it but there's a quote that goes something like (paraphrased) "open standards are for losers" (side note: if anyone has the original quote, please let me know). It's a pithy way of pointing out that the winners in any market don't care. Others want open standards to level the playing field.
Second, and I can't stress this enough, literally nobody wants federated systems apart from a handful techno-enthusiasts. It doesn't solve any problem users care about. In fact, it tends to create problems users do care about.
Look no further than the POTS system. Part of the reason you have spam and robocalls is one provider is pretty much free to send or forward traffic to anyone and to essentially spoof the sender such that things like caller ID do very little. Plus there's all the routing issues. Users tend to want to keep their numbers so you can't use a phone number as an identifier anymore. You have to use something lower level (think of this as the difference between a domain name and an IP address) and then deal with all the porting issues and the security issues that creates (eg SIM jacking).
As long as people continue to use the Internet for their own benefit, that's fine. The internet that will be the ultimate "open standard" for the masses of people.