jdev - 2025-09-05

so you lose pinned keys and secure delegation, roll your own TXT record parser, make many more requests that are slower, and gain... what ?

you're not gonna connect to the same XMPP server 5 different times

huh

and yes, rolling your own TXT record parser is far better than the overhead of HTTPS+JSON

a person would make ONE TXT record request, for one connection (in any protocol) they make to a XMPP server

and will also cache the keys too

well, their DNS resolver caches it, but still

you still must make the DNS request over an encrypted connection you realize ?

so you are already doing HTTPS or an identical-cost equivalent

but without the benefit of secure delegation or pinned keys

so your last argument seems to rely on parsing DNS records being easier or cheaper than parsing json... and lol god no

I wrote a DNS parser once: https://github.com/moparisthebest/jDnsProxy/blob/master/jDnsProxy/src/main/java/com/moparisthebest/dns/dto/Packet.java I'm still trying to recover

meet in the middle what if JSON over TXT records

combine that with the practical limit of TXT records being ~400 characters etc and they are a total non-starter to carry the needed info

moparisthebest: monero designed openalias to tie monero addresses to domains, and you'll be surprised that they didn't store a JSON file in a HTTPS server

they used TXT records in DNS

also btw, good thing about storing it in DNS, is that it isn't dependent on the HTTPS server existing

what if the server shuts down or is behind some sort of wall?

good luck trying to get your key info ✏

in fact you are making yet another point of failure in this system, since an attacker can DDoS the server that is hosting your host-meta.json file

and servers/clients will immediately downgrade to CA-enforced non-ECH TLS connections ✏

DNS records propagate to other DNS services, it is near impossible to try to DDoS DNS records to impede ECH connections

huh ? it has a TTL and an attacker can also just DDoS the XMPP server lol

but you are getting rid of this one benefit in favor of some centralized HTTPS server

it has nothing to do with ECH, ECH is just one of a dozen things you need to connect to an XMPP server, none of which will fit in DNS

> huh ? it has a TTL and an attacker can also just DDoS the XMPP server lol state actors would greatly benefit from DDoSing your host-meta.json file instead

centralized https server ? I have no idea where you are pulling this

where do you think they'll fetch the file from?

thin air?

certainly not a centralized https server lol

100% of XMPP servers already have an https server for http upload

i don't think you have the right definition of centralization for this :P

in DNS, records propagate across other servers

one of us doesn't lol

in your design, the ECH record is stored in one server

which is the XMPP server's HTTPS server

that is centralization

lol there are so many things wrong with what you said I don't even know where to start

begin :P

DNS records do not "propagate across other servers" ... you have usually 1 or 2 DNS servers where all your records live... "state actors" can trivially ddos those and now no one can resolve your domain

the only way i'll not call it centralization, is if other XMPP servers choose to share ECH keys of your XMPP server

moparisthebest: but there is more collateral damage to DDoSing a DNS server than DDoSing a HTTPS server

since it'll include records for thousands of domains within the same registrar ✏

you can equally have 1 or 2 (or unlimited) HTTPS servers... it doesn't really matter because if a state actor wants to stop you from connecting to your XMPP server they'll just ddos that no ?

what ?

i'm not saying they want to stop you from connecting to your xMPP server

I run my own DNS server

i'm saying to prevent ECH connections

oh! you think blocking getting the ECH key means connections will be made without ECH in the clear ???? that's... not how it works

read the ECH RFC

you do not understand what i mean

they can easily identify connections to a specific server if they prevent people from accessing the ECH keys :P

not see what's inside the traffic

but see what SNI is used

and the TLS fingerprint of the client

say if clients implement this XEP, what will they do if they literally cannot access the JSON file

if it's either behind a wall, or the HTTPS server is under maintenance

will they just stop connecting?

will new C2S/S2S connections completely halt until you bring your HTTPS server back up?

anyway i disagree with this experimental XEP, maybe we should stop discussing it

> but see what SNI is used this is your misunderstanding... an ECH-capable client will never send plaintext SNI ↺

regardless of whether it can get ECH keys or not, or even if they exist or not

> anyway i disagree with this experimental XEP, maybe we should stop discussing it that's perfectly fine, you or anyone else is free to do better ↺

if the connection methods can't be reached the client will used a cached copy or fallbacks, same as anything else, nothing special because https

Good day. I have asked this question over the mailing-list and I did not receive an answer as of yet, so I ask here also. I am interested to know of a valid URI for XEP-0248: PubSub Collection Nodes. ``` xmpp:comments.hostname?;node=node_collection/node_leaf;item=item_id ``` Would this be a valid URI?

I would also appreciate your comments concerning to navigational directives, which would be helpful for Libervia and Movim, as it is for Rivista. https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/VXGZYDMD7OZSWDX6WGUMF5VKTTSQ7YQ6/ *Navigation instructions for Atom Over XMPP (XEP-0277 and XEP-0472)* ✏