Stop Telling Us XMPP Should Use JSON
64 points by adamcstephens
64 points by adamcstephens
This is consistent with my expressed opinions:
XML got a really bad reputation. The reason it got a really bad reputation is because people were using it for things that it should never have been used for. XML stands for Extensible Markup Language. And if you're using it as an extensible markup language, it's actually really great.
Let's say you're working on something and you're like: "I'm making a new kind of book, and I need to annotate all of the verses in the Bible, and have the chapter headings and stuff."
It's great for that.
It's really good for when you have a document, and some things are italicized, and some things are in a foreign language, and subtitles, and all that stuff. It's really good for that.
It's not good if it's like: "I need to configure this server and the server needs to know if this value is true or false."
No, that's bad. Don't do that. That's not a good use for XML. But XML does have some uses for which it's appropriate.
XML is the best format if you need to add inline markup to text while preserving existing formatting (like whitespace and newlines). Not a great format for this, but all of the other popular formats are worse.
XML is pretty terrible at preserving white space. It's often indented using white space, and there's an expectation that this indentation doesn't affect the content. If I was writing XML to be processed by some tool and I had to make sure to avoid any white space I didn't want to be treated as part of the text I'd be pretty annoyed.
E.g I would want to write like this:
<document>
<paragraph>
Hello world, this is an example paragraph.
Lorem ipsum dolor sit amet et cetera.
</paragraph>
</document>
I would not want to have to write like this:
<document>
<paragraph>Hello world, this is an example paragraph.
Lorem ipsum dolor sit amet et cetera.</paragraph>
</document>
As a result, a parser would have to collapse whitespace in some way.
My main use case for XML is to keep a progression of tutorial code samples in sync, so I can change a variable name in sample1 and have it propagate all the way to sample7. For example this
IsUnique(s) == <s on="1">Cardinality(seen) = Len(s)</s><s on="2-">
\A i, j \in 1..Len(s):
<s on="3">i # j => </s>seq[i] # seq[j]</s>
Generates 3 versions of IsUnique. I need complete control over the formatting of the output, so XML content preserving whitespace is a critical feature for me.
The solution is it should be <paragraph><text content=" This has significant leading whitespace."/></paragraph>. :-)
I thought it was generally put in a <![CDATA[]]> section.
(It's been a solid 15 years since I've had to go into the weeds on XML, and I don't miss it, but I think my memory is at least reflective of our practice back then, and therefore reflective of the behavior of the parsers we used, if not correct according to the standard.)
XML also got a bad reputation for 25 years of security issues. They continue to this day. The syntax is complex and the spec, which is really difficult to read, includes features that require a deserialier to cross network authorization boundaries. IMHO it is impossible to use untrusted XML with confidence. I'm somewhat optimistic that a language like rust could avoid the many memory safety issues that libxml2 has had, but we'd still be left with features that allow attackers to make requests to foreign domains.
features that allow attackers to make requests to foreign domains
The syntax of XMPP "stanzas" is not full-blown XML, it is a subset that is not even strictly valid XML. Making "requests to foreign domain" is not required to parse stanzas.
Still, throwing a conforming XML parser instead of an XMPP-specific stanza parser at stanzas would be an easy mistake to make.
An entire XMPP session is an XML document (actually, two XML documents, one for each direction). It starts with the all of the header nonsense and all of it lives within a <stream></stream> block. Each stanza is a self-contained block within this document. This allows you to use a standard XML SAX parser. The MSN Messenger protocol, in contrast, gave a complete XML document for each message.
That said, I think XMPP disallows some XML features (it's been over a decade since I read the spec carefully), including entities (which are a common source of vulnerabilities). The way XMPP uses namespaces is also weird, but I'm not sure if it's a restriction of what XML allows.
The way XMPP uses namespaces is also weird, but I'm not sure if it's a restriction of what XML allows.
What is the weirdness you a referring to. I believe XMPP use XML namespaces in a pretty standard way (minus the missing xmlns declaration on attributes, but strictly speaking, this is standards compliant).
Not sure what you mean here. By XML spec most attributes should not have xmlns. Some may, and this is allowed in xmpp, but it's not always common because attributes are inherently namespaced by the element they are on to begin with.
but it's not always common because attributes are inherently namespaced by the element they are on to begin with.
They are not "inherently namespaced by the element they are on". In <example xmlns="foo:bar" attr1="value"/>, attr1 is in the empty/null namespace. If this is an issue in practice is a different discussion, but at least for XMPP it does not seem to cause any practical issues.
No. This is a common misunderstanding. In your example attr1 is conceptually in an anonymous namespace that is derived from the element it is on. This is not the same as being in any namespace one can name with a prefix or xmlns and is more specific.
Sounds like wise engineering to me! Thanks for pointing this out. Looking at a few XMPP projects on GitHub just now, it looks like they tend to stay away from full-blown XML parsers too, which seems like the critical step for avoiding the security flaws.
XMPP uses XML in a weird manner: the long-lived stream in its entirety is one XML document, so XMPP implementations basically have to use an event-based SAX-style parser, not DOM-style.
XMPP uses XML in a weird manner: the long-lived stream in its entirety is one XML document, so XMPP implementations basically have to use an event-based SAX-style parser, not DOM-style.
Yet, this is not how many XMPP implementations parse and process the XMPP stream. Smack, for example, splits the top-level stream elements and handles them as single XML document. This is possible, because you don't need much context from the outermost <stream/>. And eventually, it allows the use of a DOM parser if you want.
You still need most of a sax style parser to do the splitting
I wrote such a XML splitter a while ago, not sure if I would specify it as "most of a sax style parser".
XML remains the best format for representing trees
Let me introduce you to S-expressions …
XML is an artifact of the 90s-era mentality that brought us enterprise Java. It’s a markup language pressed into service as a data encoding. The affordances which make sense for markup (e.g. ending tags and attributes) make negative sense when encoding data.
The right time to consider it was 25 years ago. But even then, you would have to invent a way to handle validation and type composition for your s-exps. I'm sure that can be done, but with XML you have the benefit that it is already a standard that provides these things, whereas now you're inventing a standard for streaming data as well as the protocol that's going to sit on top of it, and all the compatible implementations are going to have to rewrite that code too.
I can't argue against the bloat of ending tags. But I will say they've been concerned about compression since the get-go, and the overhead here is not that big when you consider that compression algorithms really like fixed strings, and these days a few extra bytes in the packet are not the killer they once were.
I can't argue against the bloat of ending tags
In the SGML days we had </> to close an open entity. But XML disallowed it, boo.
If one were particularly dedicated, one might be able to write an SGML application for S-expressions. SGML can consume almost anything structured, as long as you can craft the application definition. I've worked with applications where entities looked like >this< … >/this< and the parser was fine with that.
I've worked with applications where entities looked like >this< … >/this< and the parser was fine with that.
... Why the hell did they look like that?
It was quite an old SGML application. It pre-dated the web, so people didn't have a huge weight of documents to refer to. I seem to remember the inward-facing markers were supposed to "highlight" the tag name better. I dunno. I just had to work with it, I didn't have to like it.
For those still hating on end tags, SGML had Null End Tag. That was pretty short. Looked like poo, tho
I haven't looked into the history but I sorta get the impression that xml is verbose because the designers didn't expect everyone to always be reading and writing raw XML files. It feels like you're supposed to manipulate the data in a structured editor that uses XML as an internal format.
My sense at the time was that XML was explicitly about interchange, and that human-readable tags were thought to facilitate that as well as lead to a quality called being "self-describing." There was much discussion of structured editors, but the only one I was ever aware of was oXygen (IIRC) for DocBook and it was pretty expensive, so I assume it wasn't widely used.
Most of my own use of XML has entailed hand-writing it. The amount of work involved with building a good structured editor is pretty big, and XML's modularity and extensibility has generally made the task harder. That is, most of my own use of XML has been as a "document markup" system, although I think the semantic debate about what that means elsewhere in these comments is probably circular.
IMO XML is mostly derided for fashion reasons, because it grew up with Java (which is also mostly derided for fashion reasons) and because by-and-large modern systems are written with a kind of laissez faire approach to correctness; we'd rather have the "simplicity" of JSON, YAML, etc. formats and hand-write (or forget to hand-write) validation for them. There was an explosion of interesting ideas with XML that saw very poor adoption (XSLT, XLink, RelaxNG) or none at al (XProc). Java had poor metaprogramming for a long time (might still, I don't know) but built several technologies on top of XML to alleviate the problem, so people doing Java in that era developed a distaste for constantly writing XML configuration files. Overall, it's kind of a shame in my opinion.
The big benefit of XML (especially from the perspective of XMPP) is that one XML document can contain another XML document without the parser for the outer document having any knowledge of the structure of the inner one. Most interestingly, this can happen multiple levels deep and so you can have A contains B contains C, where the parser for A does know about C and handles it, but ignores B (or delegates parsing of B to something else).
In XMPP, you send rich text as XHTML. A client that doesn't know how to parse XHTML can simply use the plain-text equivalent. A client that knows about only some XHTML tags can render those and ignore the rest. This is not possible with HTML, because you have to know that some tags (e.g. <br> and <img>) are self-closing.
The really fun cases are things like embedding Atom in XMPP. Atom includes HTML for the summaries of the things in the feed. An XMPP client that knows about Atom can give you a nice feed renderer view. An XMPP client that doesn't know about Atom, but does know about a subset of XHTML can still render the body of the messages.
s-exprs don't have the attribute/child distinction of XML, which is a nice property of XML (and the restriction that attributes don't just hold trees is .. kinda nice and enforces good behavior around denormalizing data).
I used to think XML really had negative value but I do appreciate the restrictions it places now.
which is a nice property of XML
It’s really not as it creates confusion in the model. And if you want this behaviour for your sexpr application, you can just define it as taking a map as the second child.
I think attributes make a ton of sense for a data interchange format. They make a clean separation between "attributes of this node" and "child nodes". You see them in JSON-based tree encodings as well, where an object typically represents a node, a property called "children" contains the list of child nodes, and the other properties represent attributes of the node.
I've read the argument before that S-exprs are better than XML because XML has attributes, and I'm just not buying it. For most use cases of encoding trees, it makes sense to differentiate them.
They make a clean separation between "attributes of this node" and "child nodes"
I do not believe that separation makes sense. In what way is ‘the children of the node’ distinct from ‘the colour of the node’? Specifically in XML, why may attributes only be strings, rather than sets or lists?
It’s a distinction which does make some sense when marking up text: attributes are metadata about the text, while children are more elements containing text. But in the general case of data interchange I do not believe it makes sense. Notably, programming languages do not typically distinguish between attributes of an object and the contents of an object. In fact, an object often has multiple disjoint contents! For example, a Student may have all of parents, classes and personal possessions.
The XML infoset is not a bad fit for the case of human-authored textual documents. It’s bad for data interchange.
I agree that it would've been better with a data interchange format where you only have attributes, no children. Like JSON; if you want child nodes, have an attribute you call "children".
S-expressions do the opposite. It removes the concept of attributes and leaves us with only children. What does (text (color "blue") (color "red") "Hello World") mean? Is color meant to be an attribute (and you should therefore only have one)? Or is color an element that it makes sense to have multiple of?
XML is better. There, <text color="blue" color="red">Hello World</text> is clearly invalid because color is used as an attribute. However <text><color>blue</color><color>red</color>Hello World</text> obviously makes sense as a textelement with twocolor` elements among its children.
JSON probably approaches the best solution. {"type":"text", "color":"blue", "color":"red", content:"Hello World"} is clearly malformed just like the first XML example, because we have duplicate keys. And instead of having a confusing generic concept of "children" that applies to all objects, this text object can just have a string property called content which makes sense for it specifically. Or if the schema allowed child objects under a text object, we could have a property called children that's an array of objects.
Although parsers disagree what to do about your "clearly malformed" example. Most JSON that bother to specify say "last value wins", some parsers reject as invalid and you get a lot of fun if some oddball parser ends up letting the first value win.
That's not really the important part. As a human reading a schema or reading JSON messages, it's clear to me that when the schema talks about a property called "color", there can only be one of them. My code should output only one "color", my data model can exclude the possibility of having multiple "color"s. There are exceptions, but they are exceedingly rare and universally considered bad.
When I read an S-expression schema which says that a text element can have children called color, it's not immediately clear just from the structure that there can only be one. When I read S-expression messages containing (text (color "red")), it's not clear whether there can be only one. Structurally, it's not clear (to me, the human interacting with this system) whether color is an attribute of the text element (and can therefore only occur once) or if color is just a child element. I have to hope someone wrote it down in documentation, since the structure doesn't tell me.
CSTML's approach to all this is to have attributes that allow arbitrary JSON, but then to also have relationships between nodes to be named. Relationships between nodes can use a [] flag to make themeselves lists, url-params-style. It looks like this:
<Theme { attribute: { nested: 'value' } }>
primaryColor: <Color "blue" />
accentColors[]: <Color "red" />
accentColors[]: <Color "green" />
</>
Any thoughts?
What markup languages aren't encoding data?
Markup language are for encoding a specific kind of data (documents), not for arbitrary data.
Funnily enough, I think that the structure of many things we call "documents" are far more arbitrary than the kind of data I imagine you're thinking of, but I can only guess because it seems "arbitrary" is but a stand-in for "not a document" which itself doesn't really have clear boundaries. But the really interesting thing then is that XML actually seems just as well equipped to handle arbitrary structure as JSON or any other text serialization format! So when we say it is "for" a purpose, do we mean some nebulous aggregate of desires we must historically extract from the creators of the technology, or are we referring to the purpose in practice that a technogy has found in the hands of service? Is it the whole of the intentions of the creator, like a gospel, or is it parts of each practice and intentionality? Why?
Let me introduce you to S-expressions …
Hear, hear! Sexps still remain on top of the heap (pun intended) for this sort of textual expression, at least in my book.
It’s a markup language pressed into service as a data encoding.
Agreed, and the XML standards bodies seem to be pretty clear on their intended role for it as markup syntax. After all, I've always been impressed by the notion of mixed XML vocabularies in documents. Is this the wrong reading?
Sexps are cool but they don't have a great extensibility story. More similar to JSON in that regard.
The closed data model is not a weakness of JSON but its superpower. Extensibility (the X in XML and the E in edn) is a fatal flaw for a data interchange format.
Now to be clear, for other purposes such as markup or configuration, extensibility might be worth it.
Sure. XML is not a data interchange format and could never be used as one since it has only strings.
What's that supposed to mean? It's a bad data interchange format since it only has strings, but it's clearly used as a data interchange format. Ever heard of XML-RPC? SOAP? PLists?
Some of those protocols invented data interchange formats on top of XML, but the XML by itself doesn't give you that.
In that case, JSON isn't a data interchange format either. The only essential difference between them is that JSON happens to differentiate between numeric data, Boolean data and textual data while XML doesn't, but that seems like a weird line to draw. They're both formats which represent trees of objects with attribute key/value pairs.
That's not the only difference, but it is the main one! The thing that makes JSON so good for serialization and interchange is precisely that it can directly encode most data without any additional protocol on top.
Except you can't. Both sides need to agree on some schema, including conventions on e.g how to parse non-numeric/boolean data like timestamps and UUIDs, what the names of keys are, etc. The literal only difference is that the conventions on how to parse stuff includes "this field is expected to be parsed as a base-10 integer".
And maps and arrays and booleans. The difference is between JSON.parse(string) giving you data you work with directly and XML.parse(string) giving you a tree you now need to do operations on.
I like both technologies quite a bit, but they have very little overlap in terms of use cases.
Is "happens to match JavaScript's data model" your criterium for whether something is a data interchange format? I usually interact with JSON by using some schema-based parser (Serde in Rust or json.Unmarshal in Go), do there's already a translation from JSON's data model to the tree I operate on. Using XML for data interchange is really a very small conceptual leap.
It's hardly just "JavaScript data model" it matches pretty close to every major scripting language (python, ruby, perl, etc) and even serde's internal conceptual model is pretty close.
Data you can load out of JSON in 1-6 lines of code would usually take 10-60 lines for xml
Json.parse will...also yield a tree if your data is structured like a tree (most JSON documents are)
Which is nice, right up until you hit the line of that 'most'. For example, try putting a 64-bit inode number in JSON. You have two choices:
But surely the idea was to use schema definitions and XSLT to, for example, denote the string "<number><type=floating-point>3.1415926535897932</number>" and thereby get something other than pure strings back when read?
When discussing XML, people tend to forget that you were supposed to have schemas and validate your inputs and outputs against them. Of course no-one did that, because the tools were proprietary, expensive and hard to use, and if you were BigCo sending data to some contractor the problem of handing the data was on them, not you.
Huh, it's been a long time, but I was definitely using free nice XSD tools in 2009-2011, and I think I had something too in 2002-2005 (I was using a proprietary Java framework at the time, so perhaps it came bundled with some proprietary XML libraries?).
XML has always been complex, but it's fine. It's a bit weird to use a text markup language for cases where you don't have text, but XMPP likely allows using markup on text messages, so... I think XMPP has many problems, but XML doesn't rank as important to me amongst them. And there aren't so many alternatives to it- if talking strictly about IM, the only thing that has impressed me lately is DeltaChat, and it's a completely different thing.
OK I was overdramatizing the cost and availability of tools. But my other point still stands - most generators of XML-based data did not have the discipline to actually validate their output. I worked at a consultancy at the time, and what were we gonna do if some ad-hoc XML soup came down the pipe from a multinational? Complain about it? Heck no, suck it up and try to Postel that crap.
XML's fatal flaw was that it's something that should be opaque, like a binary format, but it's actually "human-readable" like HTML was. This lead peope to do shortcuts like just put in random entity names instead of going through the process of writing a DTD. Probably the only dude who knew how to write DTDs had buggered off to another architecture astronaut job anyway.
I don't know, I was mostly the small guy sending XML to the multinational, and they would reject my XML if it didn't validate, so I've been mostly through the opposite experience :)
I agree that not using proper XML tools to read/write is a sin. But I don't think XML is special in that regard, really. At least between the popular formats today, I think most of them are text. Heck, very recently I implemented a shell script that generates JSON, and I used string interpolation- but it's in a very constrained part of a system so there's virtually no risk.
We don't know why XML took off, but ASN.1 was available at the time and somewhat popular, and it was binary... and I reckon most people don't even know it exists- so perhaps XML being text helped it skyrocket. (I would guess it just feel familiar to everyone because everyone at the time was familiar with HTML.)
The main problem of XML is that it has a lot of complexity that you eat even if you don't need the features that complexity enables. So it basically it doesn't scale down. But most of the problem stems from people misunderstanding XML- which might be an XML problem of being too complex. But for many uses it's just fine.
I guess there was a wide spread of companies. I can imagine some that were really up to date on their WS* specs, and others who turned off validation on outgoing because it crashed on unescaped ampersands or something. Like so many other utopian schemes, XML relied on everyone being perfect all the time, which basically never happens.
Edit my first real project as a baby consultant was baby-sitting a Java program that ingested an XML dump of yellow pages-type listings into an online system. It was designed by another consulting firm (this was in the late 1990s) and it took in excess of 3 days to import ~600MB of data. There was no validation, nor error handling, so if it crashed, it was a week until the data was updated.
I learned a lot of Perl to monitor the process, restart if needed, remove illegal values (ampersands!) and so on. Fun times were had until a reshuffle at the customer wiped out my script directory. Backups? What backups?
Anyway, XMPP uses XML because XMPP is so old it was new and hot when XML was new and hot. If someone would try to invent it today, they'd no doubt use JSON.
Something I've ran into with XML based services is even if you have great validation set up on your own side you almost don't want to overly validate anything just to ensure you don't break services on the other side in B2B and can also change your output to compensate for their issues
Can you explain that a bit? I'd have thought the opposite - but I'm assuming you're manipulating them using a Lisp.
Namespaces. XHTML and ATOM, both XML formats, have an <author> tag, but with different semantics. XML has a way to allow the use of both in a single document.
Common Lisp, at least, allows for this using packages:
CL-USER> (defpackage :xhtml
(:use :cl)
(:export :author))
#<PACKAGE "XHTML">
CL-USER> (defpackage :atom
(:use :cl)
(:export :author))
#<PACKAGE "ATOM">
CL-USER> '(document (xhtml:author "Alice") (atom:author "Bob"))
(DOCUMENT (XHTML:AUTHOR "Alice") (ATOM:AUTHOR "Bob"))
The same can be said about JSON or most other serialization formats (see JSON.Net's XML ↔ JSON converter). With the exception of the behavior of your parser+serializer and some rules surrounding how values themselves are handled through that pipeline, being picky about serialization formats only really tend to matter if there's some unfulfilled resource constraint (which there clearly isn't given the performance of XML within XMPP)
It sounds like XMPP 2.0 or whatever should be XMPP plus a bunch of non-optional XEP's so you can advertise a base-case of functionality around clients and servers. Of course everyone will fight over what that list of non-optional should be.
I mean I'm sure there is some low-hanging fruit to fix as well, but changing the serialization format from XML -> JSON seems like a waste of time and energy.
The big thing I'd really like is better security required. At least make transport security required (maybe TLS 1.3 as minimum even) and make sure it's in the non-optional list of XEP's. There is basically no reason to at-minimum have decent transport security.
OMEMO would be great too, but my understanding is in practice (deployed code out in the wild) it's arguably not very secure, because of bad defaults, assumptions, etc.
It sounds like XMPP 2.0 or whatever should be XMPP plus a bunch of non-optional XEP's so you can advertise a base-case of functionality around clients and servers. Of course everyone will fight over what that list of non-optional should be.
XMPP already has this (old name "compliance levels"). But, yes, XMPP being XMPP, they went from a simple list of XEPs (2008), to a list of lists of XEPs (2010), to a matrix of XEPs (2012-2023).
From https://xmpp.org/extensions/xep-0479.html:
This document defines XMPP application Categories based on typical use cases (Core, Web, IM, Mobile) and Levels (Core, Advanced) based on functionality in the respective category. For each combination of those, the required XEPs are referenced.
Ouch. I seem to remember the "compliance levels" but not to the extent of XEP lists of lists mess.
I checked and it looks like TLS is on the list of lists, but it's not required to be enabled on connections, and it doesn't seem to mandate any particular version.
it's not required to be enabled on connections
There are valid use cases for unencrypted connections, for instance server components typically run on the same host as the server.
In practice though, unencrypted connections to clients or other servers are disabled on most (all?) of the federated "Jabber network" today. Maybe you can set up your server without TLS, but chances are you won't be able to talk to the outside world.
TLS has been required for many many years.
Required in what sense? Required by whom?
Required in the sense that if you don't use TLS your XMPP server won't be able to talk to other servers running today, because they are configured to not allow plain text connections.
It's not required by any person though. I am not sure how that would be compatible with the idea of a federated network based on an open protocol. Democracy is hard, sure. Democratic processes are slower than authoritative ones. Sometimes consensuses emerge though, like mandating TLS via compliance suites.
Awesome! @nicoco gave more details in their comment too.
I wonder what versions of TLS the federated network mostly uses. If I had some time, I'd go do a test, but I just don't right now, maybe this weekend, but I kind of doubt it. A family member had a stroke recently and I'm generally the primary caregiver.
It would be interesting to see if TLS 1.3 is mostly used or if it's all TLS 1.0 or something. I'm a little worried it will be all over the map, and not TLS 1.2 or TLS 1.3 which are both generally secure no matter what you do. Lots of older TLS has all sorts of problems.
All that said, I know you do a lot in the XMPP space, and I just want to thank you for your hard work. I'm very happy jmp.chat exists.
There is a big push towards TLS 1.3 but definitely quite some 1.2 still out there at the moment.
OMEMO is okay, but PFS(perfect forward secrecy) is already provided by TLS and with the amount of XMPP server operators the chance of your key exposing your messages is basically nil. It's better to remove the needless overhead of tracking forward key states and just use PGP to protect yourself. Sure PFS is great for short lived stuff like initializing a video chat, but for the long term of loading and unloading messages it's better to leave that to the gigantic chat networks with billions of users under a single company/administration.
I think one of us has some confusion around OMEMO, TLS and PFS?
They operate at different levels of the stack. For total privacy and security of messages, you want both.
TLS is just about the transport across the network, it does nothing to protect the message's secrecy end to end. OMEMO does E2E.
PFS is fine, it even works in newer versions of TLS, but again that's only for the transport to/from servers, it does nothing for the messages themselves.
PGP is basically a disaster, I wouldn't recommend PGP for anything if you can avoid it.
PGP doesn't ratchet keys so it's less likely to fail in federated networks. Also it has the ability to use different key types so you can easily adopt for postquantum cryptography without changing much client code. I agree transport should have a threat model that includes pfs because traffic is observable to 3rd parties outside of xmpp, but within xmpp itself it doesn't make much sense. Signal itself even has a hard time encrypting messages to more than one device and that's why your phone is always the master client. You either have usability with you messages encrypted statelessly or you don't. You also already rely on PGP for the basis of all your Linux packages on a CDN so I wouldn't really call or much of a disaster if anything.
So you are saying use PGP instead of OMEMO? Do any clients support this? That sounds like a giant pain if you have to do it by hand all the time.
Around my comment on PGP's disaster status: Latacora has said it better than I ever could: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
The only update since than that I know of is we have Sequoia PGP now so at least the code isn't as janky anymore.
There's some support around but I don't think anyone supports proper modern PGP yet. I'm using it for backup file encryption and some other things but not on the wire at the moment.
It's worth remembering why XML was such a good fit back in the early days of XMPP: Almost every format that you wanted to use XMPP to transport was XML:
The future of the world was XML and a message bus for XML was a really useful thing.
Now, the world isn't XML. Mostly, XMPP message bodies are HTML that are shoehorned into XHTML, or they're attachments. And mostly they're actually blobs encrypted with OMEMO. Oh, or they're not actually transported over XMPP except as fallback, they use Jingle or similar to establish a separate channel and use XMPP purely as the control plane.
All of which means that most of the advantages of XML have gone away, but most of the benefits of moving away from XML have gone away for the same reasons.
Of all the things you could criticise XMPP for, this is probably one of the silliest. It's not a design with a privacy model that makes sense for a post-Snowden chat mechanism. It's a design that's okay as a generic message bus between trusted entities with weak privacy requirements, but generally worse than MQTT for this kind of thing.
Not sure about the tag on this one.
I've suggested switching out programming for api, but that's not really much better.
How is there not a tag for protocols and protocol design? Also, to a lesser degree, tags for non-programming structured languages, like markup languages (even if it's a single markup tag instead of seperate tags for each major one) and serialization/wire formats (definitely a single tag here), etc.?
Yet we have a tag for merkle trees? And IPv6 in particular when we already have a networking tag (though the IPv6 tag is being retired it seems; probably could simply turn that into a more general protocols tag instead)?
programming would be fine. It's the catch all tag for anything that definitely is on topic (like this story is) but isn't covered by a more specific tag.
Tags partially exist to allow hiding posts people do not care about, so e.g. merkle-trees exists as the blockchain containment zone for people who don't want to see them.
It's a weird tag though. I want to filter out blockchain stuff (or at least would've wanted to, back when it was the hype instead of AI), but I don't want to filter out all the other uses of merkle trees.. I have nothing against posts about Git or various merkle tree based databases like DynamoDB
Nah, 'merkle-trees' was introduced to strictly limit the scope of cryptocurrency related submissions. Narrowly, discussing how a blockchain works internally is on topic, but discussing its usage "in the real world" is not.
That's true. And it is under the platforms category, not the compsci category.
It was just the first example I saw. I did think it'd be for the people who aren't interested in blockchain stuff, but then I saw the description was “and related similar data structures. not business/scam news”, so I thought it was purely a data structures-based tag. I didn't notice it was under the platforms category.
I don't know if it matters at all, which is the best reason for sticking with XML. You can do all this stuff in either format. Who cares, you're moving structured data from X to Y with a schema. JSON Schema exists. The article should defend extensibility and whatever "embed at any level" means because from here it looks like either works, just one's already implemented.