jdev - 2021-11-10

  1. Sam

    Is there anyone who has done an implementation of Message Styling that would be interested in using a shared set of unit tests to ensure compatibility?

  2. nephele

    Sam: What do the unit tests do, check the rendering of items or so?

  3. Sam

    nephele: yah, they take in a message and spit out what parts of the message should have what styles

  4. nephele

    Ah, so it's unit tests for the parser part

  5. nephele

    Are these for https://xmpp.org/extensions/xep-0393.html ?

  6. Sam


  7. nephele

    I am reading it, I'm quite lost on what a child block is, is this only in reference to nested quotes?

  8. nephele

    Anyway, I want to implement message formatting for Renga at some point or another, If i can figure out how to include unit tests that could be quite neat to have the same ones

  9. pulkomandy

    you can have unit tests in Renga by comparing the text_run_array in a BView with the expected output from the test, I guess? Sounds possible to do at least

  10. nephele

    I'm not sure if something like quotes could be represented with a text_run_array

  11. lovetox

    the more i look into python xml libs the more i believe xmpps decision to not use prefixes is actually the weird thing that nobody does

  12. lovetox

    i think one can say there i almost no support in libs for so called "default" namespaces

  13. lovetox

    pythons etree.Element, has no way of setting a default namespace, nor parsing it

  14. lovetox

    lxml supports them better, but it still fills like something which is a second class citizen

  15. MattJ

    lovetox, I've no idea what you mean... an XML library either supports namespaces or it doesn't. XMPP doesn't do anything weird, and there's not really any such thing as a "default namespace" in XML (actually there is, but let's not go there)

  16. lovetox

    i also thought that, but its not the case, or it depends what you mean by supports

  17. lovetox

    if you parse that with pythons included xml lib

  18. lovetox

    '<a xmlns="test" />'

  19. lovetox

    you get an object and if you serialise it back its

  20. lovetox

    '<ns0:a xmlns:ns0="test" />'

  21. Zash

    why the

  22. Trbl

    fk would you implement xmpp in python

  23. flow

    looks like a valid transformation?

  24. Zash

    looks like an excellent way to convince people that xml is scary and to use json instead

  25. flow

    even though not an optimal one

  26. lovetox

    flow how does that help me if xmpp says i should use no prefixes :D

  27. Trbl

    should or must

  28. Trbl

    i'd just say fuck it if its the first case

  29. flow

    probably not much, but then again, I think, at least those kind of prefixes are fine

  30. flow

    a different (and desirable) kind of prefixes are the ones that a declare in <stream/>

  31. flow

    a different (and desirable) kind of prefixes are the ones that a declared in <stream/>

  32. flow

    those are probably likely to cause issues with certain impelementations

  33. flow

    but not the prefixes that are introduced by the transformation you showed

  34. flow

    assuming they are only done on a sub <stream/> level

  35. lovetox

    so every server will be ok if i send

  36. lovetox

    <ns0:message xmlns:ns0="jabber:client" />

  37. lovetox

    because that would be great :D

  38. Zash

    Prosody will be fine. ``` > util.xml.parse[[<ns0:message xmlns:ns0="jabber:client" />]] <message xmlns='jabber:client'/> ```

  39. flow

    lovetox, maybe not every server, but chances are high that the XML parser on the receiving end will handle it just fine

  40. flow

    but still, the transformation is not space-efficient, so you may want to avoid it

  41. flow

    maybe there is simple switch to change the behavior of serialiser?

  42. Zash

    space-efficiency would be to stuff a ton of namespace prefixes on the stream header

  43. Zash

    `<sm:r/>` etc

  44. flow

    sure, but let's do baby step and get this fixed first

  45. flow

    sure, but let's do baby steps and get this fixed first

  46. flow

    Zash, would prosody support namespace declartions in <stream/>? if so, announce it as stream feature and I'll implement an optimization in Smack for it

  47. Zash

    All that's handled transparently by libexpat, so should work fine

  48. Zash

    The receiving/parsing side at least.

  49. flow

    Zash, then we should consider specifying a stream feature for this. so that clients can safely perform this optimization

  50. flow

    as I have heard that other servers bail on it

  51. Zash


  52. MattJ

    But the stream feature comes after the client already sent the opening stream header...

  53. Zash

    Save it for the post-sasl stream restart

  54. Zash

    assuming we still have a stream restart in the future

  55. MattJ

    Carry state between the unauthed and authed streams?!

  56. Zash


  57. Zash

    Maybe, one day, we should redesign the whole stream startup thing.

  58. flow

    if it's an non-TLS connection that its fine

  59. flow

    otherwise you have to announce the feature after TLS

  60. flow

    but before auth

  61. flow

    I think this should be safe?

  62. Zash

    Make it client-first, where it sends all the extensions it wants, and the server picks the parts it likes

  63. MattJ


  64. Zash

    Since this is the server telling the client things _after_ it has been authenticated with TLS & certs

  65. Zash

    no wait

  66. Zash

    aaaaargh, everything is backwards

  67. Zash


  68. Zash

    so confused

  69. Zash

    Server does advertise things after it has been authenticated. Then the client authenticates. And then it does the thing.

  70. Zash

    So, should be fine?

  71. flow

    simply in the stream features of step 8 in RFC 6120 § 9.1.1

  72. flow

    then the client can declare the namespaces in step 13

  73. flow

    so besides the <mechanisms/> in <stream:features/> you have a <namespace-prefixes-in-stream/> flag

  74. Zash

    as a bonus, after the restart, throw in a namespaced attribute on the opening stream header to tell the server it's okay to do the same thing

  75. Zash

    `<stream:stream to="example.com" ns:prefixes="ok" xmlns:ns="urn:xmpp:tbd:namespaces-prefixes">` something something