Hacker News new | ask | show | jobs
by hnlmorg 1851 days ago
That only solves half the problem. There's no easy (read: 1 click) way of quoting an older message. No easy way of handling notifications (read: not PMs but when someone mentions you in a channel like @handle in other chat services), no easy way of handling roaming, etc.

Yes, ZNCs solve some of these problems, but they're not easy to set up, the channel mentions isn't even remotely as intuitive as that in Slack et al and the playback history isn't as user friendly as the history in other chat services because it replays _n_ messages irrespective of whether you saw them or missed them while DCed. Which can make roaming a PITA at times.

I say all this as a someone who loves IRC. I've built IRC clients in the 90s, numerous IRC bots, ran ZNC services and even use IRC as my primary IM back in the early days of Android (and thus seen first hand the frustrations of using IRC on the train and getting frequent disconnects to my bounce).

IRC as a concept is amazing however IRC as a protocol sucks by modern day standards and while all the little workarounds are fun to hack together, ultimately they still fall short of what products like Slack and Discord are doing. So I can totally see why some people don't bother with IRC any more.

I've not (yet) played with Matrix. Maybe that's the spiritual successor to IRC. It sure as hell can't be any worse than XMMP (I _really_ wanted to like XMMP but just couldn't get past how unnecessarily over-engineered it was)
1 comments
tffgg 1851 days ago
Could you expand on XMPP being over engineered? (Just curious) Thanks
link
hnlmorg 1849 days ago
Sorry just seen this. It's been a long time since I've touch XMPP so I might get some of the specifics wrong, but IIRC it was XML heavy. Everything was an XML file. Every message. I know XML will have it's fans but for an instant messaging app that create a hell of a lot of overhead. But in fairness to XMPP, it was created in the era when XML was basically the go to if you needed a strict schema.

Joining to servers was a pain as well. XMPP was intended to be federated but in practice it didn't really work well. A large part of that reason was because XMPP described a base protocol but then different servers could support different extensions off that and if your server didn't support the same extensions then you couldn't join. These extensions could vary from the "well that should have been part of the base standard to begin with" to the absurd.

There was also a lack of decent clients for XMPP. To be fair, this isn't XMPP's fault but rather the lack of adoption. But because XMPP was something that Google or others would use as a base to build their own IM network from, all of the good XMPP clients were locked into specific networks rather than like with IRC or Matrix clients that are designed to run on any network.

A lot of the tooling for XMPP wasn't particularly noob friendly either. It was very much built by engineers for engineers rather than intended for your average nerd to set up a private servers. I remember one XMPP daemon was written in Haskell and all the config was hardcoded so you had to edit Haskell source to bring the server up. Which isn't the easiest thing to do given how alien Haskell looks to non-Haskell developers.

link
MattJ100 1849 days ago
> IIRC it was XML heavy. Everything was an XML file. Every message. I know XML will have it's fans but for an instant messaging app that create a hell of a lot of overhead.

The "overhead" is minimal, especially with the features XML brings. A message looks something like:

  <message to="user@example.com" type="chat">
    <body>Hello world</body>
  </message>
In a world where people stream HD video over their mobile data connection without a thought, I'm pretty sure XML is not an issue. There are binary bindings (EXI), but they never really took off outside some niche IoT systems. It just hasn't been a problem. XMPP has even been deployed over unreliable high-latency HF radio links: https://www.isode.com/whitepapers/naval-xmpp-roadmap.html

> Joining to servers was a pain as well. XMPP was intended to be federated but in practice it didn't really work well.

The large active network of federating XMPP servers would disagree with you. E.g. https://blog.prosody.im/2020-retrospective/

> A large part of that reason was because XMPP described a base protocol but then different servers could support different extensions off that and if your server didn't support the same extensions then you couldn't join.

This isn't quite accurate. Every extension in XMPP is designed with backwards-compatibility in mind. Two servers not being able to federate is not really a thing - federation is in the base protocol. On top of the base protocol various things can be negotiated. None of these are mandatory. Two servers not being able to federate due to differing extensions is a myth.

