jdev - 2022-07-26

  1. Guus

    Has anyone ever gotten Tsung test running with XMPP over websockets? I can't get it to send the rfc7395-mandated 'open' replacement for the 'stream' element.

  2. lovetox

    how do lib devs handle presence with no type, regarding of routing, attaching stanza handlers

  3. lovetox

    how does the API look for a client, to connect to a "no type attr" stanza

  4. lovetox

    because not specificing a type, means for me, i want all presences, so no type filtering

  5. flow

    lovetox, smakc defaults to type available

  6. flow


  7. lovetox

    so you invent a type

  8. flow

    pretty sure it wasn't me

  9. lovetox

    this was also my idea ..

  10. lovetox

    its really again weird that this is not consistnet, messages have real default for type

  11. lovetox

    presence not

  12. flow

    think of it as: the default, if not explicitly set, is available

  13. lovetox

    its not a problem to understand it, its simply bad design

  14. flow

    I think it's not the worst designed parts of XMPP, but yes, it is strange that there is no explicit 'available' type

  15. lovetox

    its not even in the top 10 :D

  16. flow

    that is inconsistent and does not follow other XMPP design patterns where we have, the default value of the attribute 'bar' is 'foo' if not set (but you may also send bar=foo if you want)

  17. flow

    to be frank, if you hadn't pointed out that 'available' does not appear in the XML schema for presence, I wouldn't be able to tell

  18. lovetox

    its problematic for the way i designed the lib, my lib does first parse attributes, tag names, namepspaces, creates a handler chain, and sends the stanza then to all these handlers

  19. lovetox

    the lib itself uses handlers to contruct then some object that abstructs the xml away for the client

  20. lovetox

    but now i have to special case the attribute parsing bevor i contruct the handler chain, because my own lib cannot register a handler for "available"

  21. lovetox

    though if i think about it

  22. lovetox

    i do the same for messages anyway

  23. lovetox

    ah ..

  24. lovetox

    the difference would be while i insert a type=normal and i dont make the stanza with that move invalid

  25. lovetox

    i now need to insert a type=availalbe into the xml ..

  26. lovetox

    rather ugly

  27. nav

    It's not something that I had thought about until now, but one wants to be careful trying to equate JIDs with identities (as in, concrete users), because that is not necessarily the case.

  28. nav

    It's the same as email. If your email address gets reused, the new user will have access to lots of stuff where you used your email as an ID (unless 2FA, etc.) Same with JIDs and XEP-0077 registrations (unless password / 2FA / etc.)

  29. nav

    Server owners, especially those who recycle unused JIDs, would do well to disallow JID reuse.

  30. nav

    I don't recall if servers already offer an out of the box solution for that.

  31. nav

    Or maybe servers could provide a unique key for each registration that could be discovered via XEP-0030?

  32. nav

    So that you can tell if someone recycles a JID.

  33. Zash


  34. nav

    Zash: 👍👍

  35. Zash

    So, does anything support XEP-0440 and RFC 9266 ?

  36. Zash

    Sam, https://hg.prosody.im/trunk/rev/29685403be32 ;)

  37. Sam

    Wow, the RFC was only published a few hours ago, that was fast!

  38. Zash

    Found the first bug!

  39. Sam

    I'll write some integration tests after work