If this news has anyone tempted to dust off an old jabber.org account, you may get an "account disabled" notification when trying to log in. Try again in an hour or so and you should be able to log in successfully.
Why? We've had well over a million accounts registered at jabber.org. We came up with a hacky solution to speed up the migration: we initially imported all accounts that have been active in the past 6 months. Now we're importing them on an on-demand basis. If you attempt a login and your data has not been migrated yet, you'll get "account disabled" error but your account will be prioritized for import during the next migration run (which is now running asynchronously multiple times per day).
Also note that the migration this weekend was just the first step in bringing the service back to life, it's still lacking a number of modern features that are widespread elsewhere in XMPP these days (for example, no push notifications for mobile clients). We'll be turning these things on over the coming weeks.
Finally, once the dust settles, we'll be looking towards the future of the service. Potentially opening up registration again (closed since 2013) and options to help the service be more self-sustaining (such as accepting donations).
Does the disabled-message also tell you to come back in an hour? If not, you risk people trying, seeing their account is deactivated and never bother to come back.
My one experience with Prosody was writing a plugin to extend Jitsi Meet to show a list of the available conferences and their participants before you join (never got around to developing it beyond the prototype stage, but at least a deliverable that came out of it is a
thorough explanation of how to use lib-jitsi-meet that I felt was missing: https://github.com/solarkraft/lib-jitsi-meet-demo - I still believe the feature to be important for allowing spontaneous meetups -don't you want to steal my idea?).
What the hell, I hated it. The parts I needed were super under-documented and Lua/their implementation of it lacks so many features normal languages have - I had to copy a lot of things together from the web to answer basic questions like "what properties does this object have".
To their credit the people in the chat room were very responsive and helpful; I probably should've asked there earlier instead of making sure I don't ask a redundant question.
How do you develop your Prosody plugins? Did I miss some obvious way to set things up so that it's actually convenient? I used the Docker Jitsi Meet setup.
And, while you're here, maybe you could explain the reasoning behind break-out rooms not just being their own conferences (or so it seems to me).
I agree. Matt and his team are very active in the community helping others implement Prosody and make use of XMPP. He even took the time to provide me with helpful feedback a few years ago[1] when I took my first steps with XMPP.
What happened with XMPP? Seems like the fragmentation of extensions kind of broke the client/server ecosystem, but the fundamentals seem solid, used by Whatsapp successfully, but for some reason recent open messaging alternatives seem to decide to develop new protocols rather than build on top of XMPP.
The client/server ecosystem in XMPP is going strong. Fragmentation is no more of an issue in XMPP than any other open ecosystem. That's not to say it's easy to prevent things being fragmented in an open ecosystem, but it's something we try to stay on top of.
For example, for some time now the XMPP Standards Foundation annually publishes the "compliance suites" which detail for developers what up-to-date implementations are expected to be supporting. We recently updated the xmpp.org website to automatically calculate and display the compliance status of every project.
Monal's support for calls is in alpha builds, and they're hoping to release it in the coming months. Gajim (written in Python) is looking for someone to help them out with their audio/video call stack, which needs some attention.
> Seems like the fragmentation of extensions kind of broke the client/server ecosystem
It did. It was bigger and bigger mess, which feature in which client was supported by what server. I still remember how spotty basic stuff (nowadays) like "send file to someone" was.
And then corporations happened. There was a brief beautiful period of time where you could just put up your XMPP server and chat both with Google and Facebook users directly, but companies figured out closing down their gardens is more profitable and it was no longer the case
> but for some reason recent open messaging alternatives seem to decide to develop new protocols rather than build on top of XMPP.
Coz it is a fucking mess of XEPs spottily implemented between clients and servers, and not always that user friendly.
If you can control server, protocol and client you can just implement stuff. You don't need to make a spec, hope other people's client implement it, start using it in your server, and hope everyone else agrees on it too. And you can just deprecate stuff that turned out to not work well, or just need to be done differently.
Frankly, XEPs shouldn't exist. There should be just XMPP 1.0, 2.0, 3.0 etc. with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
You either implement all or are noncompliant, no more "well, you send a message but target client doesn't support this XEP, they get garbage"
It was a terrible pile of overengineered sophomoric semantic-nonsense second-system effect garbage from day 1. The need for everything to be an extension and XML was a millstone around every client and server's neck, the XML validation is directly blamed for the downfall of Google Wave but it also seems like that drag was the primary reason why the client experience always sucked. The reason the only successful uses of XMPP are in closed ecosystems isn't nefarious companies trying to control it (although there are those), it's because the only way you can actually get a reliably compatible experience for the kind of rich chat that everyone expects these days is if you control the clients and servers together.
I genuinely think the main reason there are no successful open-source chat apps is that XMPP dragged them all down.
"recent open messaging alternatives seem to decide to develop new protocols rather than build on top of XMPP"
XMPP is reasonably specifically a protocol for Instant Messaging. You can theoretically do whatever you want with it, and you can theoretically turn it into a mechanism for delivering social-networking style asynchronous messaging, but it doesn't necessarily bring a lot of value, and it makes a certain amount of fundamental architecture decisions that aren't necessarily the best for a social network.
I am interpreting your "recent open messaging alternatives" in the social network framework because my perception is the major ones you might be thinking about are those things, like Mastodon and such. I'm not aware of hot new open IM protocols that are just "old school" IM.
I used xmpp for a while and it has a fairly good hosting experience (easy to setup and maintain) but it lacks good clients. At least clients that the typical whatsapp user would like. And now, that everyone pushes matrix as the best alternative to everything, the situation will likely not change.
There never was meaningful money behind it. It seems the only way a protocol can ever grow today is by having for-profit companies sponsoring its development, doing the marketing, pushing it to individuals, companies and public services. That's not too hard to understand: at some point you need people working on it, and in a capitalistic society you need to pay them, and thus you need to somehow make money. Even with all the goodwill and proper licenses and all, you need massive humanpower.
Google, Whatsapp, Fcaebook all used a form of XMPP but never intended to propel it as a federated protocol, only for their own usage.
Prosody (server) and Monal (iOS client) make a great combination. I'm not aware of anything for Android that's as elegant as Monal but I'd be happy to hear people's suggestions.
Conversations [1] is the best Android XMPP client I know. IIRC they pushed the adoption of OMEMO and implemented it first, before the desktop clients could catch up.
Valid question! Honest answer: the folk involved (including me) have more experience with Prosody these days.
Jabber.org previously ran ejabberd for years, in fact that's what it was running when I joined the admin team (I was also running ejabberd on my personal server at the time). We had quite a few problems with it back then, and for various reasons decided to switch to something else to help bring some stability to the service. This is all in the distant past (literally 10+ years ago), and I know for sure that the several problems we kept encountering on jabber.org have been fixed long ago. Many other large XMPP services run ejabberd successfully, including conversations.im.
But now that Prosody is more mature, the team has more experience with it, and it has a few more features than ejabberd that we'd like to support, it's what makes the most sense for us right now.
If you're trying to decide between ejabberd and Prosody, they average out to being equivalent in terms of protocol support. ejabberd has clustering, and a commercial option for people who want that. Prosody has a strong focus on extensibility, and has hundreds of community modules at https://modules.prosody.im which provide various kinds of extra functionality.
I don't think either project is overall "better" than the other, but each has strengths and weaknesses for specific use cases.
[+] [-] MattJ100|3 years ago|reply
Why? We've had well over a million accounts registered at jabber.org. We came up with a hacky solution to speed up the migration: we initially imported all accounts that have been active in the past 6 months. Now we're importing them on an on-demand basis. If you attempt a login and your data has not been migrated yet, you'll get "account disabled" error but your account will be prioritized for import during the next migration run (which is now running asynchronously multiple times per day).
Also note that the migration this weekend was just the first step in bringing the service back to life, it's still lacking a number of modern features that are widespread elsewhere in XMPP these days (for example, no push notifications for mobile clients). We'll be turning these things on over the coming weeks.
Finally, once the dust settles, we'll be looking towards the future of the service. Potentially opening up registration again (closed since 2013) and options to help the service be more self-sustaining (such as accepting donations).
[+] [-] matsemann|3 years ago|reply
[+] [-] petre|3 years ago|reply
[+] [-] durpkingOP|3 years ago|reply
[+] [-] winrid|3 years ago|reply
[+] [-] saghul|3 years ago|reply
We use Prosody successfully for powering the signalling in Jitsi Meet. Its extensibility has allowed us to develop many many features easily.
[+] [-] solarkraft|3 years ago|reply
What the hell, I hated it. The parts I needed were super under-documented and Lua/their implementation of it lacks so many features normal languages have - I had to copy a lot of things together from the web to answer basic questions like "what properties does this object have".
To their credit the people in the chat room were very responsive and helpful; I probably should've asked there earlier instead of making sure I don't ask a redundant question.
How do you develop your Prosody plugins? Did I miss some obvious way to set things up so that it's actually convenient? I used the Docker Jitsi Meet setup.
And, while you're here, maybe you could explain the reasoning behind break-out rooms not just being their own conferences (or so it seems to me).
[+] [-] siparikh|3 years ago|reply
[1] https://samirparikh.com/blog/this-is-how-you-run-an-open-sou...
[+] [-] atsmyles|3 years ago|reply
[+] [-] aojdwhsd|3 years ago|reply
[+] [-] f1refly|3 years ago|reply
[+] [-] pull_my_finger|3 years ago|reply
[+] [-] Ambolia|3 years ago|reply
[+] [-] MattJ100|3 years ago|reply
For example, for some time now the XMPP Standards Foundation annually publishes the "compliance suites" which detail for developers what up-to-date implementations are expected to be supporting. We recently updated the xmpp.org website to automatically calculate and display the compliance status of every project.
This, for example, is not fragmentation: https://matthewwild.co.uk/uploads/screenshot-20230119-167413...
Monal's support for calls is in alpha builds, and they're hoping to release it in the coming months. Gajim (written in Python) is looking for someone to help them out with their audio/video call stack, which needs some attention.
Servers (as in, actual deployments) are monitored via https://compliance.conversations.im/ - which feeds into curated lists such as https://providers.xmpp.net/
[+] [-] ilyt|3 years ago|reply
It did. It was bigger and bigger mess, which feature in which client was supported by what server. I still remember how spotty basic stuff (nowadays) like "send file to someone" was.
And then corporations happened. There was a brief beautiful period of time where you could just put up your XMPP server and chat both with Google and Facebook users directly, but companies figured out closing down their gardens is more profitable and it was no longer the case
> but for some reason recent open messaging alternatives seem to decide to develop new protocols rather than build on top of XMPP.
Coz it is a fucking mess of XEPs spottily implemented between clients and servers, and not always that user friendly.
If you can control server, protocol and client you can just implement stuff. You don't need to make a spec, hope other people's client implement it, start using it in your server, and hope everyone else agrees on it too. And you can just deprecate stuff that turned out to not work well, or just need to be done differently.
Frankly, XEPs shouldn't exist. There should be just XMPP 1.0, 2.0, 3.0 etc. with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
You either implement all or are noncompliant, no more "well, you send a message but target client doesn't support this XEP, they get garbage"
[+] [-] bamboozled|3 years ago|reply
[+] [-] lmm|3 years ago|reply
I genuinely think the main reason there are no successful open-source chat apps is that XMPP dragged them all down.
[+] [-] jerf|3 years ago|reply
XMPP is reasonably specifically a protocol for Instant Messaging. You can theoretically do whatever you want with it, and you can theoretically turn it into a mechanism for delivering social-networking style asynchronous messaging, but it doesn't necessarily bring a lot of value, and it makes a certain amount of fundamental architecture decisions that aren't necessarily the best for a social network.
I am interpreting your "recent open messaging alternatives" in the social network framework because my perception is the major ones you might be thinking about are those things, like Mastodon and such. I'm not aware of hot new open IM protocols that are just "old school" IM.
[+] [-] jonas-w|3 years ago|reply
[+] [-] seba_dos1|3 years ago|reply
[+] [-] andrius4669|3 years ago|reply
[+] [-] Gordonjcp|3 years ago|reply
[+] [-] rakoo|3 years ago|reply
There never was meaningful money behind it. It seems the only way a protocol can ever grow today is by having for-profit companies sponsoring its development, doing the marketing, pushing it to individuals, companies and public services. That's not too hard to understand: at some point you need people working on it, and in a capitalistic society you need to pay them, and thus you need to somehow make money. Even with all the goodwill and proper licenses and all, you need massive humanpower.
Google, Whatsapp, Fcaebook all used a form of XMPP but never intended to propel it as a federated protocol, only for their own usage.
[+] [-] daneel_w|3 years ago|reply
[+] [-] deaddabe|3 years ago|reply
[1] https://conversations.im/
[+] [-] Semaphor|3 years ago|reply
[+] [-] crossroadsguy|3 years ago|reply
[+] [-] nix23|3 years ago|reply
[+] [-] MattJ100|3 years ago|reply
Jabber.org previously ran ejabberd for years, in fact that's what it was running when I joined the admin team (I was also running ejabberd on my personal server at the time). We had quite a few problems with it back then, and for various reasons decided to switch to something else to help bring some stability to the service. This is all in the distant past (literally 10+ years ago), and I know for sure that the several problems we kept encountering on jabber.org have been fixed long ago. Many other large XMPP services run ejabberd successfully, including conversations.im.
But now that Prosody is more mature, the team has more experience with it, and it has a few more features than ejabberd that we'd like to support, it's what makes the most sense for us right now.
If you're trying to decide between ejabberd and Prosody, they average out to being equivalent in terms of protocol support. ejabberd has clustering, and a commercial option for people who want that. Prosody has a strong focus on extensibility, and has hundreds of community modules at https://modules.prosody.im which provide various kinds of extra functionality.
I don't think either project is overall "better" than the other, but each has strengths and weaknesses for specific use cases.
[+] [-] ipcress_file|3 years ago|reply
The only significant irritant for me is spam. Open registration servers are the blight of XMPP.
[+] [-] MattJ100|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] pabs3|3 years ago|reply