jdev - 2022-01-06

  1. Sam

    For IBB XEP-0047 (IBB) section 2.2 says that if the sequence number has been used we return unexpected-request. It also says that if anything is received out-of-sequence to close the bytestream. If you get a sequence number larger than expected, is there no error? Just a cleanly closed bytestream?

  2. Sam

    I feel like the same error should be sent no matter what if you get a bad sequence, not just "close the bytestream as described in the next section"

  3. MattJ

    That was probably the intent, I guess

  4. flow

    yep, we should probably "Because the sequence number has already been used or is larger than expected" write there

  5. Sam

    Or just remove the whole paragraph about closing it if the sequence number is wrong

  6. qy

    My two client instances aren't announcing devicelists to each other (and therefore bundles either), can i clarify what exactly triggers pubsub to send updates?

  7. MattJ

    Your client must implement disco (XEP-0030), caps (XEP-0115) and advertise support for the feature '<node name>+notify'

  8. MattJ

    https://xmpp.org/extensions/xep-0163.html#example-4 and surrounding text

  9. qy

    MattJ: So, I already do send out `<feature var="eu.siacs.conversations.axolotl.devicelist+notify"/>`, with a caps ver that is just set to the current time so it's always fetched fresh, but in response, nothing comes back? That's the server's duty no?

  10. qy

    Also ``` <identity category='account' type='registered'/> <identity category='pubsub' type='pep'/> ``` is missing from my disco result, maybe its that

  11. Zash

    from your account?

  12. qy


  13. qy

    Apparently it's not mattered til now

  14. Zash

    wait what

  15. Zash

    > caps ver that is just set to the current time u wut

  16. qy


  17. qy


  18. qy

    Hate me :p

  19. qy

    It was a debug build hack that ive yet to correct

  20. qy

    Didnt seem to break anything either, til perhaps now

  21. Zash

    ah, node, not the actual `ver=`?

  22. qy


  23. Zash


  24. Zash


  25. Zash

    why is there a screenshot of code here

  26. qy

    To show the logic

  27. qy

    I build the node from http://weechat.org# + current time with zeros padding + =

  28. qy

    Tldr it means the server always disco requests me, aiui

  29. Zash

    Thanks I hate it

  30. qy


  31. qy

    Right, so im ok on the identity thing, thats the disco for the bare jid, and it returns correctly, with pep

  32. MattJ

    qy: I don't know without looking, but if you're not doing XEP-0115 then I don't know if you can count on it working correctly in Prosody at least

  33. qy

    Understandable. It didn't break so far, and all the other features work, so i've not been in a rush to sort that

  34. MattJ

    Consider this incentive to not spam the XMPP network with disco queries and responses 😉

  35. qy

    Conscious of the fact that that part of my code has the line `// This is utter bullshit, TODO: anything but this` too anyway 👀

  36. MattJ


  37. edhelas

    JDev doesn't have a MUC Avatar :(

  38. Maranda added one to it

  39. Maranda


  40. Maranda


  41. Maranda hates iconless rooms as well.

  42. qy

    I don't see it, is that a clientside hack

  43. Maranda

    sort of

  44. edhelas

    all the cool MUC have a MUC Avatar

  45. contrapunctus

    Doesn't appear in Conversations 😶

  46. qy

    Right, caps vaguely sorted. No more spam at least

  47. qy

    So, iqs are going through with unique ids and to and from, devicelist sets are getting a response, but my two clients arent sending each other devicelists, not sure what's up

  48. pep.

    Your clients don't "send each other" devices lists

  49. qy

    pep.: The server does, right?

  50. pep.


  51. qy

    With devicelist+notify

  52. pep.


  53. qy

    Yeah, thing is, thats not happening

  54. pep.

    You can test with something else that's not devicelist maybe. Try avatars?

  55. qy

    Well, i kinda have, "urn:xmpp:chat-markers:0" is on and that works... do you mean if i have "urn:xmpp:avatar:metadata+notify and i update my avatar i should see it too?

  56. qy

    As a new presence

  57. pep.

    0084? urn:xmpp:avatar:metadata+notify

  58. qy


  59. pep.

    Not as a new presence

  60. pep.


  61. pep.

    You do have presence subscription to that jid right?

  62. qy

    I'm honestly not sure anymore

  63. pep.

    (Otherwise they'll likely never check your caps, or ain't be able to, and you won't get notified)

  64. pep.

    (Otherwise they'll likely never check your caps, or won't be able to, and you won't get notified)

  65. qy

    (Hang on, ive a feeling im missing something obvious)