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.
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.
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.
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.
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.
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.
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.
AIM is a lot like AIM, and it worked fine on BlackBerries.
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!
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.
> 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 :)
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.
[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...
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.
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.
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!
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
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....
> 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.
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.