XSF Discussion - 2020-12-09


  1. waqas

    The "Character counting in message bodies" thread on the Standards ML is mildly amusing, we haven't had one of these in a while.

  2. Kev

    I hope I helped with that :)

  3. waqas

    It's basically a "someone is wrong on the internet" thread

  4. waqas

    https://xkcd.com/386/

  5. edhelas

    do we have somewhere a full list of forbidden characters for JIDs ?

  6. Kev

    RFC 762

  7. Kev

    RFC 7622

  8. jonas’

    Kev, I liked your email :D

  9. jonas’

    also, can someone point me at an XML library which really gives you the raw bytes on the wire and how it handles entities? :)

  10. jonas’

    because if we’re going to count bytes on the wire, we obviously also have to count the bytes used for entities.

  11. jonas’

    "have fun with *that*"

  12. Ge0rG

    I was very much interested in the IoT hot-path where you really need the body character counts, but jonas’ kind of already raised this question.

  13. flow

    I think statements like these and "…much easier than writing 20 emails on this topic" are potentially harmful, as they could interpreted as an attempt to suppress discussion. I found the thread insightful (at least some parts of it).

  14. jonas’

    flow, ok, noted, thanks for the feedback

  15. jonas’

    I am a bit annoyed by the thread because I had essentially the same discussion already a few years back when I brought this specification gap up in References.

  16. Kev

    As far as I can see, it should be codepoints.

  17. flow

    jonas’, I get that, but that is probably more an indication that we are not good in transforming those discussions into a specification

  18. flow

    Kev, nice try ;)

  19. mathieui

    (as long as I don’t have to transform my unicode codepoints into entities again to be able to use this XEP I will be happy with the result, so I’m staying out of that discussion)

  20. jonas’

    flow, yeah, because nobody makes a final call

  21. jonas’

    mathieui, oh, why not? don’t you want to guess whether the sender used = instead of 'a' everywhere?!

  22. flow

    Kev, nice try ;) (or was that not an attempt to resurfcace that discussion here?)

  23. jonas’

    mathieui, oh, why not? don’t you want to guess whether the sender used a instead of 'a' everywhere?!

  24. mathieui

    that would be fun

  25. Kev

    flow: I wasn't trying to start discussion, I was saying that to me the case is clearcut for codepoints.

  26. Ge0rG

    jonas’: but what if you want to highlight the "#"?

  27. Kev

    (Commenting as the References author)

  28. jonas’

    Ge0rG, shush!

  29. jonas’

    I should write an XML serialiser which creates the most expanded version possible of any character data

  30. Ge0rG

    the recent MS Teams "important, spoofing" issue makes me want to stuff U+0000 into an xmpp message and see where it gets killed.

  31. Kev

    jonas': Take that, "nobody makes a final call" ;p

  32. jonas’

    Ge0rG, libexpat and libxml2 throw errors at you when they encounter it on the input

  33. jonas’

    so at least prosody should kill your stream

  34. jonas’

    not sure what ejabberd does

  35. waqas

    jonas’: I think wrapping each character in CDATA is the best you can do

  36. waqas

    No wait, empty CDATA sections are legal, so you can do a lot better

  37. jonas’

    waqas, oh, that means infinite expansion… let us omit CDATA sections from considerations then :)

  38. waqas

    Ge0rG: \0 isn't a legal XML character. CDATA sections, entities, etc don't let you work with non-legal characters, they are more an alternate encoding, but work with the same characters.

  39. Ge0rG

    waqas: I know. But it wouldn't be the first time for illegal characters going places.

  40. Zash

    You know what doesn't have character counting problems? Embedded markers. Perhaps we could use some special characters to "mark up" sections that have some special meaning.

  41. waqas

    Ge0rG: You can probably target pseudo-XML parsers that some servers have, e.g., Tigase I think was pretty liberal

  42. Ge0rG

    Zash: yes, let's use the zero-width-space as an escape character, followed by an xml element defining the markup

  43. Zash

    Or we could use <> since those are special in xml

  44. waqas

    I think counting bytes or code points is a mistake, we should instead count graphemes, as that corresponds to what is rendered and the user sees!

  45. Zash

    waqas: that position is taken already

  46. waqas

    oh no

  47. Ge0rG

    waqas: ITYM grapheme clusters.

  48. jonas’

    let’s count rendered CSS pixels

  49. jonas’

    (as opposed to device pixels)

  50. Zash

    jonas’: I was just about to type 'what about pixels'

  51. jonas’

    ^5

  52. waqas

    We'll just need to include the font and font-size, etc used for rendering, and then we are all set

  53. Ge0rG

    how do you treat off-screen hidden text?

  54. waqas

    Or does that need to be configurable?

  55. jonas’

    waqas, no, obviously that’s all available from context.

  56. jonas’

    just like the wire encoding is

  57. Ge0rG

    https://www.getdigital.de/web/getdigital/gfx/products/__generated__resized/1100x1100/4883CSS-sucks-v2_4883_square.jpg

  58. waqas

    Yay for binary XML

  59. Zash

    Don't forget compression

  60. waqas

    Also accessibility, e.g., if the text isn't rendered but spoken

  61. Ge0rG

    you also need to reverse count characters in RTL languages

  62. flow

    Kev, FYI the unicode spec seems to always talk about "code point(s)", not "codepoint(s)"

  63. flow

    not sure if this is a AE vs BE thing

  64. Kev

    Just a Kev thing, probably.

  65. Kev

    I'll fix it in a moment once I'm out of a meeting.

  66. Kev

    Done while still in a meeting.

  67. flow

    who said one can't be producitve in meetings?

  68. edhelas

    Ge0rG nice tshirt :D

  69. edhelas

    We could do something similar with XMPP

  70. edhelas

    something like

  71. edhelas

    <message xmlns="jabber:client" to="juliette@foo.com" type="chat" id="62470128-e587-493e-8592-d7bca532e28f"> <thread>6b3fc7be-0480-461b-8f25-0e7117f5b1d5</thread> <active xmlns="http://jabber.org/protocol/chatstates" /> <body>XMPP is not verbose</body> <request xmlns="urn:xmpp:receipts" /> <markable xmlns="urn:xmpp:chat-markers:0" /> <origin-id xmlns="urn:xmpp:sid:0" id="5ee0e98f-eb38-44ac-b698-19c621b7479d" /> </message>

  72. Zash

    Needs <delay> and <stanza-id>

  73. edhelas

    Yeah sorry :D You can also add the OMEMO stuff as well

  74. Zash

    Also the somewhat redundant full JID in @from

  75. edhelas

    This will only be available on the XXL tshirts to be readable :p

  76. Zash

    And baby sized with <presence/> ?

  77. Kev

    "Couldn't send message: Slixmpp got into trouble." is probably good while voting, right?

  78. Ge0rG

    Kev: do you contest the vote now?

  79. Kev

    I think something has gone quite wrong, as it just told me what my four votes were. After voting on five issues :)

  80. Kev

    I think it really didn't like that I've got two clients running.

  81. Ge0rG

    I have two clients running and never had any trouble

  82. Ge0rG

    maybe it's about *which* clients you are running?

  83. Kev

    Did you try starting voting on one, and finishing on the other :)

  84. Ge0rG

    I don't remember. But IIRC memberbot is doing evil resource locking things with the vots

  85. Ge0rG

    I don't remember. But IIRC memberbot is doing evil resource locking things with the votes

  86. Kev

    That's what it seemed, to me.

  87. mathieui

    never had an issue either and I always run two clients (but do not switch in the middle of voting)

  88. theTedd

    Zash, machine-readable compliance suite data: https://dpaste.org/dEaq/slim

  89. theTedd

    I should try to get the badge generator finished (complete with DOAP processing)

  90. Zash

    Oh, I also made a thing for generating almost exactly that

  91. theTedd

    lovely

  92. theTedd

    there are some A|B choices in there

  93. theTedd

    I think it's just BOSH/WebSockets though

  94. Zash

    gui, tui?

  95. theTedd

    also that

  96. theTedd

    avatars isn't a requirement for text-only clients

  97. Zash

    https://cerdale.zash.se/upload/eQVYwXp3PqMC47-L/xep-0443.json

  98. Zash

    tell poezio

  99. theTedd

    requirement != restriction

  100. Zash

    requirements ≠ implementation ≠ deployment

  101. emus

    Hi, I know this is a religious question (no troll): But when one wants to if a client runs on Unix... can I just say Linux? 😅️

  102. Zash

    "Do you mean *nix or UNIX®?"

  103. emus

    https://en.wikipedia.org/wiki/Unix

  104. Zash

    > when one wants to if a accidentally a word?

  105. emus

    Okay, doesnt matter really

  106. emus

    The XMPP Newsletter for November 2020 is out! This is the last newsletter for this year! Thanks to everyone contributing! Read about an important circumstance regarding certificates to all parties involved in XMPP! Also updates for several clients and servers! https://xmpp.org/2020/11/newsletter-11-november/

  107. wurstsalat

    argh, typo "comming year", my bad

  108. emus

    😩️ - no, really wurstsalat - you did a great job on the XEP section, you are excused!

  109. Zash

    https://github.com/xsf/xmpp.org/pull/850

  110. wurstsalat

    thanks Zash !

  111. Neustradamus

    emus: We are in December.

  112. Zash

    Neustradamus, oh hush

  113. Zash

    It's news from November

  114. Neustradamus

    Bad timing

  115. arc

    https://fosdem.org/2021/schedule/track/real_time_communications/

  116. arc

    What're we doing with this?

  117. Seve

    Neustradamus: let us know if you can read the future

  118. arc

    Shh. He can.

  119. arc

    But he can only write about it in the perspective of a 16th century astrologer

  120. emus

    Neustradamus, we are happy for new contributors and reviewers to reduce time on drafting and reviewing.

  121. Zash

    Could just call it The Newsletter

  122. Zash

    NeXtLetter.

  123. Neustradamus

    emus: With new system, I can not contribute into... Badly.

  124. emus

    ^^ we have "signifcant growth" since this year (seeing email stats). I guess most subcribers are happy 😊️ and also from the personal feedback I receive

  125. Neustradamus

    Draft problem

  126. emus

    Why you cannot?

  127. Zash

    emus: Hm, if it's published just before the end of $month, with a Call To Action™ at the end of "did we miss something from tomorrow? tell us in the comments/repliy to the tweet/whaever"...

  128. emus

    zash, I dont understand what you mean?

  129. Zash

    Cover november-01 to 28, publish on 29, ask people to reply with the cool thing that wasn't in the newsletter in order to generate more noise. Not entirely serious.

  130. Zash

    and also make sure cool thing happens on the 29 that people can reply with.

  131. Zash

    Anyways, don't listen to me, I can't into marketing.

  132. emus

    hehe. I personally think it wont really make a change. I introduced the two review phases to get things less pressure on the team and have more time to ensure quality and force everyone to get done in one night (we also dont have the ressources). I think many people read it rather like a summary of the month, or not as hard into the XMPP development as most here are. I think this request comes from a very different perspective than most readers.

  133. emus

    For me that is mostly a question of ressources. If I need to squash things together, I cannot do that usually in one evening alone

  134. emus

    and also I dont want to do this alone

  135. wurstsalat

    > For me that is mostly a question of ressources. If I need to squash things together, I cannot do that usually in one evening alone +1 I'm happy with how it works at the moment

  136. Neustradamus

    Problems in newsletter links, examples: - https://xmpp.org/2020/11/newsletter-11-november/ (December, 09, 2020) - https://xmpp.org/2020/10/newsletter-10-october/ (November, 05, 2020) - https://xmpp.org/2020/09/newsletter-09-september/ (October, 06, 2020) - https://xmpp.org/2020/08/newsletter-08-august/ (August, 08, 2020) - https://xmpp.org/2020/08/newsletter-06-august/ (August, 06, 2020) - https://xmpp.org/2020/07/newsletter-01-july/ (July, 01, 2020) - https://xmpp.org/2020/06/newsletter/ (June, 09, 2020) - https://xmpp.org/2020/05/newsletter/ (May, 07, 2020) - https://xmpp.org/2020/04/everyone-go-for-decentralisation-03-apr-2020 (April, 03, 2020) - https://xmpp.org/2020/02/newsletter-04-february/ (February, 04, 2020) - ... Link problems like https://github.com/xsf/xmpp.org/issues/638

  137. Neustradamus

    Really time to solve problem.

  138. Neustradamus

    Really time to solve problems.

  139. emus

    Yes, and I will go with what the contributors can manage currently

  140. emus

    neustradamus - what is your exact problem with this?

  141. emus

    I see the links, but what is the issue you have=

  142. emus

    ?

  143. Neustradamus

    Look links, date

  144. Neustradamus

    https://github.com/xsf/xmpp.org/issues/638 it is not solved yet.

  145. emus

    Okay, I see, but lets be honest I is too old to fix on that. but what is it with the other links?

  146. emus

    And even more imporant, what is preventing you from contributing to the Newsletter?

  147. Zash

    Cool URLs don't change.

  148. Neustradamus

    February: https://xmpp.org/2020/02/newsletter-04-february/ -> https://xmpp.org/2020/02/newsletter April: https://xmpp.org/2020/04/everyone-go-for-decentralisation-03-apr-2020 -> https://xmpp.org/2020/04/newsletter May: https://xmpp.org/2020/05/newsletter/ June: https://xmpp.org/2020/06/newsletter/ July: https://xmpp.org/2020/07/newsletter-01-july/ -> https://xmpp.org/2020/07/newsletter August Part 1: https://xmpp.org/2020/08/newsletter-06-august/ -> https://xmpp.org/2020/08/newsletter-1 August Part 2: https://xmpp.org/2020/08/newsletter-08-august/ -> https://xmpp.org/2020/08/newsletter-2 October: https://xmpp.org/2020/09/newsletter-09-september/ -> https://xmpp.org/2020/10/newsletter November: https://xmpp.org/2020/10/newsletter-10-october/ -> https://xmpp.org/2020/11/newsletter December: https://xmpp.org/2020/11/newsletter-11-november/ -> https://xmpp.org/2020/12/newsletter

  149. emus

    Neustradamus, I dont see why we need to change the links now. I personally lag the knowledge for this. I can offer you the following, if you want to commit anything to the next release in February 2021 you join the MUC and if you write up a news you have you can post it there and we can commit that to the next draft. However, the PR your self should work, we always provide a direct link from now on. I see you already have a Github account. So that should work

  150. Neustradamus

    Do not forget that I have been the last Communication team member. I have contributed several years before the new draft system on GitHub which has a lot of problems (bad link names, bad publication dates) Harmonization needs to be done to solve all problems. The problem is not new and people keep... Strange.

  151. emus

    I am happy for support, but I cannot do that my self 🤷‍♂️️

  152. Neustradamus

    In more when you click on the date of all publications: -> https://xmpp.org/blog.html#

  153. Neustradamus

    It is easy, create a PR with perfect name to all files.

  154. emus

    I dont see the problem with creating a PR right now? Anyway, Im out for today

  155. Neustradamus

    You can see: https://github.com/xsf/xmpp.org/issues/638 -> https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2018/ -> https://xmpp.org/2019/01/newsletter It will be remove the bad link problem "January 2018" in "January 2019"

  156. Neustradamus

    Thanks in advance.

  157. Neustradamus

    Example of Gajim, no problem: - https://gajim.org/post/2020-11-27-development-news-november/ - https://gajim.org/post/2020-10-28-development-news-october/ - https://gajim.org/post/2020-09-27-development-news-september/ - https://gajim.org/post/2020-08-30-development-news-august/ - https://gajim.org/post/2020-07-26-development-news-july/ - https://gajim.org/post/2020-06-28-development-news-june/ - https://gajim.org/post/2020-05-26-development-news-may/ - https://gajim.org/post/2020-04-28-development-news-april/ - https://gajim.org/post/2020-03-30-development-news-march/ - https://gajim.org/post/2020-02-26-development-news-february/ - https://gajim.org/post/2020-01-27-development-news-january/

  158. deuill

    Thanks for working on the newsletter, it's genuinely something I look forward to every month.