XSF Discussion - 2018-12-30

  1. pep.

    TIL https://xmpp.org/extensions/xep-0209.html

  2. pep.

    I knew about the feature but I always thought it was a custom client thing

  3. mathieui

    didn’t we talk about it at the meetup?

  4. jonas’

    wait what

  5. jonas’


  6. jonas’

    same here, pep.

  7. jonas’

    now let’s move that to multi-item PEP and it’s actually useful.

  8. edhelas

    jonas’ <3

  9. mathieui

    pep., if you feel bored, don’t hesitate to fix https://lab.louiz.org/poezio/poezio/issues/2557

  10. pep.

    mathieui, I don't think so. Or I didn't understand it like that. I'm discussing this with sasza just now

  11. jonas’

    a proper solution for metacontacts of which the information lives server-side is somthing I wanted

  12. jonas’

    and then I ditched it. and now it doesn’t fit in my roster data model anymore.

  13. jonas’

    but given that it can greatly improve UX for those of us with (friends with) multiple accounts ... :)

  14. pep.

    There doesn't seem to be much security concerns for this meta-contact thing. owl was wondering if it was possible to use this as a pre-condition (but not requirement) for <moved/>. I also think it would be interesting

  15. pep.

    At the moment it seems I can just send a meta-contact tag for any other jid as long as I know their identity tag?

  16. jonas’


  17. jonas’

    send to whom?

  18. pep.

    Say I, userA, sends a meta-contact thing to userB, <meta jid='userA@jid1' tag='foo' .. />. Now userB knows my identity tag right, they could use it to send userC <meta jid='userB@jid1' tag='foo' ../> ?

  19. pep.

    There doesn't seem to be any auth mechanism(?)

  20. pep.


  21. jonas’

    XEP-0209 does not specify anything for sending a meta-contact thing to another user.

  22. jonas’

    so why should there be an auth or verification mechanism?

  23. pep.


  24. pep.

    I see

  25. jonas’

    did you only look at the examples? ;-P

  26. pep.

    Yes and I was confused

  27. jonas’


  28. pep.

    Because it's not what I thought it was

  29. pep.

    With owl we were picturing something else, users would be able to say "This is another account of mine"

  30. pep.

    That would need another XEP then.. and would probably need to interact with this

  31. jonas’

    put it in vcard?

  32. pep.


  33. jonas’

    I bet you can put a JID in a vcard

  34. jonas’

    put all your accounts in all your vcards

  35. jonas’

    also allows cross-validation

  36. pep.

    Yeah cross-validation should be a thing

  37. pep.

    The issue owl had was that with <moved/> (and even with what's being discussed, https://wiki.xmpp.org/web/Sprints/2018_November_Dusseldorf/Pad grep for moved), it's not possible to say "hey I moved to that other JID" anymore if the first server is down

  38. pep.

    Ge0rG, ^

  39. Ge0rG

    pep.: yes, also if you actually delete the old account. Moved is full of hairy corner cases of xmpp.

  40. Ge0rG

    Next time I have a bit of time to tackle it, I'll prepare a proposal for a new Moved, probably based on a mix of messages and pep

  41. edhelas

    is stream compression still a thing in XMPP ?

  42. Zash

    It has dubious security properties. Prosody got rid of it. Dunno about others.

  43. jonas’

    FWIW https://github.com/horazont/aioxmpp/issues/249#issuecomment-435442679

  44. jonas’

    (scroll to the bottom of that comment for a summary)

  45. jonas’

    TL;DR: if you do it right™, the benefits are rather slim, but it can at least revert the base64 overhead

  46. flow

    edhelas, I'd say yes, and I believe that the side channels can be closed

  47. flow

    jonas’, you consider 12% bytes saved in the worst case "rather slim"?

  48. flow

    Or am I misreading the stats and its 1.2% or something?

  49. Zash

    Does it consider the extra memory usage on servers?

  50. jonas’

    yes, 12% is rather slim IMO

  51. jonas’

    12% is low enough that I’d be interested if the additional CPU time involved on the client side isn’t worse than transmitting the extra bytes

  52. jonas’

    (not to mention the memory overhead)

  53. Zash

    As a server dev, I'd rather avoid more memory usage

  54. edhelas

    I saw some security issues regarding TLS + compression as well

  55. Zash

    Yeah, you don't want SASL / password anywhere near compression.

  56. jonas’

    "password or password-equivalent" is probably more fitting, given that SCRAM for example is safe-ish even without encryption, IIRC.

  57. Zash

    Depends on what you wanna protect or be safe against

  58. vanitasvitae

    XML namespaces containing multiple occurences od ':' (eg. "urn:xmpp:bob") are valid, are they? https://github.com/dino/dino/issues/394#issuecomment-450573159 Maybe someone can shine some light on this issue?

  59. vanitasvitae


  60. lovetox

    this is indeed wrong vanitasvitae

  61. vanitasvitae

    So such namespaces are not allowed?

  62. lovetox

    as you see on the captcha node

  63. lovetox

    namespace and node name are exchanged

  64. lovetox

    the thing is the namespace is not as namespace declared

  65. lovetox

    as you can read <urn:xmpp:captcha xmlns='captcha'>

  66. lovetox

    but it should be

  67. lovetox

    <captcha xmlns='urn:xmpp:captcha'>

  68. lovetox

    if this comes from an ejabberd, this is a major bug

  69. vanitasvitae

    ah 😀

  70. vanitasvitae

    Okay, I understood it wrong then

  71. vanitasvitae

    I thought "xmlns='urn:xmpp:bob'" would be illegal.

  72. lovetox

    are you not running a stable version?

  73. vanitasvitae

    Thanks for clarifying.