Comment by giancarlostoro | Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

The whole replace Discord thing is something I've been thinking about since 2019 and building my own IM platform since 2007. I hear people pitching every platform under the sun, but the one that I think has the most potential is XMPP. I've been building a modern client, nothing worth showing yet, but eventually I'll slap it on my blog and do a Show HN, for now it supports very basic XMPP primitives, adding friends, setting statuses, messaging friends, simple stuff.

Back in the late 2000s and early 2010s Google and Facebook supported XMPP, so you could login to Facebook Chat / Google Talk via Pidgin through an XMPP gateway (if if this was the default protocol or a bridge I'm not sure, its been years).

The biggest strength I see for XMPP is that because the web and even enterprise (think banking etc) uses XML too, everyone's optimized the ever living crud out of HTML so you could get some very high performance libraries to churn through all those stanzas, but also more importantly, its an extensible protocol. There's no reason it cannot have half of the things that exist on Discord, without disrupting the protocols OOTB design, because unlike IRC and other competing protocols, its extendable by design.

The best part about XMPP, or rather "protocol not service" as the OP discusses, is that you can go beyond the intended use case of it.

My favorite example - Arista network switches can be clients on an XMPP server. Control plane's have to be very slim. XMPP enables someone with a network operator to apply wide, symmetrical configurations across a network, without repetition. You can add the "core" switches to a group chat, and query them for information simultaneously.

Found an example article: https://jonw.mayhem.academy/arista-switch-wrangling-with-xmp...

You would never see Discord as a control plane management option, nor a Slack, Telegram or Signal option. But if all or a group supported XMPP, there would be a low resistance avenue for that (if someone really wanted it).

As it stands, we have product lock in due to each service having it's own system, with limits on interactivity. So I won't be cross-channel quoting outage causes directly from the switch in the company Slack any time soon.

Discord/Slack/Telegram get used for botnet command and control, and this method has been used since the irc days.

Oooh, a new client! between Fluux[0], Spaces coming to Movim[1], and now this, the XMPP ecosystem is getting exciting again.

[0] https://github.com/processone/fluux-messenger

[1] https://movim.eu/

Please do show it off when it's ready! Three cheers for XMPP and the return of protocol oriented thinking.

There is another thread about self hosting an XMPP server today

https://news.ycombinator.com/item?id=47034801

> The biggest strength I see for XMPP is [...] XML

It's an advantage, sure, but to me the serialisation format is the least interesting thing. Others are similarly optimized too. I think the extensibility and approach to standards is far more interesting than the fact it uses angle brackets instead of braces.

Are they still sending the entire stream as an element? Thereby making dealing with that xml a lot more painful than it needs to be.

Back in the days, I had to write my own parser, existing xml parsers couldn't handle the case well.

XML isn't a strength these days, IMO.

XML is much better than JSON for document-oriented data like messaging and web pages. Use the right tool for the job.

IM messages aren’t really documents. They are text with some very minimal formatting that could be expressed with markdown. Any media attached isn’t embedded in the document, it’s attached externally / rendered at the bottom.

The only example I can think that messages are expressed as documents is Microsoft Teams. And it’s as much an example of what not to do as anything.

Eh, XML is a machine-readable generic markup language. Why would you prefer using a less powerful format like markdown in a context like message representation? XML with inline tags seems the perfect fit.

Less powerful also means less complex and less exploitable. You can very easily grab a markdown renderer rather than trying to decode a .docx for messages.

Pretty much no messaging apps let you create messages more complex than markdown anyway.

From a security perspective, I prefer a widespread commonly used XML parser over your custom parser for markdown extensions.

IM messages seem to be documents just as much as email or many things you'd normally call documents. A reasonable definition IMO would be:

    A self-contained rich formatted text file/package that optionally contains attachments or media.

I'd disagree with that for most messaging apps. If you think about Discord or Slack for example. You have a plain text message and then media attachments externally. This could be very well expressed with JSON.

Very few messaging apps let you go beyond plain text and let you start embedding media or complex layouts inside a message.

Slack messages have a ton of formatting. You could implement it with some sort of extension on markdown but you'd have to write a custom parser. XML gives you a markup structure for free.

Slack canvases have full layouts including images.

Slack messages contains a lot of additional formatting and media.

Even whatsapp does formatting, so does signal.

What is a current popular messaging app that does not have rich text features?

It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine. Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.

> It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine.

Absolutely with you up to here, but...

> Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.

Absolutely not. Having seen the infinite different ways a naive implementation of XML goes wrong, arguably being one of the main causes of death for XHTML because browsers rightfully rejected bad XML, "Don't roll your own XML implementation" should be right up there with "Don't roll your own crypto".

I don't feel like it's going out on a limb to say that if someone needs to defer to a LLM to implement XML they're not qualified to determine if it's done it right and/or catch what it got enthusiastically wrong.

Oh sorry, I don't at all intend to say you should write your own parser! Totally agree: "Don't roll your own XML implementation"

What I was addressing is, interfacing with an XML parser and converting that into whatever your internal representation is, can be a chore. LLMs are great at that stuff.

I'm going to stand by my position there, if you're writing an application that's primary technical purpose is to communicate via an XML based protocol and feel the need to outsource the XML part to the bullshit machine, IMO you probably shouldn't be writing that application.

To each their own.

There's nothing really wrong with XML for this. What would you use instead?

I think the comparison today is more vs the Matrix protocol that is a more recent take at the same ideas, and JSON vs XML isn't the strongest argument.

XMPP was the first creep towards the bullshit of today. Unlike IRC, it makes you register, leak identifiers, centralise and transfer power over you to third parties. Exposing you to lawfare, downtime and wasted resources. Also, IRC is extendable.

oh please do show it! I love XMPP and the clients are few and far between. Does it do jingle?

Reply on news.ycombinator.com