jdev - 2024-08-11

singpolyma: there's neither a success nor error response to bidi

You could definitely just... Not use one of them, but that's the only option I see here unless I'm missing something which is highly possible

so. hm. When a server sends me stanzas before XEP-0198 <resumed/>, those stanzas aren't being counted... and they are potentially addressed to a different resource than the resource I'm going to have after resume. ✏

that is somewhat weird.

oh but I wouldn't *bind* on stream I intend to resume, right?

how can you have a resource before you resumed?

bind and resume ought to be mutually exclusive

indeed

sensible, my fault then. ✏

This has the fun side effect that if you use bind2 you *must* inline sm into it in order to use sm at all

That seems reasonable, no?

Yeah it's fine, just unexpected. Definitely bit me when implementing

so how does that work with s2s-SM?

there's no bind you'd do before resuming, is there?

there's no bind in s2s no

as the RFC (core) intended! <stream:features/> without mandatory features indicates negotiation is completed

c2s is the weird one with the super weird <iq> before it's legal to send <iq>

Zash, but you can't make SM mandatory because you don't know whether the other side is willing/able to resume or enable it in the first place, can you? ✏

jonas’, SM already has a way to negotiate resumability, presumably included in the BIND2 binding?

is bind2 relevant for s2s?

I don't think so

can you do sm(2) without bind2?

sm without bind2 surely. I don't know about an sm2?

Hm, can't think of what might be relevant. s2s doesn't do as many things on startup anyway, so the sasl2/bind2 things aren't as relevant

> You are a server that supports bidi ( https://xmpp.org/extensions/xep-0288.html ), you get 2 incoming s2s connections from example.org (maybe multiple nodes in a cluster... Doesn't matter why), they both enable bidi... > > Now you have 2 outgoing streams for messages to example.org... which do you send messages out? Or duplicate messages to both 😈 ? Does anything specify this? cc dwd No, you have two streams which will accept outgoing messages; which (if any) you use is up to you. Simpler example: You open an outbound stream, and get an inbound stream. Both are bidi-enabled. Either could be used for outgoing messages, you can receive inbound message on either. Now, using both has some *really* interesting problems to solve, because you're bound to ensure ordering is maintained, so you'll need to send messages from a particular stream outbound on the same stream. But it's theoretically possible to do safely.

> am I seeing this right that XEP-0114 does not use RFC 6120 XML streams? The examples given have the initiating entity not send a version tag; this would mean that not sending features is correct. I think some servers will send features over XEP-0114 if they receive a version tag. Metre certainly does (unless you tell it not to), and allows components to do starttls, for example.

But the node.js component thingy sends a version tag *but also* chokes if it sees features, hence why I had to make that configurable in Metre.

The same node.js component thingy that chocked if you send it a disco#info query? (I think it got fixed tho) ✏

Or was it xep-199 ping?

Probably. I only came across it because of the matrix-bifrost bridge, which seems pretty flakey to me.

FWIW re bidi, I think Prosody will in most cases pick the oldest s2sout for outgoing stanzas, be that a regular outgoing s2s or a bidi-enabled incoming. It's still kinda new and doesn't have any more fancy handling than that yet.