XSF Discussion - 2017-10-07


  1. edhelas

    what is the default behavior when a JID choose to quit a MUC

  2. edhelas

    looks like most of the clients are not even waiting for the ACK, which can be quite problematic (what if the JID is still connected ?)

  3. jonasw

    edhelas, can you clarify?

  4. Ge0rG

    Another one bites the dust. https://mobile.twitter.com/aim/status/916290747850264577

  5. jonasw

    now, all we need is a super-elegant way to get people into the XMPP network

  6. jonasw

    off the top of my head: set up an XMPP domain, deploy an AIM transport, let people log in with $aimidentifier@domain.example, import their roster with the @domain.example suffix.

  7. jonasw

    I am amazed by the twitter thread though

  8. jonasw

    @aim is doing good work there

  9. edhelas

    jonasw to leave a MUC you send a presence unavailable to the MUC, some clients choose to directly say "you're disconnected from the muc"

  10. jonasw

    edhelas, yeah, I mean, what you gonna do anyways?

  11. edhelas

    wait for the ACK :)

  12. jonasw

    sure, but what if you don’t get the ACK

  13. edhelas

    that's what I'm saying

  14. jonasw

    yeah, I mean, what’s a client to do about it anyways?

  15. jonasw

    it can resend unavailable or start ignoring the messages, because the user clearly doesn’t want to be in the MUC anymore.

  16. jonasw

    why would it wait for the ACK for updating the UI if it can handle everything else under the hood without user interaction?

  17. edhelas

    what if I send a leave presence, server don't handle it, then I continue to receive messages and presences from the MUC

  18. jonasw

    resend an unavailable presence on each presence and message from the MUC until it "gets the message" ;-)

  19. jonasw

    just like the TCP stack will send RSTs to each and every unwanted packet.

  20. edhelas

    \o/

  21. jonasw

    (or maybe send an error presence, that’d be okay too, I think)

  22. jonasw

    (or error message, depending on the received thing)

  23. Ge0rG

    Yeah, send errors until the MUC finally kicks you out.

  24. jonasw

    RST RST RST

  25. jonasw

    Ge0rG, errors or presence unavailable?

  26. Ge0rG

    jonasw: errors.

  27. jonasw

    mhm

  28. Ge0rG

    jonasw: you forgot the Emoji conversion plug-in.

  29. jonasw

    context?

  30. Ge0rG

    jonasw [12:40]: > mhm

  31. jonasw

    Ge0rG, that’s only in pidgin, and I turned it off again because it caused interoperability issues

  32. Guus

    an XMPP domain shouldn't be identifying PEP identities and features, should it (unlike its entity JIDs)?

  33. ralphm

    I think an XMPP domain should totally be advertising that it supports PEP

  34. ralphm

    Or do you think it only makes sense to ask a particular user account?

  35. ralphm

    I guess PEP is a special one out, because you'd want to find out before you create an account.

  36. Guus

    that's what https://xmpp.org/extensions/xep-0163.html#support implies

  37. Guus

    also, there's no pep feature, or is there?

  38. Guus

    just an identity

  39. Zash

    Indeed

  40. Guus

    and it feels wrong to me for the server to identify itself as a PEP service

  41. Guus

    (I'm talking about the XEP-0030 kind of service discovery, by the way - not advertising stuff on the website :P )