XSF Discussion - 2021-08-25

  1. me9

    'ello! I have a question about a XEP which I guess exists. What XEP defines how a 'raw' (?) text message should look like and what metadata it contains for the clients to interpret and display it right to the user? I'd like to see how it's built for a second, later question.

  2. Sam

    me9: welcome! The body of messages is actually defined by the core RFCs, not in an XEP. However, that's just text (no special formatting or anything). Metadata and formatting is defined by many different XEPs depending on the feature you want.

  3. Sam

    (the IETF maintains the core of XMPP in a handful of RFCs, the XSF maintains any extensions to the core protocol in XEPs)

  4. Sam

    Is there something specific you're looking to learn how to do? Maybe I can point you at a more concrete document

  5. me9

    I'm looking for what metadata there is for time and date.

  6. flow

    me9 like https://xmpp.org/extensions/xep-0203.html ?

  7. me9


  8. me9

    I don't understand what it does. But I can tell/show you what I was thinking about.

  9. Sam

    Sure, that might help

  10. Holger

    me9: As the XEP title suggests, the idea is to only add <delay/> timestamps in case the message was actually delayed for some reason (sender was offline while the message was written, message was stored in MAM/offline spool, ...). The idea is that you can assume instant delivery if no such timestamp is included. (But of course there's no _guarantee_).

  11. Holger

    XMPP's original standard operation was _instant_ messaging ... :-)

  12. me9

    Holger: Aha ok. Well I just meant how date and time look universally before the client shows it right.

  13. me9

    > Holger wrote: > XMPP's original standard operation was _instant_ messaging ... :-) Yeah I get it. That's also interesting.

  14. Holger

    XEPs that add timestamps usually refer to this format: https://xmpp.org/extensions/xep-0082.html

  15. flow

    me9, https://xmpp.org/extensions/xep-0082.html maybe?

  16. Holger

    Holger <-> flow 1:0

  17. me9

    Mhm. Seems right.

  18. me9


  19. me9

    Seems the XEP is talking about the problem someone and me found.

  20. me9

    A bit.

  21. flow

    me9, feel free to elaborate on the problem

  22. me9

    Wait a bit, I want to look at that XEP. It's always so long.. :))

  23. me9

    But maybe you can think about my idea while I'm reading. This is also about the formatting of quotes. There's an issue on one XMPP client (Blabber.im). Blabber normally does this when you quote woth the ontegrated function of quoting: ```[nick] wrote: > [quoted text]``` But the issue wanted to add a date to that. But we figured that only a client adding a date wouldn't be internationally friendly, as when you have people from.different countries and rimezones meeting, they write and display date and time (very) differently. So what we'd need for a date to be added would probably be some kind of XEP which let's the cleitn translate the date and time into the persons local format. Here's what I wrote at the end: https://codeberg.org/kriztan/blabber.im/issues/499#issuecomment-249559

  24. me9

    So this is actually about the text before a quote, which more than one client would have to use for it to be useful and not confusing.

  25. me9

    Maybe the idea is just too fiddly and not useful for many people, I don't know... Just wanted to give a readon to close that issue, really.

  26. me9

    Maybe the idea is just too fiddly and not useful for many people, I don't know... Just wanted to give a readäson to close that issue, really.

  27. me9

    Maybe the idea is just too fiddly and not useful for many people, I don't know... Just wanted to give a reason to close that issue, really.

  28. Zash

    Quotes are currently just plain text prefixed by `>`. There's a XEP or two for referencing earlier messages by id, which would likely make things easier in the long run

  29. wurstsalat

    me9 to takle this problem, you'd need message references/fastening

  30. wurstsalat

    tackle, that is

  31. me9

    > Zash wrote: > Quotes are currently just plain text prefixed by `>`. There's a XEP or two for referencing earlier messages by id, which would likely make things easier in the long run IDs would be very useful, that's true.

  32. me9

    wurstsalat: Is that what Zash meant?

  33. wurstsalat

    yep, didn't see that message

  34. me9


  35. me9

    https://xmpp.org/extensions/xep-0082.html at point 6. Security Considerations: [...] if it's set to the local time of a user, and thus concerns users' *privcacy*. To avoid this issue developers are advised to [...] :D

  36. me9

    https://xmpp.org/extensions/xep-0082.html at point 6. Security Considerations: > [...] if it's set to the local time of a user, and thus concerns users' *privcacy*. To avoid this issue developers are advised to [...] :D

  37. jonas’

    me9, feel free to PR :) -> https://github.com/xsf/xeps/

  38. me9

    jonas’: A PR for removing one character in that giant text? Okay.

  39. Zash

    That should make review easy

  40. jonas’

    me9, what else? :)

  41. jonas’

    can't give you +w on the repository and I can't do it myself right now

  42. me9

    Dunno. There was also that editor JID for errata. But I'll try.

  43. jonas’

    editor ... JID?

  44. me9


  45. flow

    I think there is only a editor mail address

  46. jonas’

    that's no JID

  47. jonas’

    what flow says

  48. me9

    Uh. Okay. :D

  49. jonas’

    it would end up with me making a PR though ;)

  50. jonas’

    (or the equivalent of...)

  51. me9

    Okay I'll do it jonas’ xD

  52. me9

    One freaky character.

  53. me9


  54. jonas’

    maybe you can find something else to fix in that document, too :)

  55. flow

    an improvement is an improvement, no matter how small it is

  56. jonas’


  57. jonas’

    many people probably just skimmed past that and possibly thought "ugh, they can't even edit their documents properly!!kk"

  58. me9


  59. me9

    So my quote-date-stuff idea wasn't very good, I guess?

  60. jonas’

    if only we had proper markup instead of magic characters stuffed in <body/>

  61. me9

    Do you always use 'an' before 'X...' words? Or just when the long version begins with a vowel?

  62. Holger

    me9: You use it when 'X' is the first letter of an abbreviation, because it's about pronounciation, not spelling. "An (e)XMPP client."

  63. jonas’

    an exx emm pee pee

  64. Holger

    Holger <-> jonas’ 1:0

  65. me9

    Ah, because one says ex for x?

  66. jonas’

    me9, yes

  67. jonas’

    Holger, :P

  68. me9

    Holger: You already have two points. What now? You won?

  69. Holger

    I'd say so, waiting for presents now.

  70. jonas’

    <presents type="unavailable"/>

  71. wurstsalat

    thanks for the giggles (again)

  72. me9

    Ha! I found one more inconsistency in 0082. XD

  73. me9

    Did somebody already point out the following little UI issues, which seems to appear with every single XEP? (Or is it just my browser being weird?)

  74. me9


  75. Zash

    Looks fine here

  76. jonas’

    probably an edge-case with that very narrow screen

  77. jonas’

    feel free to open an issue with that screenshot, I think there can be something done about it

  78. Zash

    Looked fine on every screen width I tried

  79. Zash

    Ctrl-Shift-M in Firefox and then resized the viewport, could not reproduce that overlap issue.

  80. mdosch

    Looks even good on mobile with fennec here.

  81. mdosch

    > probably an edge-case with that very narrow screen But at the JabberID the width is more than enough. Maybe some browser doing weird things withs padding or how it was called again.

  82. me9

    > jonas’ wrote: > probably an edge-case with that very narrow screen I zoomed in and cut off something, it looks different.

  83. me9

    The photo is from Ungoogled Chromium on my phone but with the desktop view. Both desktop and mobile view do it in Ungoogled Chromium. But with Fennec, it's perfectly fine.

  84. wurstsalat

    Edge case it is then

  85. jonas’

    wurstsalat, no they said Chromium, not Edge *scnr*

  86. wurstsalat


  87. me9


  88. me9

    My little PR should be good and deployed now by the way.

  89. jonas’

    me9, next editor work window is next tuesday, so don't hold your breath :)

  90. me9

    jonas’: Fine 👍

  91. me9

    Do I have to do that CLA thing?

  92. wurstsalat

    MattJ, jonas’, do you have plans/ideas on how to proceed with https://github.com/xsf/xmpp.org/pull/953 ? should I rebase it peridically? anything I can do to help reviewing?

  93. jonas’

    me9, I don't think that this contribution is really copyrightable, so it would've been OK without I guess

  94. me9

    jonas’: I did it anyway. It remember that for the rest, right?

  95. me9

    jonas’: I did it anyway. It remembers that for the rest, right?

  96. jonas’

    it does

  97. me9


  98. Sam

    I am writing up a list of open questions about ad-hoc commands because this entire XEP is confusing to me. I will submit a patch to try and clarify any of them at a later date, please consider adding your own questions to the document. Thanks. https://pad.disroot.org/p/adhocquestions

  99. jonas’

    better don't look at what "execute" means.

  100. Sam

    Oh yah, that's one I should add. All it had to say was "also there's a default action" and it would make sense, but instead it's got tons of text about when "execute" means something else or means itself and what?

  101. Zash

    no, no, noooooo

  102. jonas’

    I said you should *not* look at it :P

  103. Sam

    Anyways, I'm sick of reading and re-reading this and having dozens of bugs due to misreading the spec (no idea if it's me or others misreading the spec, but I'm doing whatever I see other things doing) so I'm going to at least try to put together a PR if I can get it all straight in my head. First step is listing the questions.

  104. flow

    Sam you may want to look at (and add to) https://wiki.xmpp.org/web/XEP-Remarks/XEP-0050:Ad-Hoc_Commands

  105. Sam

    good to know; thanks

  106. MattJ

    wurstsalat, next steps - I just want to give it a quick review, merge and deploy. My usual time allocated to XSF infrastructure was yesterday, but it got taken over by other stuff. I'll get to it soon!

  107. wurstsalat

    MattJ: thanks :) I'll rebase next monday then

  108. mjk

    It has come to my attention that XEP-0363 (http upload) requires a particular kind of transport security (TLS), with seemingly no regard for things like .onion domains. This makes onion-service admins either to jump through hoops to enable a redundant and useless (no cert verification performed by clients) security layer, or to go against the spec, allowing http://abcdef.onion up-/download. Would it be too late to change the xep to require some unspecified transport security form, only referring to TLS and onion services in a note?

  109. mjk

    I should add that, in my observation, many onion services go against the spec here

  110. Zash

    Related observation: Things that do the aesgcm:// thing, they can't deal with http://

  111. mjk


  112. Zash

    Luckily that's not a XEP so not our problem! YOLO GLHF /me hides

  113. mjk

    Hm? It's been a xep since december, if I'm not mistaken :p

  114. Zash

    Has it?

  115. mjk

    Let me look up the number

  116. Zash

    Oh, historical

  117. Zash


  118. Zash

    `/correct s/XEP/Standards Track XEP/` then

  119. mjk

    Okay then :l

  120. mjk

    Okay then :)

  121. mjk

    I hope for future orthogonalization of file encryption (aes gcm) and transport protocols (http over tls, http over onion...)

  122. Zash

    Something something reference to earlier talk about things being rushed into production ahead of standardization and causing awkwardness.

  123. mjk

    Something like `omemo:http://abcdef.onion/path/to/file#foo`

  124. Zash

    I've seen e.g. git+https:// elsewhere. Some MIME thing could also have worked

  125. Zash

    `application/some-encrypted-container` 🤷️

  126. mjk

    Yeah, `aesgcm+https` would have worked too

  127. mjk

    Yeah, `aesgcm+https` scheme would have worked too

  128. Zash

    inb4 `aesgcm+tftp://`

  129. mjk

    We're getting dangerously bikesheddy

  130. Zash

    Nah, I'm just sprinting ahead on tangents

  131. mjk


  132. mjk

    Going back to 0363, clients generally seem to allow plain http upload too, with a notable exception of Gajim (if I'm reading the code correctly). But, e.g., this <https://github.com/dino/dino/pull/1098> Dino PR, if accepted as is, would break the, admittedly non-standard, functionality

  133. Zash

    There was a question somewhere earlier about whether file transfer used UDP or TCP. Recently there's been deployment of TURN UDP proxies. Soooo could you do say TFTP over TURN? That'd be funny.

  134. Zash

    Maybe the whole thing will break down and everyone will move towards Jingle File Transfer? (plz do)

  135. mdosch

    Would it be possible to ditch http and jingle it to the server and the server transfers it over jingle to other clients requesting the file?

  136. Zash

    JFT can use HTTP Upload for transport per some XEP somewhere, and OMEMO for security, so in theory it should be possible to combine those properties and not have to use the assgcm:// hack

  137. mjk

    Nah, SIMS FTW

  138. Zash

    mdosch, why not? "over jingle" can mean a lot of things tho

  139. Zash

    mjk, SIMS being something of a combination of Jingle File Transfer and Jingle Message Initialization...

  140. mjk

    Ok nevermind me

  141. Zash

    And then there's XEP-0447 and 448...

  142. mjk

    Jm2c regarding 0363

  143. Zash

    A/B fight plz