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. 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.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.