@norman @mattj @z428 @jom As being someone that managed Cisco Jabber for over a decade in day job: Jabber is not totally garbage. Mostly it works very well, though it has its shortcomings and issues, of course.
The main problem (as with many other solutions) is to have clueless or not-caring admins that are forced to manage things they don't like. Then you run into issues and blame the product.
(note: Jabber misses many newer XEPs, where Cisco is to blame for, of course)
@ij I see two fundamental issues with #xmpp: (a) Loads of broken clients with 1990s-ICQ-usability. And (b) all that extensibility that makes unencypted text/plain virtually the only reliable baseline for cross-server communication. The older I get, too, the more I am opposing "extensibility" on a protocol level as this seems pretty much a "techie" thing that makes things utterly complex at least if not "handled right". Like #signal - that at some point prevents "older" ...
@z428 @norman @mattj @jom I agree that we need to get rid off of the legacy stuff and maybe actively exclude older servers that are not compatible with, let's say, the latest 2 or 3 XMPP Compliance Suites, like before 2019 Suite or so.
Extensibility by itself is neither good nor bad. A stale protocol is as bad as an overly changing protocol. I agree that newer XEPs need to hit the "market" faster. But I think the XMPP community performed quite well in the past years after a long dorm before.
@ij What I sort of miss with #xmpp as well as with most of the #fediverse applications, actually, is something like a decentralized, "nomadic" identity that allows to connect to _any_ server running that technology and still have my contacts, my chat history, available. I think #matrix does a bit better here... but yes, the bad image of #xmpp definitely is a problem too. #xmpp needs some sort of "user-sided" representation to do end-user marketing and communication. 😉
@z428 @ij @norman @mattj @jom that problem with nomadic identity is a) that multi client is a mess, b) you will need again a way to find out where to deliver messages for a specific user and c) you would not be able to receive messages while being offline
If you want such an architecture you should better go with a p2p messenger like Briar in the first place.
@jr Not really sure. For sure I think this isn't trivial. But on the other side I assume it also is difficult because it isn't "obvious", it questions some core assumptions we often seem to take as granted these days - like storing user content on a local server or in a database, maybe even unencrypted, and knowing this ties this particular user to this particular machine. Things such as #ssb or #zot try to overcome this. Maybe #ipfs or #dat could help here too.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!