jdev - 2023-11-02

> XEP-0333 has no pull mechanism. Markers are sent directly. If 500 people do that in a public muc, we have a lot of noise

Is there any plan for an XEP which would introduce a pull mechanism to scale better for public / large MUCs?

Don't do it in big MUC? Or do it in PM like the Tigase clients?

We don't do pull here :P

Server side periodic aggregation might be something to explore ✏

> We don't do pull here :P Let me naively ask, why not? :)

Markers don't have to be sent for every message either, could send every $period to reduce noise

meson: XMPP is a real time instant messaging protocol, pull/poll is the opposite of how things normally work. 500 clients polling for updates isn't ideal either

Yeah, you don't really want poll, but maybe batching

You also probably don't care about if 500 people read something, so filtering is also something that could be done

Yeah, a server could restrict broadcast only to those of people who have recently interacted, or something

So if you have thousands of lurkers, you don't need to see the read status of them all

Do we think in general "one big stanza" has any performance benefits over "many small stanzas all at once" when it comes to questions of batching? Probably a small xml parser improvement, maybe easier to batch other updates on the client, but I'm not sure that's my gut not knowledge

I prefer many small stanzas generally when working on protocols

Large stanzas raise too many questions about maximum size, and can't be interleaved with other stanzas

I suppose we can say if there is beneficial batching the client can do it, modulo xml parsing overhead which should be small. So then 500 "I read this" stanzas vs one "these 500 people read this stanza" maybe it's no big deal either way

Isn't it a good idea to batch UI updates too, so that fits

yes, too many UI updates is definitely the worst culprit in many cases, which isn't strictly protocol related itself. the other possible place for batching is storage updates, though if you wait before persisting you may run the risk of losing something if you crash while you wait

just use stateless UIs!!k

no, imemdiate mode it's called

for normal tcp connection this probably does not matter for the client

but what about websocket? every stanza is its own message. I dont know the protocol details, but may be a bigger overhead there

> but what about websocket? every stanza is its own message. I dont know the protocol details, but may be a bigger overhead there Slightly bigger. Eventually hopefully we can switch to WebTransport ↺

singpolyma has been tempting me with another transport for XMPP, knowing I'm a sucker for XMPP over X

Especailly since this one is hopefully just a tweak to one you already have that makes it more generic :)

No framing is indeed a plus

>> but what about websocket? every stanza is its own message. I dont know the protocol details, but may be a bigger overhead there > Slightly bigger. Eventually hopefully we can switch to WebTransport Like for cheogram you mean? Why 🤔 ↺

Like whats the selling of webtransport i mean

Browsers can do it, terrible firewalls and vps hosts that can only do https can do it

MSavoritias (fae,ve): it's basically raw QUIC sockets in the browser

with a tiny bit of ceremony to make it smell more like http/3

closest thing to raw sockets the browser has ever seen

and with the small extra ceremony you can do it from even a non-browser context without needing a whole http client library, etc, so it's a real contender for a first class connection IMO. Especially if we spec it to not be allowed with any "path component" set so it works just like quic to a port, like our existing TCP to a port stuff does. Would be pretty great

You mean to be allowed with any path component?

That sounds like a very cool thing to support 😃 /me adds it to their todo list

Since it would communicate with clearnet especially.

This is going to push us to not-dns for discovery though, fits right in with my host-meta 2 I need to write though :)

MSavoritias (fae,ve): it's encrypted UDP on quic, not sure what you mean though

I meant that i would be interested to implement a clear net connection next to gnunet maybe

For testing and other purposes

So webtransport sounds interesting. Especially since it supports browsers and can get through firewalls

moparisthebest: I would very much like to discover it over DNS like usual of course, you know me :)

the only supported params are host, port, and path and I'd very much like to not support path

I think we have to have path though, and that rules out DNS

singpolyma, latest trunk has DANE for s2sin now btw :)

Besides, why have a method for browsers and then a separate discovery method

Zash: I saw! Thanks so much for all your work on that

moparisthebest: /me whispers DNS-over-HTTPS

SVCB in DNS over HTTPS?

and we don't have to have path. it's optional

some might find it useful

path?

Plus this gets us basically dane for tlds that'll never do DNSSEC

if they don't do dnssec how are you doing discovery?

I'd like to figure out how to pin DNSKEY in my resolver so I can work with specific domains from bad tlds, but I haven't got it to work yet

singpolyma, pin DS records?

I very much want a thing that monitors DS records against my DNSKEY ( or CDS )

DNSSEC Transparency

Zash: honestly I need to read all the dnssec specs again before I'm 100% sure what I want. For example yax.im publishes dnssec signed zone so in theory I should be able to add a trust anchor to verify it even though there is not chain to root. But I haven't figured it out yet

Delegation Signer (DS) are hashes of your DNSKEY published in the parent zone (along with glue etc), so pinning on that makes some sense

or at least monitoring

looks like apex has both DS and DNSKEY in many cases?

hm, not sure, but DS and NS (and optional A, AAAA glue) normally go in the parent zone, ( `dig zash.se DS @a.ns.se` ) while DNSKEY goes in your zone ( `dig zash.se DNSKEY @ns1.zash.se` ), confusingly named the same thing but in different places.

Parent zone means at the TLD?

yes

(but TLD and root zone have the same thing)

right. so that won't be the case for an unsupporting tld. which explains why for yax.im I see DNSKEY but not DS

Before the root was signed, there was this alternate side-whatsitcalled trust chain thing...

yes. but I should be able to pin right at the level of a single domain without an alt root. I think?

I don't see why not, might depend on your software tho

Ah, here we go https://op-co.de/blog/posts/yax_im_dnssec/

maybe I need to generate the DS from the published DNSKEY and put that in my trust anchors

Should be entirely possible, yes.

I tried doing it with the key directly, which something implied to me would work, but I'll try to figure out generating the DS instead and see

Hm, libunbound seems unhappy with that

at least as a trust anchor

With the generated DS?

No I put a DNSKEY as trust anchor

Huh, it worked, but I think I found a bug when entering multiple trust anchors :/

~$ unbound-host -y 'yax.im. 86400 IN DNSKEY 257 3 8 AwEAAcB7Fx3T/byAWrKVzmivuH1bpP5Jx4uUaS9SRWcFltlBJaBeTUiHl+L4PQH68eDx5vrHiBI0orYfcVyvDBaXrUoReJvQgnn3OKdr/u2Qpd02nLqxjT8h/gtCX+J2nRjE9zXrJsWB/+RZmxZrp19skwZQnMXxqQdk4VMMz7PQSdLuRfYzdlktH58IoSzQNqFpA+l4WsLd10kWv+H5E2wAjXg8iXSz/qWrme6uxnIp9NT0/pHOQhsA48GsGQu9kI+BcOrL6w4CDVVBRapJw8xZtSlV09M879pZr7s90Knv6quFBMMghTWYtzfVmDavDlYqdskyYhQOhiyJ0NcnQPt6HjM=' yax.im -v yax.im has address 151.252.51.53 (secure) yax.im has no IPv6 address (insecure) yax.im mail is handled by 5 bender.boerde.de. (secure)

@Zash are you running FreeBSD or just Unboound on Linux?

unbound on Linux

Yeah when I tried DNSKEY as trust anchor I just couldn't resolve it anymore