XSF Discussion - 2018-07-21

hm, Link Mauve, I’m not sure I’m comfortable merging your change to xep-0050 without going through council

It seemed very much editorial to me (https://github.com/xsf/xeps/pull/677/commits/b16e5025be007d9e4554beb127917f58246f980e for reference), but I can drop it from this PR and do another one for council.

this removes one of two statements which contradict each other. technically, you could also have removed the requirement to ignore this attribute (and possibly replaced it with a requirement for it to b e "execute" or whatever), so I’m not sure.

It didn’t make much sense to make a previously-ignored attribute required, only because it was marked as optional somewhere else.

The other one is a MUST ignore, this one is “optionally maybe add this”. ✏

is there anything planned in caps2, that we have like a server caps hash?

depending on the server, i have to send out min. 5 disco infos after a disco items

lovetox, it’s already done, see §5.2.

on each start of the client

Uh?

yes thats exactly what i would need

yes Link Mauve need to discover httpupload, mucs, proxys, transports

lovetox, if you mean that the server would keep a tree of all of its component’s ecaps2, the issue is that they could change at any moment, or even depend on who is asking.

what the items of the domain could change depending on who is aksing?

i mean yeah it could, but why should it

a client could also announce different stuff depending on who is asking

was disco-sub a xep or how was it?

we simply dont do ti

lovetox, I’ve seen it done.

yeah then this server should not use caps

simple as that

Why that?

It’s still a valuable optimisation.

i guess if he keeps a hash of its components *per* user

Another issue is what to do when a component gets disconnected and reconnected?

restart?

nothing

for longer time, then send out a updated hash

Bunneh: xep caps2

Zash: Sorry, I couldn't find a match

https://xmpp.org/extensions/xep-0390.html#usecases-stream-feature

Zash

Bunneh, xep ecaps2 ✏

Link Mauve: Entity Capabilities 2.0 (Standards Track, Experimental, 2017-06-14) See: https://xmpp.org/extensions/xep-0390.html

tanx

What sucks about stanza counters in 0198 is that you can't say when the desync happened. I'm at 35k stanzas on my session, with ~20 stanzas too few counted by the client. ✏

Ge0rG, don’t you get logging whenever that happens, on both sides?

Link Mauve: no, i'm just receiving the last ~20 stanzas duplicated on resume

Oh wow.

Ge0rG, you know you are desync'd but still resume the desync'd stream?

Counting is surprisingly hard

I really wouldn't be surprised if i find a counting bug in Conversations

flow: I know it, my client doesn't

IIRC especially when acting as client it gets awkward since you start twice from separate events

Yeah

I think part of the trickery is to make sure not to send stanzas into the stream before you are resumed. Or at least don't count them

But that goes for servers and clients