> There was also a lack of decent clients for XMPP. To be fair, this isn't XMPP's fault but rather the lack of adoption. But because XMPP was something that Google or others would use as a base to build their own IM network from, all of the good XMPP clients were locked into specific networks rather than like with IRC or Matrix clients that are designed to run on any network.

For the record Google federated with the open XMPP network, and allowed third-party XMPP clients to connect. Other providers of XMPP were not so open (Facebook never federated, for example).

Opinions of what constitutes a "decent client" vary widely. Being an open ecosystem, XMPP has a wide and diverse range of clients, and many people quite happily use modern XMPP clients such as Conversations, for example.

The biggest problem is that most clients are "just" open-source projects backed by volunteer efforts. It's very hard to find real sustainability (e.g. funding) in open-source, let alone open decentralized ecosystems, so resources are more limited compared to proprietary competitors.

I wrote a bit about this at https://snikket.org/blog/products-vs-protocols/

> It was very much built by engineers for engineers rather than intended for your average nerd to set up a private servers.

I don't know which Haskell server this was (surprisingly), but I've been working on making XMPP server setup easier since starting the Prosody project back in 2008. More recently I'm also working on Snikket, which takes things to a whole new level - you can have a private XMPP server up in just a few minutes without any technical knowledge of XMPP: https://snikket.org/service/quickstart/

link
hnlmorg 1849 days ago
> The "overhead" is minimal, especially with the features XML brings. A message looks something like:

Yeah, something like that. Just with a hell of a lot more metadata and closing tags to accompany it. I'm all for strict schemas and the first to criticise IRC's protocol for being dated, but XMPP is an overreaction. It's too far the other way. But I do get why XML was chosen -- frankly there wasn't any better options in 90s. But that still doesn't mean it isn't noisy and the, in my personal opinion, wrong choice.

> In a world where people stream HD video over their mobile data connection without a thought, I'm pretty sure XML is not an issue.

Smart phones weren't invented when I was running XMPP and the kind of bandwidth you're boasting about is a very recent development in the grand scheme of things.

> The large active network of federating XMPP servers would disagree with you.

That's also a recent development. Plus look at the graphs: even now it still hard to argue that you're even close to reaching that same kind of critical mass as the major IRC networks currently have (let alone had in their heyday) and that's without addressing the elephant in the room that is Matrix and it's far steeper uptake climb than XMPP. I mean, sure, you have a small and loyal fan base but chat protocols depend on that critical mass in the same way that social networks do and I can't see XMPP ever achieving that because it's already missed its opening.

It's now 10 years too late to be talking about XMPP and yet that's when all the advances you keep bring up were started. The protocol was already > 10 years old at that point and many engineers like myself had tried it and given up.

> Two servers not being able to federate is not really a thing - federation is in the base protocol. On top of the base protocol various things can be negotiated. None of these are mandatory. Two servers not being able to federate due to differing extensions is a myth.

Maybe now, but I never managed to get it working properly ~15 years ago. It might have user error or such like but I'd ran private IRC networks, bounces, written 2 different IRC clients, a multitude of bots for different chat services (ie not just IRC) and run a whole plethora of other internet facing services and literally the only thing I could never get working quite right was federated XMPP. So I have a tough time accepting total blame for not getting it right.

And the shear that you can call it a "myth" suggests enough other people ran into the same or similar problems as myself for it to become a problem that people talk about in the first place. Which adds weight to the argument that perhaps it's not entirely fair to blame the users.

> For the record Google federated with the open XMPP network, and allowed third-party XMPP clients to connect. Other providers of XMPP were not so open (Facebook never federated, for example).

Yes I know. And for the record, you're literally making the same point I made.

> Opinions of what constitutes a "decent client" vary widely. Being an open ecosystem, XMPP has a wide and diverse range of clients, and many people quite happily use modern XMPP clients such as Conversations, for example.

Once again you missed the part where I mentioned it was a long while ago when I used XMPP.

> I don't know which Haskell server this was (surprisingly)

Me neither. tbh I can't even remember which hosting provider it was I was renting rack space from, it was that long ago.

I'm glad to see the state of XMPP has improved somewhat. But it's too little too late now because the industry has already moved on.

link