Thread

Parley: Federated, decentralised chat that speaks plain IRC

330 points · 190 comments · davidcollantes

Conlectus · 1790598456 · focus · HN ↗
There’s a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.
In this case, this is basically a poorly specified implementation of half of XMPP. Of course, I half expect the LLM would have mentioned that at some point, but the repository does not.
1. dale_glass · 1790601737 · focus · HN ↗
 Unfortunately XMPP is an absolutely terrible protocol. IRC's not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.
 I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
 1. edhelas · 1790604673 · focus · HN ↗
 Why is it terrible?
 2. monkeywork · 1790605151 · focus · HN ↗
 >Unfortunately XMPP is an absolutely terrible protocol
 Can you provide more details here? I've never seen an issue with the protocol at all, more issues with feature difference between servers depending on what they have decided to implement or not.
 packetlost · 1790605308 · focus · HN ↗
 Most times I've seen complaints about it, it boils down to "XML being yucky" and the extension component model being difficult to write clients for, which is true but not really a fault of the protocol, it's more of an inherent tradeoff of supporting opt-in extensions at all
 dale_glass · 1790605785 · focus · HN ↗
 I don't have that many problems with XML myself, but XMPP is weird even in XML land, because it tries to do XML all the way.
 For instance, it works as a constant, uninterrupted stream. You never close the document until the disconnection. Which means you absolutely have to parse it with a stream parser.
 It could have been something sensible, like a document per message: "Here's 300 characters of XML document: <xml>....". But nope.
 And what's up with this? <a href="https://xmpp.org/extensions/xep-0394.html" rel="nofollow">https://xmpp.org/extensions/xep-0394.html
 tecleandor · 1790607894 · focus · HN ↗
 OMG, that XEP is extremely and unnecessarily complex. Just do, I don't know, markdown.
 That made me remember IBM JSONx... <a href="https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=20-jsonx" rel="nofollow">https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=2...
 F3nd0 · 1790609359 · focus · HN ↗
 What’s so complex about it? From what I gather (after skimming the document just now), you attach an extra element to a message which says how to style which parts of the message, from codepoint n to codepoint m, essentially. At least conceptually, that seems really simple and straightforward.
 Are there more elegant or natural ways to do it? Probably. But when you say ‘extremely complex’, saying ‘codepoints 7 to 15 should be bold’ is not what comes to my mind.
 amenghra · 1790612098 · focus · HN ↗
 The following example (from the spec) seems quite fragile:
 <message> <body>This XEP supports many things: * inline markup * code blocks * lists * and possibly more!</body> <markup xmlns="urn:xmpp:markup:0"> <list start="31" end="89" ordered="false"> <li start="31"/> <li start="47"/> <li start="61"/> <li start="69"/> </list> </markup> </message>
 dale_glass · 1790615496 · focus · HN ↗
 Things I don't like:
 * It's not standard. You can't plug in some normal formatting library there and be done with it.
 * You'll probably end up having to write conversions back and forth.
 * It's fragile -- if anything gets misaligned it'll break
 * It's tooling unfriendly. Think things like Nagios, Grafana, etc sending formatted notifications. Everything can do this or this, but practically nothing is set up to accommodate this format.
 * It leaks into other subsystems. You can't eg, just search/replace/insert/delete words if you need to for any reason without breaking this.
 Is it the worst thing ever? No, but it seems to go with the pattern that nothing in XMPP is normal or comfortable. Everything has this weird particular flavor to it and more complexity than necessary.
 If it were up to me, my option would be to support 2 things: Markdown for simple cases, and embedded HTML for when you really have to get fancy. Each of those can be handed out to existing code and you don't ever have to keep adding extensions because what if people want colors or something now.
 Groxx · 1790619198 · focus · HN ↗
 None of this seems particularly different from doing spans inline (what if you forget to close one? or they overlap?), but it has a major benefit of being very backwards compatible, supporting future variants in parallel for gradual migration, and doesn't require any changes to search tools. And separating markup instructions from content is generally a very good idea.
 And you could use markdown. Just get the rendered spanned text result and transpile it. This would be true for any editor as well, just get convert it to spanned text, edit, convert back.
 And with HTML you'll still have to specify what subset you support, and many tools won't support that either. Markdown suffers from this too, by supporting embedded HTML, though at least commonmark is pretty baseline and well supported.
 someonebaggy · 1790637760 · focus · HN ↗
 Since the whole thing takes place in XML land I think there's no excuse for making clients implement markdown parsers as well. Bold should be or <bold> or at least or . Embedding markdown in XML is silly.
 GoblinSlayer · 1790672069 · focus · HN ↗
 AFAIK, it's Matrix markup, the idea is to make plaintext easy to extract, so you can send plaintext notifications, keep it simple. Markdown is fragile too for some reason. You can't use normal libraries with untrusted messages, because normal libraries work only with trusted data. HTML sanitization works like conversion between different formats.
 someonebaggy · 1790685385 · focus · HN ↗
 Is it not easy to strip formatting from XML markup? Just keep the text and drop the tags.
 someonebaggy · 1790637655 · focus · HN ↗
 You're in XML land. Just do XHTML or whatever subset you think is useful for IM.
 [deleted] · 1790612042 · focus · HN ↗
 [deleted]
 mcv · 1790625182 · focus · HN ↗
 Is there a better standard available? As far as I know, XMPP is a real standard. If it's outdated, is there a better one?
 dale_glass · 1790605548 · focus · HN ↗
 Other people provided some info:
 <a href="https://news.ycombinator.com/item?id=9772968">https://news.ycombinator.com/item?id=9772968
 <a href="https://news.ycombinator.com/item?id=31133082">https://news.ycombinator.com/item?id=31133082 (article and discussion)
 But TL;DR:
 * It's hard to even parse, XMPP uses an uninterrupted XML stream. * The contents are often baroque and complex * Standards are a mess, and stuff that should be in core isn't * Data loss is possible * Protocol wasn't made for mobile devices * Multiple devices are terribly supported * Data loss is possible
 From my attempts long ago, and other testimonials, writing an XMPP client is a full time job of solving weird problems that shouldn't exist in something better designed.
 fishgoesblub · 1790605671 · focus · HN ↗
 Regarding the part part: <a href="https://www.process-one.net/blog/stop-telling-us-xmpp-should-use-json/" rel="nofollow">https://www.process-one.net/blog/stop-telling-us-xmpp-should...
 dale_glass · 1790605852 · focus · HN ↗
 What part part, sorry?
 p2detar · 1790606803 · focus · HN ↗
 > We hear this too often: “XMPP uses XML. It should use JSON—it’s more modern.”
 I can't take this write-up seriously if it starts like that. I still read the whole thing though and I couldn't find any solid argument as to why someone would prefer XML to JSON for XMPP.
 > This is especially true in browser environments, where XMPP streams run over WebSockets, which naturally frames the XMPP protocol. That’s why you are never actually working with XML trees consuming large chunks of memory. Modern implementations like XMPP.js go further and use LTX—a lightweight parser built specifically for XMPP’s streaming model—rather than the browser’s DOM parser. The result: developers work with JSON-like objects anyway. The wire format becomes invisible to your application code.
 That to me, is an argument for using JSON, not XML. XML is strong when you have elements referencing other elements in your document structure or DOCTYPE for grammar defs. I might be missing something but I don't get how streaming XML is to be preferred over JSON for XMPP.
 Dylan16807 · 1790618331 · focus · HN ↗
 If it was actually using XML as a markup language then that would be a reason to stick with it. But XML seems to be complicating things much more than it simplifies.
 >> XML remains the best format for representing trees—deep hierarchies of nested data. JSON handles flatter structures well, but good messaging protocols are extensible: extensions can be embedded at different levels and composed together, like Lego bricks. That’s where XML shines.
 Anything reasonable you'd be doing with messaging protocol is pretty flat.
 someonebaggy · 1790638103 · focus · HN ↗
 It should be JSON with embedded XML for message text markup, playing to each ones strengths... not combining two sets of weaknesses by framing in XML and then using Markdown to format the messages.
 GoblinSlayer · 1790676959 · focus · HN ↗
 Features complicate things, not markup. JSON protocols still do all the things xmpp does.
 [deleted] · 1790607134 · focus · HN ↗
 [deleted]
 nunobrito · 1790608370 · focus · HN ↗
 Identities. Creating an identity in XMPP is an absolute mess and requires domains along with approvals. At least in IRC this isn't complicated.
 My own preference goes to NOSTR, just a set of public/private keys as identity and nothing else needed.
 sellmesoap · 1790621563 · focus · HN ↗
 Or ANproto <a href="https://anproto.com/" rel="nofollow">https://anproto.com/ without the nostr baggage, what little there is.
 nunobrito · 1790629267 · focus · HN ↗
 There is zero baggage on NOSTR regarding identities. An npub became the non-ambiguous way to reference anyone regardless of where they are writing from.
 Thank you for the reference to that project called anproto, never had heard of it and I'm still without understanding what problem it really solves. Seems to encrypt texts but then contains zero outside metadata to route it somewhere. The website is very scarce on details for someone unfamiliar the scuttle-something they mention.
 someonebaggy · 1790637838 · focus · HN ↗
 Doesn't nostr also forego routing metadata?
 nunobrito · 1790669504 · focus · HN ↗
 NOSTR notes are very flexible. For example you can have the json include metadata which is essential to know where it should be going, or you can encrypt everything and send what looks like "garbage" to an open relay that can only be fetched by anyone with a key.
 There are dedicated profile notes which define which relays that account/identity prefers to send their messages but everything is flexible. It does forego much of the routing metadata, which in my opinion is an obstacle when you don't know which stations/relays are placed on a given geography but you want the message to "navigate" (sometimes quite literally) to a place/region.
 For that type of things I'm a biased fan of <a href="https://xprs.dev" rel="nofollow">https://xprs.dev because it bridges NOSTR identities/signing/encryption with APRS that can use store/forward and the routing follows any possible method include USB drives.
 sellmesoap · 1790714376 · focus · HN ↗
 The nostr baggage I referred to is the crypto culture on the network. I appreciate nostr for being sparse as well. ActivityPub doesn't feel approachable re: understanding the protocol.
 There's an example ANproto in use at <a href="https://wiredove.net" rel="nofollow">https://wiredove.net it's pretty clean but not very active, yet another experimental social network playground!
 throwawayffffas · 1790612700 · focus · HN ↗
 That there are issues with feature differences is a problem with the protocol.
 Good protocols are opinionated and make concrete choices.
 Extensibility typically leads to compatibility issues like the ones you are describing.
 rtpg · 1790645787 · focus · HN ↗
 I will say that the middle layer is not great. I have an XMPP bot and the "interaction with the network" stuff really is ugly and unfun.
 I think the protocol itself is... I mean it's fine, I guess? Protocols are tricky because a lot of stuff is bolted on and it's not really super stateless as a protocol. But like all the Python XMPP client libs (for example) are all real janky.
 The protocol is complex enough to where the "simple and easy" client libs require way more up front design.
 3. alwaysthiserror · 1790605261 · focus · HN ↗
 I once implemented the presence and basic messaging functionality of XMPP for a web site, using a braindead bridge (that I also wrote; so, the meaningful logic lived in the browser).
 Considering I'd never hosted an XMPP daemon and didn't know anything about the protocol (I'd used XMPP clients a little bit, but had never looked at the protocol) and got a server (that part, I didn't write), an auth connector for our website's authentication system (so the daemon would authenticate against that instead), prod-ready and the features I wanted all working smoothly and reliably in maybe three weeks of very part-time work (this'd be, like, 3-4 part-time days with LLMs now, tops, from the same starting point)... seems decent to me? I mean I did direct work with the protocol, didn't just glue together libraries, and it was pretty damn good. Also (and I know browsers seem to be retreating on this front, which sucks) being XML made it very nice to work with in a Web context, since you can just ask the browser to turn ~any XML into a DOM for you, and get a bunch of functionality for free.
 What's wrong with it?
 pmlnr · 1790611257 · focus · HN ↗
 These days complicated and/or complex == hard == bad.
 hnlmorg · 1790612591 · focus · HN ↗
 Which is understandable when messaging shouldn’t be a hard problem to solve.
 4. ryandrake · 1790606433 · focus · HN ↗
 > I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
 This is what boggles my mind. We're talking: Text. Over the Internet. It should not be a complex, difficult problem! We've been sending text over the Internet from the moment the Internet went online. So how is it that 10 companies have managed to find 30 different ways to do it, which are all incompatible with each other? You have to TRY to fail this badly.
 jodrellblank · 1790609427 · focus · HN ↗
 This is what boggles my mind. We're talking decades of arguments and discussions, dozens of different ways to do it, with dozens of tradeoffs that you could start listing with 20 seconds of thought, and still people just pop in like "why isn't it simple??" as if that's some award winning insight.
 Come on, try! Start listing some of the core features of the different protocols/clients and answer your own question as to why it isn't simple! Presence. Chat history while offline. Threading. Mobile devices. Intermittent/mobile/cellular/wifi/CGNAT connectivity. Multiple clients on the same identity and presence. Identity establishing and confirming. Encryption. End-to-end encryption. Backing up and restoring chats, encrypted chats, group chats. Federation. Friends/groups/permissions/trust boundaries. Markup, markdown, formatting, images, emoji, unicode, code blocks. Audio, video, broadcast, multicast. Discovery. Extensibility. Federation. Store-and-forward.
 > "We've been sending text over the Internet from the moment the Internet went online"
 And IRC has RFC 1459, RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194 and it does almost none of those things.
 And you can still use IRC. But IRC is not good. At this point it's either wilfull ignorance of what people use computers for, or it's indistinguishable from deliberate trolling.
 NoMoreNicksLeft · 1790610419 · focus · HN ↗
 Threading? God, I hate threads in a live chat. Is it never not awkward to use? Slack is the example I'm thinking of, though I'm sure it's shit everywhere else too. In Slack, rather than display the one threaded reply just below (maybe indented), it makes me go to another window, but then someone else is replying non-threaded, so I have to bounce back and forth for the next 10 minutes.
 hnlmorg · 1790617074 · focus · HN ↗
 I completely agree. Threads in Slack should be a great way to make conversations easy to navigate but damn did they fsck up ever part of the UX:
 - opening threads in a new window is in some hard to find and hard to remember location
 - threads can’t be inlined (like you’ve described). I actually like how they’re in a pane to the right but sometimes that causes issues (as you’ve described). Sometimes it’s just that the view is too narrow.
 - there’s no way to shift non-threaded comments into the thread. I’ve lost count of the number of times conversations have happened over multiple threads and/or non-threaded replies.
 The way they implemented it is a complete clusterfuck.
 exogenousdata · 1790628542 · focus · HN ↗
 As an anecdotal counter-point, I love threads in a live chat. When used correctly, it means when my idiot friends start having a heated discussion about some random topic while I'm at work, I get one 'ding' from my phone and then never again until I start interacting or they @ me. As opposed to the 427 new notifications I get on my phone about whether Golden Eye was better than Mario Kart 64.
 Ultimately the tech is only as good as the humans that use it. If you're chatting with folks that can't understand the difference between a thread or not, that's a meat-bag issue and not anything an RFC can fix.
 bityard · 1790611641 · focus · HN ↗
 I have half-wondered many times whether it would be possible/practical to build a chat system on top of MQTT or similar. Chat seems like mostly a pub/sub problem from where I sit.
 ezst · 1790641340 · focus · HN ↗
 Congrats, you just described XMPP
 5. oooyay · 1790610938 · focus · HN ↗
 IRC is good in that it is open, durable, and slow moving. All of those points are intentional features that make it a stable cockroach in a nuclear world.
 I briefly entertained building a modern chat experience on top of IRC when I came to this realization.
 thinkmassive · 1790614941 · focus · HN ↗
 Slack was originally a side project built by a game dev company as a set of scripts on top of IRC. <a href="https://en.wikipedia.org/wiki/Slack_(software)#History" rel="nofollow">https://en.wikipedia.org/wiki/Slack_(software)#History
 radlad · 1790617170 · focus · HN ↗
 IRCv3 aimed to do this, with mixed results.
 bilekas · 1790618974 · focus · HN ↗
 IRC really is good. It's reliable too, but it really fell behind the times and never pushed forward with additions to the spec and such. When the clients and libraries tapered off too it just felt like it froze.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.