XSF Discussion - 2019-01-29

  1. moparisthebest

    xmpp is suddenly looking alot better than facetime to some apple users now I bet :D

  2. edhelas

    moparisthebest how so ?

  3. edhelas


  4. edhelas

    ah :p

  5. jonas’


  6. edhelas

    took 10 days to turn the Facetime switch of

  7. edhelas

    > Weirder yet: if the recipient presses the volume down button or the power button to try to silence or dismiss the call, their camera turns on as well. Though the recipient’s phone display continues showing the incoming call screen, their microphone/camera are streaming.

  8. jonas’


  9. edhelas

    they got some pretty weird bahavior going on in their app to have that

  10. jonas’


  11. Guus

    (doesn't facetime use XMPP?)

  12. edhelas

    Guus in a way, everything in IM/VoiP is based on XMPP with a bit or a lot of adaptations :p

  13. Guus

    Yes, we can declare victory.

  14. jonas’


  15. jonas’


  16. Guus

    Also, 2019 is going to be the year of the linux desktop.

  17. Ge0rG

    Guus: the twentieth consecutive one!

  18. Guus

    See? Winning! #tigerblood

  19. Guus

    See? Winning! #tigerblood

  20. Holger

    Is it known/expected that the links to Schemas in XEPs lead to a 404?

  21. Holger

    E.g. 0313 sends me to <http://www.xmpp.org/schemas/archive-management.xsd>.

  22. jonas’

    Holger, known

  23. Holger


  24. mtavares

    Ge0rG, I've been using linux a my desktop since 1996 (almost exclusive, just a drop into win or macos every now and then), so it's more like 23th consecutive one.

  25. goffi

    Hey, is there any reason why MAM is not activated on this room?

  26. Ge0rG

    missing mod_mac_mum?

  27. Maranda

    Mac Mum 🎑✨

  28. Ge0rG

    Maranda: or was it mod_mum_mac?

  29. Maranda

    Not sure

  30. Ge0rG

    I remember it being related to a low-income overweight burger-eating family.

  31. Maranda

    Ge0rG, mum mac apparently

  32. Ge0rG

    maybe it was also a MILFy cam_mum.

  33. Ge0rG

    This only reinforces my wish to write a blog post: "Prosody Community Modules: The Good, the Bad, and the Ugly"

  34. jonas’


  35. Ge0rG

    jonas’: indeed.

  36. Maranda

    🤔 I guess the query should be directed to Zash for a more proper naming convention on that

  37. Maranda

    Naming convention discussion rather

  38. Ge0rG

    Maranda: the problem is that depending on prosody version, there are modules in core or not.

  39. Ge0rG

    and the core modules implement a feature set that is overlapping but neither a subset nor a superset of the community module

  40. Ge0rG

    I think I need to draw plenty of Venn diagrams.

  41. Maranda

    Not sure I include all modules.... Not having contributed ones

  42. Maranda

    And since my MUC MAM relies on mod_muc_log guess what... It's called mod_muc_log_mam 🙃🤭

  43. Ge0rG

    Just shuffle the letters.

  44. Ge0rG

    Maranda: do you know the Kennifyer?

  45. Maranda

    Like wise the http logs are called mod_muc_log_http

  46. Maranda


  47. Ge0rG

    Maranda: https://www.namesuppressed.com/kenny/

  48. Maranda


  49. Ge0rG


  50. Maranda


  51. Guus

    So, I did something silly and slapped on xep-0359 to any stanza that passed. Doesn't work to well for IQ's, which can have only one direct child.

  52. Ge0rG


  53. Guus

    what's the best approach here? Only Messages?

  54. Ge0rG

    not doing it at all in this manner?

  55. Guus

    Ge0rG elaborate, please

  56. Ge0rG

    I'm not sure it is a good idea to slap 0359 on *all* messages that you pass. You should only do that for messages that end up in your MAM archive

  57. Guus

    what makes you wonder if it's a good idea?

  58. dwd

    Ge0rG, I think you *have* to place a stanza-id on anything you archive, with mam:2. Whether you *also* place them on other messages is not specified.

  59. dwd

    Ge0rG, But a client might ask for "all messages after this one", so if you can't service that from MAM because you're unaware of the stanza-id referenced, that could be a problem.

  60. Ge0rG

    dwd: that's exactly what I was thinking. CC Guus

  61. dwd

    Also, there's a nagging concern that if you're a little over-zealous in archiving messages, you can archive the MAM result stanzas, and a query for "every message after this point" can lead you into some interestingly endless interactions.

  62. Zash


  63. Zash

    Those would be contained inside forwarded-containers, right?

  64. Ge0rG

    Zash: it's not *forbidden* to archive those.

  65. Ge0rG

    I'm not sure whether it was mentioned before, but it would be nice to have consistent rules for MAM and Carbons and ephemeral vs. persistent messages.

  66. Zash


  67. Zash

    Something for the summit perhaps?

  68. Ge0rG

    For the 2018 Summit.

  69. Zash

    You know all these issues stand still while there isn't an ongoing summit :)

  70. Ge0rG

    I'd like to have Summit discuss the mess of message IDs, and which ones to use when when referencing messages.

  71. Ge0rG

    Zash: because nobody reads the ML?

  72. Zash

    Nobody reads anything, ever :)

  73. Guus

    an awesome tagline for a chat client.

  74. dwd

    Ge0rG, Might it be worth looking at XEP-0226 again and seeing if it makes sense to stipulate ephemerality in terms of message profiles?

  75. Ge0rG

    dwd: interesting idea, but I fear it will lead into an endless list of exceptions and exceptions-from-exceptions

  76. Ge0rG

    dwd: essentially you'd end up codifying the existing rules with a different name

  77. dwd

    Ge0rG, Well, the existing rules are "apply common sense".

  78. Ge0rG

    dwd: that doesn't work

  79. Ge0rG

    It's a good way to delegate the hard work from people who should know it to random server developers.

  80. dwd

    Ge0rG, I think we can approach this by saying "these elements are metadata - ignore them for the purposes of MAM/Carbons/etc", and "these elements mean it's worth doing something with".

  81. dwd

    Ge0rG, In general, server developers are not random. Certainly not cryptogrphically so.

  82. Ge0rG

    dwd: ah, so you are into tagging stanza elements and using those as signal/noise indicators?

  83. Guus

    I'd not consider myself to be a cryptographically strong random, but more random like https://xkcd.com/221/

  84. dwd

    Ge0rG, I'm into exploring the idea, certainly. That's the approach of XEP-0226 - to use the elements as contents (and, in this case, ban certain combinations).

  85. dwd

    Ge0rG, Also, same, but in my case with a loaded dice.

  86. Ge0rG

    dwd: what you propose sounds like a formal notion (with explicitly named elements) of https://op-co.de/tmp/xep-0280.html#which-messages

  87. Ge0rG

    dwd: while I was more interested in changing the semantics of either message type, to-JID-fullness or both, to encode the ephemerality. Hence IM-NG

  88. dwd

    I think that's a waste of effort. It's a boil-the-ocean forklift upgrade.

  89. dwd

    I mean, those are great fun, but they've repeatedly failed.

  90. Ge0rG

    dwd: I'm not convinced it actually is.

  91. Ge0rG

    dwd: my ideas are 90% compliant with 6121 rules

  92. Ge0rG

    But yeah, I have ambitious goals.

  93. Ge0rG

    I need to restrain myself. Can we please get Summit to at least figure out which of the (only?) three message identifiers are to be used when?

  94. dwd

    Ambition is laudable, but we need a touch of pragmatism too.

  95. Zash


  96. dwd

    Ge0rG, Three? Origin, Stanza-id, and id attribute?

  97. Ge0rG

    dwd: yes

  98. dwd

    Zash, Council shot down hints. I didn't agree, and still find it very useful.

  99. Ge0rG

    IIRC, Council's problem was that the XEP format is not suitable for Hints.

  100. Ge0rG

    Maybe there should be a Registry of Hints instead?

  101. dwd

    Ge0rG, Yes indeed. I think if origin isn't the same as the id attribute something has borkened, and stanza-id is for ids applied by intermediates (and used when querying those intermediates).

  102. dwd

    Ge0rG, I thought there were multiple arguments against hints, like servers might ignore them and things.

  103. Ge0rG

    dwd: but which one do you use in 0184 ACKs? Which one in 0333? Which one in proto-XEP-emoji-Reactions?

  104. Ge0rG

    dwd: yeah, those too

  105. dwd

    Ge0rG, The first two are specified as the stanza's id attribute, aren't they?

  106. Ge0rG

    dwd: that doesn't mean it's right, just that they predate 0359.

  107. Ge0rG

    @id is optional and scoped on the c2s stream, so there are no uniqueness guarantees. origin-id can be forged by a malicious client, and stanza-id isn't available until the message was reflected to you, which is "never" in the default case.

  108. dwd

    Ge0rG, Let me rephrase - I think origin-id is an unfortunate workaround for broken behaviour, some of which I even contributed to.

  109. Ge0rG

    dwd: okay okay. I'm writing up the long version to standards@

  110. dwd

    Ge0rG, Rather than ossify it, I'd rather treat it as the workaround it is, and work to remove the requirement for its existence.

  111. Ge0rG

    dwd: there is a principal problem with attager-generated-IDs scoped to a MUC (as opposed to a direct chat)

  112. Ge0rG

    dwd: there is a principal problem with attacker-generated-IDs scoped to a MUC (as opposed to a direct chat)

  113. dwd

    Ge0rG, Does origin-id help with that at all?

  114. Ge0rG

    dwd: no

  115. Ge0rG

    it merely adds to the confusion

  116. dwd

    Ge0rG, Right. Of course, if MUCs *don't* preserve ids, then the reflection would ... Oh.

  117. Ge0rG

    dwd: oh?

  118. dwd

    Ge0rG, That is, the attack is only even vaguely possible because an attacker has control of the id. If the MUC re-issues a new id, then it's largely moot.

  119. Ge0rG

    dwd: yes, you have replaced a reference authentication problem with a race condition problem.

  120. flow

    Is there a canonical XMPP logo somewhere?

  121. Zash


  122. jonas’

    flow, any of xmpp*.png in https://github.com/xsf/xmpp.org/tree/master/content/images/logos ?

  123. Zash

    No .svg?

  124. jonas’


  125. jonas’

    haven’t found it yet

  126. Zash

    `$ locate xmpp.svg`

  127. jonas’

    flow, https://github.com/xsf/xmpp.org/pull/363 Guus probably knows where the SVG version is

  128. flow

    jonas’, thanks, png is fine

  129. jonas’

    ah, got it

  130. jonas’


  131. Zash

    I found ~/src/xmpp/images/xmpp.svg

  132. Zash


  133. ralphm

    That's the old one

  134. ralphm

    The new one, as linked by jonas’ has the little orange thingy crossover moved to under

  135. Zash

    This was out of a very old repo, I think from before it was split into multiple

  136. Zash

    2015, not /that/ old

  137. ralphm

    Yes, this was changed more recently

  138. ralphm

    in sept 2017

  139. ralphm

    Interestingly, Guus apparently removed the old version with the XMPP letters included

  140. Guus

    use the logo on the top-left corner of the website

  141. Guus

    that links to https://xmpp.org/theme/images/xmpp-logo.svg

  142. ralphm

    Guus: that's without the XMPP letters, hence my comment

  143. Guus

    ah, sorry, _without_

  144. Guus

    I'm scrambling today, not paying enough attention

  145. ralphm

    No worries

  146. ralphm

    I have a proper one, hold on

  147. Guus

    Unsure where that logo with letters is.

  148. Guus

    If you need to find the font: it's the same font as was used for HAL in 2001: Space Odyssey

  149. Zash

    I just noticed that the middle lines aren't completely smooth, they have sharp edges near the bottom. Now I can't un-see it :(

  150. Guus

    I always forget the font name, but not that reference. 😉

  151. ralphm

    The font is called OPTIEdgar Bold Extended

  152. ralphm


  153. ralphm

    Zash: ^

  154. Zash


  155. ralphm


  156. Guus


  157. Guus

    (I would've done the same 😛 )

  158. Guus

    maybe I'll cover myself in stickers... 😉

  159. Ge0rG

    I wish I had a Jabber® hoodie.

  160. ralphm

    Ge0rG: I'm sure you like these, too.

  161. Guus

    Thank you for using a reference, Ge0rG

  162. Guus


  163. Guus

    speaking of which - did Peter get back to you?

  164. Ge0rG

    Guus: not yet

  165. Ge0rG

    > Will reply tonight or tomorrow! -- Thu, 24 Jan 2019

  166. Ge0rG

    Guus: should I ping him?

  167. Ge0rG

    dwd: I'd like to conclude the 0410 LC with a Council vote, but there was an intersting issue brought up and not yet resolved: should there be an _additional_ error condition that says something like "you are not a participant to this MUC"?

  168. jonas’

    Ge0rG, I think we need to have a second round of LC after you updated the XEP

  169. Guus

    Ge0rG I just pinged Peter

  170. Guus

    wraaaagghhh why can't I type on three keyboards at the same time.

  171. Ge0rG

    Guus: thanks very much

  172. Ge0rG

    jonas’: but why?

  173. jonas’

    ah, no

  174. jonas’

    it is indeed a council vote which is the next step

  175. jonas’

    you do updates, council votes whether to decide on it now or have another LC

  176. jonas’

    XEP-0001, §7 > Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the Approving Body for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the Approving Body, extend the Last Call or issue a new Last Call if the XEP requires further discussion.

  177. Ge0rG

    jonas’: so the options are now: - merge the PR and let the Council vote on Proposal - try to gain more feedback and resolve open questions

  178. jonas’


  179. jonas’

    I’m too full of cold slime to figure that out at the moment

  180. Ge0rG

    my gut feeling is that there are two issues worth delaying the Proposal: the additional error condition; and the correct baseline IQ response for a non-participant

  181. jonas’


  182. jonas’

    I suggest that you make an update to the PR which incorporates what you’d like them to be and we can discuss that tomorrow and decide whether we find it okay enough or put it into another LC?

  183. dwd

    Ge0rG, "occupant", but yeah.

  184. dwd needs to do the agenda in a bit, and will try to remember to put it on.

  185. Ge0rG

    Participant: An occupant who does not have admin status

  186. Ge0rG


  187. dwd

    I thought a particpant had voice, as well.

  188. Ge0rG

    dwd: I don't feel ready for Proposing yet.

  189. jonas’

    the key question is, do you have a ring yet?

  190. Ge0rG

    jonas’: a jingle ring or a token ring?

  191. jonas’

    a facetime ring, maybe

  192. Ge0rG

    one ring to spy upon them

  193. jonas’


  194. Ge0rG

    > The <error/> element: > - MUST contain a defined condition element. > - MAY contain a <text/> child element ... > - MAY contain a child element for an application-specific error condition Is it allowed to have multiple application-specific error conditions? Multiple defined condition elements?

  195. jonas’

    <xs:element name='error'> <xs:complexType> <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'> <xs:group ref='err:stanzaErrorGroup'/> <xs:element ref='err:text' minOccurs='0'/> </xs:sequence> <xs:attribute name='by' type='xs:string' use='optional'/> <xs:attribute name='type' use='required'> <xs:simpleType> <xs:restriction base='xs:NMTOKEN'> <xs:enumeration value='auth'/> <xs:enumeration value='cancel'/> <xs:enumeration value='continue'/> <xs:enumeration value='modify'/> <xs:enumeration value='wait'/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element>

  196. jonas’

    can someone parse that?

  197. Ge0rG

    jonas’: `<xs:group ref='err:stanzaErrorGroup'/>` is probably the relevant part

  198. jonas’

    that’s just an enumeration of the different error types

  199. jonas’

    the defined error types that is

  200. jonas’

    a single xs:choice thing with all the elements in it

  201. jonas’

    doesn’t specify/handle application defined conditions

  202. Zash

    so it needs an optional any?

  203. Zash

    Or is that implicitly allowed?

  204. jonas’

    I don’t know

  205. Ge0rG

    I fear I just trolled the standards@ ML, a little.

  206. Ge0rG

    Time to walk myself out.

  207. jonas’

    good luck

  208. Ge0rG

    Okay, so it looks like I identified the cause of massive MUC message duplication in yaxim.

  209. Ge0rG

    Anybody wants to guess?

  210. jonas’

    SQL index something?

  211. Ge0rG

    jonas’: it's my favorite MUC protocol feature.

  212. Ge0rG

    yrtnpl tebhcpung cebgbpby

  213. jonas’

    oh dear

  214. Ge0rG

    It looks like MultiUserChat.isJoined() is not updated on connection re-auth.

  215. Ge0rG &

  216. edhelas


  217. moparisthebest

    What would be the right way to officially suggest that all clients/servers omit TLS authentication for any .onion domain?

  218. moparisthebest

    A XEP or?

  219. MattJ

    A XEP, informational I guess

  220. MattJ

    "Best Practices for using XMPP with Tor"