jdev - 2021-08-25


  1. Sam

    Working on another ad-hoc implementation and decided whomever said that he thing about multiple payloads meant you were only supposed to display one and fallback if you don't support that payload type must be correct. Except then it starts talking about things with the same priority and that makes no sense and I still have no idea how any of this is supposed to work (╯°□°)╯︵ ┻━┻

  2. Sam

    > The requester SHOULD consider those elements qualified by the same namespace as having an equivalent precedence (such as if multiple "jabber:x:oob" elements are included). If anyone has any idea what that sentence means I'd be grateful. If I have <oob/><form/><oob/> am I supposed to parse out the two OOBs and show them both? Pick one at random? I have no idea.

  3. noob

    test something

  4. noob

    can anyone receive my message?

  5. wurstsalat

    noob, yes

  6. emus

    > southerntofu escribió: > emus, you'd like to remove XMPP from the name or? no, jdev is a bit short

  7. southerntofu

    emus, agreed!

  8. southerntofu

    > the responder SHOULD respond with a 403 "Forbidden" error (XEP-0050) <-- are HTTP status codes a thing in XMPP? never seen it elsewhere

  9. jonas’

    southerntofu, then I recomend you read RFC 3920 ;)

  10. jonas’

    oh, it's not even in there

  11. jonas’

    then it must be even more ancient

  12. southerntofu

    yeah that's what i thought XMPP Core defines error types not codes :)

  13. jonas’

    haha what

  14. jonas’

    RFC 3920 mentions that the schema in RFC 3921 defines a code attribute for backward compat

  15. jonas’

    it is defined as a byte though, so maximum 255

  16. jonas’

    which makes absolutely no sense for how error codes are *actually* seen in the wild

  17. southerntofu

    oO

  18. jonas’

    in 2015 or so I was still getting code='401' from some ejabberd deployment I think :)

  19. southerntofu

    Sam, yeah that's really unclear. i just read the hwole spec just to gather more context.. i guess it would require to survey existing client/server implementations to see what they do and update the spec accordingly

  20. Sam

    southerntofu: thanks for the help, glad it's not just me

  21. me9

    > I wrote: > Which xmpp.org muc is the most fitting to ask about and discuss XEPs? This one? Any idea?

  22. jonas’

    me9, xmpp:xsf@muc.xmpp.org?join

  23. me9

    jonas’: Thank you.

  24. jonas’

    I missed your question over the day change, sorry :)

  25. me9

    No problem.

  26. Sam

    I am starting a list of open question about ad-hoc commands because this entire XEP is extremely confusing to me. I'll try to clarify / fix the XEP later. If you have anything to add, I would appreciate it: https://pad.disroot.org/p/adhocquestions

  27. Sam

    Are there any common payload types that get used in ad-hoc commands other than those defined in the XEP?

  28. jonas’

    those defined in the xep == data forms?

  29. Zash

    Isn't there some hints that you could have pretty much any payload in place of datafroms?

  30. Zash

    > The payload can be elements in any namespace that makes sense and is understood [...]

  31. Sam

    data forms, notes, and oob I think are in the XEP

  32. Sam

    I was just wondering if anyone had seen anything else in the wild

  33. Zash

    I don't think so

  34. Sam

    Excellent

  35. Zash

    The thought of using 432 or 335 occurred at some point, but thankfully I never actually did such a thing