XSF Discussion - 2018-07-21

  1. jonasw

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

  2. Link Mauve

    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.

  3. jonasw

    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.

  4. Link Mauve

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

  5. Link Mauve

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

  6. Link Mauve

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

  7. lovetox

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

  8. lovetox

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

  9. Link Mauve

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

  10. lovetox

    on each start of the client

  11. Link Mauve


  12. lovetox

    yes thats exactly what i would need

  13. lovetox

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

  14. Link Mauve

    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.

  15. lovetox

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

  16. lovetox

    i mean yeah it could, but why should it

  17. lovetox

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

  18. Zash

    was disco-sub a xep or how was it?

  19. lovetox

    we simply dont do ti

  20. Link Mauve

    lovetox, I’ve seen it done.

  21. lovetox

    yeah then this server should not use caps

  22. lovetox

    simple as that

  23. Link Mauve

    Why that?

  24. Link Mauve

    It’s still a valuable optimisation.

  25. lovetox

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

  26. Link Mauve

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

  27. lovetox


  28. lovetox


  29. lovetox

    for longer time, then send out a updated hash

  30. Zash

    Bunneh: xep caps2

  31. Bunneh

    Zash: Sorry, I couldn't find a match

  32. Link Mauve

    xep ecaps2

  33. lovetox


  34. lovetox


  35. Link Mauve

    Bunneh, xep ecaps2

  36. Bunneh

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

  37. Zash


  38. Ge0rG

    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 server.

  39. Ge0rG

    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.

  40. Link Mauve

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

  41. Ge0rG

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

  42. Link Mauve

    Oh wow.

  43. flow

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

  44. daniel

    Counting is surprisingly hard

  45. daniel

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

  46. Ge0rG

    flow: I know it, my client doesn't

  47. Zash

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

  48. daniel


  49. daniel

    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

  50. daniel

    But that goes for servers and clients