XSF Discussion - 2019-07-24

  1. Guus

    jonas’ - are you available?

  2. jonas’

    depends on your definition of "available", Guus

  3. Guus

    jonas’: I've got quick questions about muclumbus, but I'm feeding the offspring now

  4. Guus

    Did my one-on-one message arrive? If so, I'll follow up on that after lunch

  5. jonas’

    Guus, no it did not, but that’s probably because you sent it to an account on which I’m currently not available

  6. jonas’

    an account which I generally prefer for 1:1 messages

  7. jonas’

    is there a reason we cannot discuss this in a more public venue, like here or operators@? (I still can’t join jdev@)

  8. Guus

    Didn't want to bother others. Will do here

  9. Guus

    Simple question really

  10. Guus

    Is-open, does that include public rooms that at the time of query cannot be joined because of a server policy (eg: amount of occupants is at a configured max)?

  11. jonas’

    Guus, no, because muclumbus does not attempt to join rooms

  12. jonas’

    it only works with the info available from disco#info

  13. Ge0rG

    so yes, it does include those rooms

  14. jonas’

    oh, yeah

  15. jonas’

    I got that inverted

  16. jonas’


  17. Guus

    Right. 🙂

  18. Guus


  19. jonas’


  20. Guus

    jonas’ follow-up question. The description of the 'q' form field is: "Optional string. Operates like the search box on the website."

  21. Guus

    ... how does the website behave?

  22. Guus

    I've now got: split value on whitespace, and split the to-be evaluated value the same way - then check if the evaluated value split contains all of the q split.

  23. jonas’

    Guus, it’s not properly documented, as you’ve found

  24. jonas’

    it is I think a shlex.split in python, which means that you can search for stuff including spaces by writing `"foo bar"` into the search box

  25. Guus

    website doesn't appear to do partial text search, so the 'split on whitespace' thing made most sense.

  26. Guus

    but might be incomplete, or plain wrong.

  27. jonas’

    the resulting keywords are fed into SQL surrounded by `%`

  28. jonas’

    https://search.jabbercat.org/search?q=gefl%C3%BC this shows partial match

  29. jonas’

    https://search.jabbercat.org/search?q=gefl%C3%BC this shows a partial match

  30. Guus

    oh, shoot, I missed the 3-character minimum thingy

  31. jonas’

    that’s a deployment-specific option

  32. Guus

    yeah, but it's why I though it was not doing partial matches

  33. Guus

    I searched for 'te', didn't get 'test' results.

  34. Guus

    (and didn't read the bright red warning message)

  35. jonas’


  36. flow

    pff warning messages, nobody reads those, c.f. compiler warnings

  37. Guus

    all search terms are AND'ed, nor OR'ed, right?

  38. jonas’

    Guus, yes

  39. Guus

    q, rolling version 2 ...

  40. Guus

    This seems to work fine. If I put this on a publicly reachable server, is there a way for you to test this, jonas’ ?

  41. Guus

    (or anyone else, for that matter?)

  42. jonas’

    Guus, yes, I have a test client software

  43. jonas’

    it’s even included in the public repo I think https://github.com/horazont/muchopper/blob/master/examples/request.py

  44. Guus

    that seems like something I can run myself

  45. Ge0rG is running a mirror bot that forks the pubsub data. Sometimes.

  46. Guus

    oh, but it doesnt create/populate mucs, I think?

  47. jonas’

    Guus, no, it doesn’t

  48. jonas’

    it only queries the search thing

  49. pep.

    I sent a link with poezio, and then I realized it was actually an image and some clients would display it a bit more user-friendly if I included the right tags. I sent an LMC with an OOB tag, but Conversations and dino don't display the picture anyway. Is that a bug? feature?

  50. pep.

    The XEP says: To deal with multiple payloads, the sender MUST re-send the entire stanza, only altering id and the payloads being corrected and adding the 'replace' payload. It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.

  51. lovetox

    read this the first time

  52. lovetox

    was that not changed a few weeks ago?

  53. lovetox

    LMC is about body for me

  54. lovetox

    and not all payloads

  55. Ge0rG

    pep.: OOB is abused by Conversations and other clients for inline media, with the restriction that url must be equal to message body

  56. Ge0rG

    not sure if you can LMC a picture into a message, though, as changing the type of message is forbidden by LMC

  57. lovetox

    its not abused at all

  58. lovetox

    or your definition of abused is weird

  59. lovetox

    oob adds a url to a message, and thats what we do

  60. lovetox

    using the xep like it was intended

  61. lovetox

    how i display messages with a oob tag is up to the client

  62. lovetox

    and not a concern of the xep

  63. Ge0rG

    lovetox: the abuse is because it's essentially used for inline images / media, and because of the undocumented body=url requirement

  64. lovetox

    how is that an abuse, to display a url added via oob inline?!

  65. lovetox

    the XEP makes zero statements as to how a client has to display a oob url

  66. Ge0rG

    lovetox: yes, so I could use the same syntax to append my avatar to all my messages.

  67. lovetox

    yeah and?

  68. Ge0rG

    it would be an equally legal use of 0066

  69. lovetox

    people not going to chat with you long when you do that

  70. lovetox

    not sure where the abuse is though

  71. lovetox

    protocol wise, you abusing people with messages, yes thats clear

  72. Ge0rG

    lovetox: only people using a client that's not adhering to XEPs will notice.

  73. Ge0rG

    All my messages are verbal abuse, nevermind the OOB

  74. Ge0rG

    OOB is not the right XEP for inline media, because it doesn't define how to display the URI, and because there is SIMS. Furthermore, clients only showing OOB media if url==body are enforcing an invisible specification.

  75. Ge0rG

    It's all wrong.

  76. Ge0rG

    It's only slightly less wrong than just HEADing every URL that's sent to you in a message body.

  77. lovetox

    you follow the notion that you think you got to decide if my client displays something inline or not

  78. lovetox

    there is no invisible specification

  79. Ge0rG

    lovetox: no, only that I'm the one who has to decide _how_ I intended my message to be shown

  80. lovetox

    you just found out implementation details of algorithm that decideds what to display inline

  81. lovetox

    and now you think its a invisible specification for you

  82. lovetox

    like its your job that a picture displays inline in MY client

  83. Ge0rG

    lovetox: XEPs are about interoperability between systems. If I see an image that I send inline, I expect your client to also display it inline, maybe with the exception that you explicitly disabled inline media.

  84. Ge0rG

    lovetox: as a client author, if I want to tell other clients to display a certain file inline, I now need to know that OOB has to be used (despite OOB not being made for inline media), and that I need to set the body to the URL, leave empty the description and send whatever text I want to accompany that image as a separate message. None of that is written down anywhere.

  85. lovetox

    There can be an endless settings go into the decision of a client if something is displayed inline

  86. lovetox

    you should not expect anything

  87. lovetox

    you should provide all data necessary to display something inline

  88. lovetox

    but thats about it

  89. Ge0rG

    lovetox: but you can keep pretending that there is no "inline media" and that all your client does is to use some creative rules to magically embed linked image files.

  90. Ge0rG

    > you should provide all data necessary to display something inline Yes, this is exactly what the fuss is about

  91. lovetox

    The problem is that you want to dictate UI and behaviour on another client, on such a complex topic as displaying weblinks inline

  92. Ge0rG

    lovetox: see, we have a fundamental disagreement on the basic assumption.

  93. Ge0rG

    lovetox: you speak about displaying weblinks, I speak about inline media.

  94. lovetox

    same story sorry

  95. Ge0rG

    no, those are completely different.

  96. Ge0rG

    lovetox: given your premise, I agree with all you said.

  97. lovetox

    not at all, its all some file on a webserver

  98. Ge0rG

    OOB is okay'ish for letting another client know that you reference a website or page of some sorts.

  99. Ge0rG

    but it's not how it's used by at least Conversations.

  100. lovetox

    So if i reference a website on facebook, the page shows inline

  101. lovetox

    thats my messenger, so i expect your client now to display it inline

  102. lovetox

    following your logic

  103. Ge0rG

    lovetox: please just stop.

  104. Ge0rG

    lovetox: as I said, we are speaking about two fundamentally different things.

  105. Ge0rG

    lovetox: please don't try to interpret what I said in the context of linking websites.

  106. lovetox

    I know you speak about pictures, but i already told you i dont accept your argument that this is not the same

  107. lovetox

    both can be displayed inline, both are displayed inline in real world by clients

  108. Ge0rG

    lovetox: yes, but the message is different.

  109. Ge0rG

    inline media: "here is a picture that I attach to my message" website reference: "here is a random weblink with which your client may do whatever it wants"

  110. lovetox

    so your argument is SIMS does not support weblinks

  111. lovetox

    so there is no way to tell other clients to show it inline

  112. lovetox

    hence you cant expect it to do it

  113. Ge0rG

    lovetox: what?

  114. Ge0rG

    I have never said anything about website references. I've been exclusively talking about inline media

  115. Ge0rG

    even in my first message, I explicitly wrote that.

  116. lovetox

    yeah so if SIMS would support sharing a website reference, and SIMS = Inline Media, then you would expect to see the website displayed inline?

  117. Ge0rG

    lovetox: sorry, I can't follow you.

  118. lovetox

    how do you tell a client to show a media inline?

  119. Ge0rG

    it looks a bit like you are trying to ask me trick questions to make me issue absurd statements.

  120. lovetox

    just by using SIMS right?

  121. lovetox

    its not a trick question, i think i understand what you are trying to say

  122. lovetox

    SIMS is not for website references

  123. Ge0rG


  124. lovetox

    oob does not say in the xep anything about inline

  125. Ge0rG


  126. Ge0rG

    SIMS is designed for inline media only

  127. Ge0rG

    it's a bit overengineered, but nevertheless.

  128. Ge0rG

    so for website references, you use something else than SIMS.

  129. Ge0rG

    you might use OOB, or just rely on the receiving client to parse the URL out of your body

  130. lovetox

    just for the record, i dont think anybody is opposed to implement SIMS over oob

  131. lovetox

    1. SIMS was not really a thing when this was implemented

  132. lovetox

    2. OOB is alot less to implement for clients

  133. lovetox

    so thats why this was chosen

  134. Ge0rG

    Yes, but it's still abuse of OOB.

  135. Ge0rG

    Also with OOB for inline media, you need to HEAD the URL to fetch the file type and size, before you can make any reasonable action with it or display an icon to the user

  136. lovetox

    i still dont see where the abuse is, the oob xep even shares a picture in its example

  137. lovetox

    so yes this XEP was clearly intended to share also links to media on the web

  138. Ge0rG

    but not for inline media in the client. ;)

  139. lovetox

    how you come to that conclusion is not clear to me, there is no way to indicate a inline display hint in oob, and your conclusion is : Its an abuse to show it inline

  140. Ge0rG

    no, it's an abuse for a sender to use OOB for inline media

  141. Ge0rG

    and for the recipient to imply that body==url --> inline media

  142. lovetox

    if your goal is to get more clients to use SIMS, i think you will be more successuful if you hint at the benefits that SIMS has over oob, like communicating the inline wish. Instead of shouting Abuse

  143. Ge0rG

    lovetox: do you know which clients implement SIMS?

  144. Zash

    Communicating hashes for integrity checks, ability to use different transports, thumbnails, what else are benefits of SIMS?

  145. pep.

    "Ge0rG> lovetox: no, only that I'm the one who has to decide _how_ I intended my message to be shown" something something 393 /me hides

  146. Holger

    > lovetox: do you know which clients implement SIMS? Movim IIRC?

  147. lovetox

    Ge0rG, Movim, Psi

  148. lovetox

    maybe converse, but not sure

  149. Ge0rG

    Zash: no need to do a HTTP HEAD

  150. Holger

    > Communicating hashes for integrity checks, ability to use different transports, thumbnails, what else are benefits of SIMS? I think edhelas was interested in metadata such as the size to avoid HEAD requests.

  151. Holger


  152. Zash

    Yeah, size and file type

  153. Holger

    And OMEMO people don't want to reveal that data. So I guess chances for implementation might be better once there's full stanza encryption.

  154. Ge0rG

    Speaking of OMEMO, https://xmpp.org/extensions/inbox/omemo-media-sharing.html combines the worst of both worlds.

  155. Ge0rG

    > The sending entity MAY also generate a thumbnail as a JPEG data uri and include that in the same message. The aesgcm:// and the data:image/jpep, are seperated by a new line character.

  156. Ge0rG

    Nuff' said.