XSF Discussion - 2022-03-30

https://github.com/moparisthebest/xmpp-proxy/blob/master/contrib/host-meta/xep-0156-proposed-minimal.json here is the tweaked proposal that is now implemented in xmpp-proxy and running on xmpp:xmpp-proxy@code.moparisthe.best?join changes from last time: per MattJ 's suggestion, alpn was kinda strange, https-svc uses it to determine protocol, like h3 means quic, h2 means means h2-over-tls-over-tcp etc, we already have the "protocol" info at the rel= level, and I planned on quic alpn matching direct-tls alpn (xmpp-client and xmpp-server), so this has been removed for non-https protocols (so it stays for websocket) let me know if anyone has suggestions, I'll start writing 3 XEPs soon, this discovery (probably try to update xep-0156), xmpp-over-quic, xmpp-s2s-over-websocket

Neustradamus: there is no "import of previous newsletter issues" at the mailing list. Previous issues can be read at xmpp.org

moparisthebest, instead of a XEP, I think a RFC might be more suitable, given what you extend is a RFC in the first place.

You can start from RFC6415, modify it, and publish a new one obsoleting the prior version?

> wurstsalat escribió: > Neustradamus: there is no "import of previous newsletter issues" at the mailing list. Previous issues can be read at xmpp.org And that is what I have referenced in the invitation

Link Mauve, lots of things that should be RFCs start out as XEPs, some stay XEPs forever, might as well start out with the process I know :)

moparisthebest: so something along the lines of Metre but for c2s too?

ish? xmpp-proxy basically lets your client or server simply connect to a TCP port and start sending stanzas, without worrying about srv/tls/posh/dane/etc

and all the directions, outgoing c2s+s2s, incoming s2s, with sasl external

iirc Metre did that for S2S

anyhow ok

metre looks like it has some routing too, xmpp-proxy will never have that, it doesn't even parse XML, also it supports quic+websockets in addition to the normal things

Maranda - if you're describing the X2X feature (zero-handshake S2S), it's https://xmpp.org/extensions/xep-0361.html and M-Link supported it for donkey's years, but that's not what xmpp-proxy is doing, I believe.

no, but QUIC or TLS with 0-rtt handshake should be *almost* as quick as that, and usable on the federated network

Kev: i more meant the: S2S <-> S2S proxying

Not any XEP in particular

361's meant for the sorts of connectivity that make mobiles look stable, and it does pretty well at that, but it's obviously no use at all for the public network :)

Maranda: Right. Steve calls that "XMPP Trunking", which seems a fair name for it.