jdev - 2022-01-07

  1. qy

    Mother of christ, legitimately the first time i'm seeing https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe

  2. qy

    So yeah i guess thats it, my hacky pubsub shims are coming back to bite me

  3. MattJ

    qy: for PEP you do *not* need to subscribe to the node manually (some servers may not even support it)

  4. MattJ

    PEP has automatic subscriptions when someone authorizes you as a contact

  5. qy

    MattJ: oh, okay

  6. qy

    Thankful, it wasn't working very well anyway

  7. Sam

    Is there any spec (or individual client or server) that uses in-band bytestreams somehow without eg. wrapping it in a larger protocol that would need to be implemented? I don't know why anything would accept an arbitrary bytestream without some other form of negotiation, but I just realized I have absolutely no way to integration test this unless I also implement Jingle or something.

  8. MattJ

    Sam, did you say https://modules.prosody.im/mod_tcpproxy ? :)

  9. Sam

    Oh thanks, that looks almost perfect

  10. MattJ

    It hasn't been touched for a long while, but I'd be surprised if it doesn't still work. If it doesn't, give me a shout, any issues are probably simple fixes.

  11. MattJ

    I did use it for stuff, back when I wrote it

  12. Sam

    Will do; thanks. I'm mostly concerned with the use of namespace prefixes (this XML library doesn't support prefixes in general, and their use here means that even if it did I'd also have to add specific support to the IBB library, which doesn't feel right, but I'm sure I'll figure something out)

  13. jonas’

    it doesn't implement Namespaces for XML 1.0?

  14. Sam

    It implements namespaces using xmlns and has read-only support for prefixes.

  15. jonas’

    that's ok

  16. jonas’

    the code supports you using a non-`tcp` prefix

  17. jonas’

    if your library doesn't even support that… I'd say you used the wrong XML library to write an XMPP library ;)

  18. Sam

    Oh cool, I *think* if I set an attribute with a namespace it's happy to make up a prefix (ie. it will just do xmlns:_ns1 or something on the current attribute), so that may be fine

  19. Sam

    We'll see. I think it's fine given that XMPP doesn't use prefixes in general.

  20. Sam

    Either way though, figuring out how to add extra attributes to IBB without building in support for this specific non-standard protocol to the IBB library will be weird. Adding arbitrary attributes isn't an extension point I normally support

  21. jonas’

    I'd also have expected a child element to be honest.

  22. Sam

    I don't generally support stuff like that either for things like IBB that are well defined and don't say "and also this can take an arbitrary payload too" if I'm honest, but yah, if I'm just thinking about data modeling with XML I guess I'd expect a child

  23. jonas’

    hm, but that's how XMPP works, kind of

  24. jonas’

    putting things in a different namespace into other things

  25. jonas’

    to extend them

  26. Sam

    Sure, but I've never really had a problem with it. I just support specific specs. ibb.Open(to, blocksize) or whatever is way easier than returning some custom thing that you can also modify and call add child on and do a builder and then eventually send.

  27. jonas’

    myeah, kind of a pain when you'd want to do some rapid prototyping

  28. Sam

    I guess; hasn't been a problem in practice. Specs mostly indicate whether they expect to be extended or not.

  29. jonas’

    nobody expects the ~spanish inquisition~ extension elements!

  30. pep.

    “I'd also have expected a child element to be honest.” < I guess that's because of the fact that we don't do much ns'd attributes, unfortunately, so we're going in circles :(

  31. Sam

    Just glancing at aioxmpp it seems to work in a similar way, though maybe I'm misunderstanding something. I can't imagine most libraries let you fully customize every single possible spec and stanza

  32. jonas’

    pep., ah, no, here primarily because a child element would allow extension itself.

  33. pep.

    I'm not sure I understand the difference really. Why wouldn't the attribute allow it

  34. jonas’

    Sam, due to the separation of business logic and stanza construction as well as inheritance it's rather easy to patch things though

  35. pep.

    As long as there's wire protocol to say you use an extension (be it an ns'd attribute or tag)

  36. jonas’

    pep., example: extend the protocol up there to do direct TLS over TCP and include a list of root CAs .

  37. jonas’

    pep., example: extend the protocol up there to do direct TLS over TCP and include a list of root CAs.

  38. Sam

    jonas’: I think what he's saying is that you could always do customtcp2:tls="whatever" as well in the same element. It doesn't matter if it's a child of the original data somehow.

  39. pep.

    I think it's just an arbitrary choice whether we use attributes or tags. A lib could make it as easy to do one or the other it's just that we're used to tags

  40. jonas’

    Sam, but representing *lists* (e.g. of root CAs) in attributes is a PITA :)

  41. Sam

    Sure, but that wasn't the original point of contention. The original question was "should host/port be an attribute or an extension" and neither of those are lists that are difficult to represent.

  42. jonas’

    Sam, having them as an element makes the "do TCP" extension more extensible though

  43. jonas’

    that was my point for favouring an element

  44. qy

    TCP over XMPP? Does that mean you could REST over XMPP? Cause that means Homeserver over XMPP is possible

  45. Sam

    Why? You could leave the protocol exactly as is (eg. "tcp:host" attributes) and also add a <tcp2:rootca> element. Or you could add a <tcp><rootca> element, it doesn't matter if it's nested or not.

  46. Sam

    qy: see also https://xmpp.org/extensions/xep-0332.html

  47. jonas’


  48. Link Mauve

    “20:06:30 qy> Tldr it means the server always disco requests me, aiui”, you might receive a request, but the server might verify the hash of your response and throw it away if it doesn’t match.

  49. qy

    That's a thing? Bugger me sideways

  50. pep.

    Sam, yeah exactly, I also think it doesn't matter, it's just an arbitrary choice

  51. qy

    Sam: Beautiful

  52. pep.

    Might look prettier or easier to understand. And these aren't at all subjective obviously /s :)

  53. Link Mauve

    MattJ, “and a block-size, if given, is (currently) ignored.”, that’s illegal as per XEP-0047, this attribute is a MUST.

  54. jonas’

    patches welcome?!

  55. pep.

    It could be specified that 'http://prosody.im/protocol/tcpproxy' ignores the MUST :)

  56. jonas’

    I think you have +w on that repository ;)

  57. pep.

    And be done with it

  58. Link Mauve

    I do.

  59. Link Mauve

    Hmm, XEP-0332 doesn’t mention anything about encodings, we know XMPP is UTF-8 but what if a HTTP server advertises text/plain;charset=utf-8 but returns non-UTF-8 as the content?

  60. jonas’

    you'd have to inject Transfer-Encoding: base64 I guess

  61. Zash

    Oh it has https://xmpp.org/extensions/xep-0332.html#sect-idm45815412462064

  62. xnamed

    I have a question about https://xmpp.org/extensions/xep-0045.html#disco-occupant What if a non-occupant - who has owner affiliation - queries room configuration or its affiliation lists? If this should be allowed, why not include something like <feature var='http://jabber.org/protocol/muc#owner'/> in the room disco info result when it's available for use?

  63. qy

    > Link Mauve wrote: > ...but the server might verify the hash of your response and throw it away if it doesn’t match alright, sorted now. I have to say, kind of a shitty behaviour to just discard the response with no indication if that is whats happening though

  64. qy

    Luckily didnt have to modify much overall

  65. qy

    Manual sorting :D