Hi Fannys! On 12/16/23 04:06, Fannys wrote:

As I said in the @xsf room the problem with this XEP is that the author is convinced that this is the one answer to everything and assumes a *lot* of stuff to get there. And besides the title obviously that is obvious in a few other places.

To try to quickly summarize, we need a lot of info to connect to XMPP servers, and need to get it in very specific (secure) ways. I've thought about this a lot over the years, and (very much thanks to your and other's feedback) tried to explain the reason for every decision. I am absolutely not married to one solution, but alternatives need to accomplish the same goals. "I don't like this" isn't helpful without an alternative proposal that can actually be considered.

Specifically:

- It calls SRV records as legacy which is a pretty big departure from the status quo.

...

For the foreseeable future you will need to maintain legacy SRV records in addition to this file

Yes, because this document explicitly deprecates SRV records (while saying they need to be supported for the forseeable future).

- It effectively makes HTTP a hard requirement for all clients and servers on the network raising complexity significantly.

HTTPS already is a hard requirement, with POSH, with HTTP Upload which is currently the only way to share files in MUCs and with multiple clients / offline clients, and, for most servers, the way they get certificates from letsencrypt. HTTPS is also a well established, fully open protocol with many independent implementations exactly like XMPP, I see no reason to avoid it. XMPP relies on many other standards, just as good or bad (depending on your POV), like DNS, IP, TCP, TLS, XML etc etc.

- Recommends that everything runs through port 443 which is in itself questionable for this.

Because it's most likely to work through real-world firewalls in real-world networks, what's questionable about this?

- Also it introduces a hard requirement for a JSON parser in all clients and servers which is another point that raises complexity.

Again, a JSON parser is already a hard requirement due to POSH. I addressed further reasons I thought this was the best choice in the Rationale https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-hm-json , but, this is not an absolute hill for me to die on. If the consensus is that XML is better here, I'm not opposed, but then it should be the XMPP-subset of XML so that we can actually use the same parser, and don't introduce the real security risk of requiring an XML parser that can parse not-XMPP-XML (just one real world example of this vulnerability in the wild is https://prosody.im/security/advisory_20220113/ ). Please note this would introduce the following (imho, downsides): 1. we could not use host-meta.xml as that requires a not-XMPP-subset-XML parser supporting comments etc etc 2. that means an extra https request when trying to fetch host-meta-2 along with legacy methods 3. so it'd require a new document definition, for a quick reference, it would look very similar to HACX https://xmpp.org/extensions/inbox/hacx.html#example-1

And I think the discussion about these items individually should have happened before. Especially since from the discussion in @xsf it seems that some of the alternatives like DNS were rejected on subjective opinions of the author.

I actually discussed this in xsf@ 21 months!!!! (damn I'm slow...) before submitting this ProtoXEP https://logs.xmpp.org/xsf/2022-03-17#2022-03-17-ead56d61d395a6b9 I hopefully explained my rationale re: DNS well https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-dns but please if you disagree and/or have alternatives do share.

My opinion is that HTTP and JSON shouldn't be requirements and i don't plan to use this XEP anywhere even if it gets voted in. We already have problems with ports and everything assuming HTTP and I don't want the problem to be worse. Plus I don't want the complexity at all.

So to summarize my current thoughts: * I think HTTPS is likely to be a hard requirement for this, at least I can't think of an alternative that can accomplish the same goals * JSON is *not* a hard requirement, and could be replaced, but has the downsides I layed out above and in the rationale

Fannys

I very much appreciate the detailed feedback, thank you!