XMPP Council - 2019-02-27

  1. jonas’

    I just realized I have a meeting at 14:30Z. depending on the duration (which isn’t clearly defined and may range from 15min to 90min), I won’t be able to be on time.

  2. zinid

    jonas’, seems like there is no agenda anyway

  3. jonas’

    okay, meeting’s over, depending on traffic I’m either on time or ~10min late

  4. jonas’

    okay, meeting’s over, depending on traffic I’m somewhere between on time or ~10min late

  5. Ge0rG

    Good morning everyone!

  6. jonas’


  7. Link Mauve

    ’morning, I’m here. o/

  8. dwd

    I'm here too.

  9. jonas’

    we have TrueDWD

  10. dwd

    In the interests of security, I suggest we conduct the meeting in Double-ROT13.

  11. jonas’

    <proceed xmlns="urn:dwd:xmpp:double-rot13"/>

  12. dwd

    OK, let's go.

  13. Ge0rG


  14. dwd

    1) Role Call?

  15. jonas’

  16. Ge0rG

  17. Ge0rG is very unprepared.

  18. Link Mauve


  19. Link Mauve same.

  20. dwd

    Kev said he'd be missing this one, didn't he?

  21. jonas’


  22. dwd


  23. dwd

    2) Agenda Bashing

  24. dwd

    So, I failed to get an agenda together, but I think we have some ProtoXEPs or something don't we?

  25. jonas’

    no protoxeps I’m aware of

  26. Link Mauve


  27. jonas’

    didn’t we discuss those already?

  28. Ge0rG

    More than the three ones that expired(?)?

  29. Link Mauve

    We mostly already voted on them though, this is just a reminder that on list people should vote.

  30. jonas’

    that’s true

  31. Link Mauve

    Ge0rG, two for us, and one for board.

  32. jonas’

    dwd, there are a bunch of [Needs Council] PRs though

  33. jonas’

    this one for example: https://github.com/xsf/xeps/pull/760

  34. dwd

    Oh, lots.

  35. jonas’

    yeah, many of them have already started votes

  36. zinid

    I think today is the last day to vote on my xeps BTW

  37. jonas’

    zinid, yes

  38. zinid

    according to Tedd sterr

  39. dwd

    zinid, Yes, sorry for the delay on my part.

  40. dwd

    jonas’, So I see #752, #758, and #760 to vote on?

  41. jonas’


  42. jonas’

    I lost track, too

  43. Link Mauve

    #746 and #747 too.

  44. jonas’

    but the numbers sound realistic

  45. jonas’

    Link Mauve, we started votes on those already

  46. Link Mauve


  47. Ge0rG

    #752 was vetoed already.

  48. dwd

    Link Mauve, Both those have been voted on and passed/expired at this point.

  49. Ge0rG

    By Dave and me.

  50. dwd

    Ge0rG, Good spot, it has indeed.

  51. dwd

    So #758 and #760.

  52. dwd

    So with that:

  53. dwd

    3) Items for a Vote:

  54. dwd

    a) https://github.com/xsf/xeps/pull/758

  55. dwd

    (XEP-0060: Expose pubsub#access_model and pubsub#publish_model)

  56. jonas’

    +1 I think

  57. Link Mauve

    I’m +1 on this one, it does enable very valid usecases.

  58. jonas’

    AFAICT this is still optional so existing services aren’t suddenly non-compliant

  59. Link Mauve


  60. Ge0rG

    It just adds two new fields, without any description?

  61. dwd

    Yes, this looks straightforward and painless. +1.

  62. Link Mauve

    Ge0rG, there is a very short description in the second chunk, in the @label.

  63. dwd

    Ge0rG, No, it updates the registration and includes a short description.

  64. dwd

    Ge0rG, I'd argue the description is long enough given the values involved.

  65. Ge0rG

    The description is non-normative, i.e. there is no requirement to fill the fields with [open, presence, roster, authorize, and whitelist] - right?

  66. Ge0rG

    so pubsub#access_model=dwd would be valid.

  67. dwd

    Ge0rG, Do you think implementors need to be told that?

  68. dwd

    Ge0rG, I mean, you could argue it has to be a valid access mode, but people have invented new ones of those before.

  69. Link Mauve


  70. dwd

    Link Mauve, I wasn't going to name names.

  71. dwd

    Link Mauve, But yes.

  72. Link Mauve

    Heh. :)

  73. Ge0rG

    dwd: I'm not sure. I'm seeing a particular XMPP client library that will throw class cast exceptions on unknown field values.

  74. dwd

    Ge0rG, Really? That seems like a bug.

  75. jonas’

    Ge0rG, that’s the libraries problem.

  76. Ge0rG

    anyway, just trying to understand this.

  77. Link Mauve

    Ge0rG, I know more than one, is this much of an issue?

  78. Ge0rG


  79. dwd


  80. dwd

    b) https://github.com/xsf/xeps/pull/760

  81. dwd

    (XEP-0045: Add avatar support using XEP-0084)

  82. Link Mauve

    I’m obviously +1, ask me anything.

  83. Ge0rG

    (re #758) I'd be 1 happier if it would explicitly reference what values are allowed.

  84. Ge0rG

    is 0084 one of the Avatar XEPs that we want to retain long-term?

  85. zinid

    wut? another avatar method for muc?

  86. jonas’

    Ge0rG, I’m firmly against that. It could state explicitly that it’s about the access/publish model, but listing the allowed values should be done where that is defined (and given that additional XEPs may easily define new models, I don’t see why that’s valuable to have)

  87. Link Mauve

    Ge0rG, yes, it is this one.

  88. dwd

    Ge0rG, Veto it if you want to require your own happiness.

  89. dwd

    zinid, Avatars for the MUC itself.

  90. Ge0rG

    jonas’: this is why I wrote "reference" and not "list"

  91. Link Mauve

    zinid, the previous council rejected the XEP-0153-based one I proposed, this one is based on a long-term PEP-only solution.

  92. zinid

    dwd: it's already imlemented using vcards

  93. jonas’

    re 760: LGTM on first glance, is there a deployment for that version already?

  94. Link Mauve

    jonas’, NAFAIK.

  95. Link Mauve

    Well, there is a Prosody module that hasn’t been published yet.

  96. zinid


  97. jonas’

    can you just mix mod_profile (or whatever the new vcard<->pubsub conversion module is) on a prosody muc? :>

  98. dwd

    Link Mauve, Isn't this one adding a Pubsub service to MUC rooms?

  99. Link Mauve

    dwd, yes, that’s what it does.

  100. dwd

    zinid, As in directly on the vCard?

  101. dwd

    zinid, Ugh. As in, a vCard directly on the MUC?

  102. zinid

    dwd, yes

  103. zinid

    dwd, ejabberd, conversations, gajim and dino support it already

  104. zinid

    and we're now rolling another one?

  105. Link Mauve

    dwd, https://docs.ejabberd.im/tutorials/muc-vcard/ describes how it works.

  106. zinid

    also, full blown pep node on muc?

  107. dwd

    zinid, Yeah, I hear you.

  108. Link Mauve

    This was what I tried to standardise back in August, but council rejected it with (imo) valid reasons.

  109. jonas’

    Link Mauve, wasn’t the main reason "put it in '45, we don’t want many avatar XEPs"?

  110. jonas’

    so you could’ve technically put the '153 based solution into '45?

  111. Link Mauve

    jonas’, indeed, but at the same time it’d be much nicer to stop having to implement so many avatar methods.

  112. jonas’

    yeah, that’s true, t oo

  113. Link Mauve

    Basing it on 0084 we can then deprecate both 0054 and 0153 (finally!).

  114. jonas’

    Link Mauve, I wonder if it’d help if your patches make clear that no full pub-sub service is expected, but merely exactly the use-cases outlined there

  115. jonas’

    so that you don’t have to implement full-blown pubsub on a MUC, instead you can simply do stuff with pubsubby wireformat

  116. Link Mauve

    (I was the one who vetoed the deprecation of 0153 a few years ago, because of the MUC avatar usecase.)

  117. dwd

    Right. I'm going to veto this one because I think squeezing Pubsub/PEP into a MUC room needs a lot more than just a quick vote by Council - I'd like to see considerable discussion on the list from implementors first.

  118. Link Mauve

    jonas’, I could do that yeah.

  119. Ge0rG

    is this PEP or PubSub?

  120. Link Mauve

    Ge0rG, PEP is a subset of PubSub on a user JID, this one is just borrowing the PubSub elements required for 0084 on a MUC.

  121. jonas’

    dwd, that sounds like a reasonable course of action

  122. Link Mauve

    dwd, sounds sensible, thanks.

  123. Ge0rG

    Link Mauve: this is not an answer to my question ;)

  124. Link Mauve

    Ge0rG, this isn’t PEP.

  125. Link Mauve

    This is another PubSub profile.

  126. Ge0rG

    or maybe my question is badly worded: is this the same subset of pubsub as PEP, but on a MUC JID instead of an account JID?

  127. Link Mauve

    Ge0rG, no, it requires different features (mostly way fewer, but also persistency) from PEP.

  128. dwd


  129. dwd

    4) Voting Catch-Up

  130. Zash

    Ge0rG: Same basic concept I guess. PubSub service on the MUC JID.

  131. jonas’

    I’m also -1 for list discussion. At the very least, this should clearly spell out which subset of '60 is required.

  132. Link Mauve

    (re #3) I’ll raise that on the list.

  133. Ge0rG

    -1 and agreed to the call to list discussion.

  134. zinid

    yeah, this one was a surprise for me, that's why I'm chiming in, sorry

  135. dwd

    There's two outstanding votes at the moment, both from zinid's ProtoXEPs.

  136. jonas’

    zinid, comments from the floor are always appreciated.

  137. Ge0rG is guilty.

  138. jonas’

    Voting Catch-Up: XMPP Over Reload: +1; I still don’t know a lot about reload, but I don’t see anything which should be blocking from moving to Experimental

  139. dwd

    zinid, FWIW, comments from the floor are always welcome. I'll soon tell you if they're not.

  140. zinid


  141. Link Mauve

    xor: +1 if I weren’t already (latest voting summary says I was still waiting for the next version).

  142. dwd

    I'm +1 on both of these. I'm not sure if they'll go anywhere, to be honest, but I see no reason to block them.

  143. jonas’

    I was already +1 on EAX and still am

  144. Link Mauve

    eax: also +1.

  145. Link Mauve wants more x86 short names. :3

  146. Ge0rG

    the current XOR is the old XOR with the XSF-CA removed, right?

  147. zinid

    Ge0rG, yes

  148. jonas’

    Ge0rG, pretty much that

  149. zinid

    and with a few typos removed

  150. Ge0rG

    +1 to XOR

  151. zinid

    Ge0rG, and I removed your glitch about MUST

  152. Ge0rG

    Link Mauve: where is the NOP XEP?

  153. Link Mauve

    Ge0rG, waiting to be submitted as a ProtoXEP. :D

  154. dwd

    5) AOB

  155. dwd


  156. Ge0rG

    There was an LC on Compliance Suite 2019

  157. jonas’

    yeah........ editor’s fault I guess

  158. Ge0rG

    And I'd like to bring up the one specific use of XEP-0066 to indicate inline images for CS-2019.

  159. Ge0rG

    Because we want the CS to reflect current best practices, right?

  160. Ge0rG

    And https://xmpp.org/extensions/xep-0066.html#x-oob is non-obvious to new implementors from the outside.

  161. dwd

    OK - assuming the LC is complete can we get that on the agenda for next week?

  162. dwd

    And speaking of next week:

  163. dwd

    6) Next Meeting

  164. Ge0rG

    +1W WFM

  165. jonas’


  166. dwd

    Good stuff.

  167. dwd

    7) Ite, Meetign Est

  168. dwd

    Thanks all.

  169. Link Mauve

    Thanks. :)

  170. zinid

    > I'm not sure if they'll go anywhere, to be honest I'm going to implement RELOAD in ejabberd, as soon as it's deployed, XMPP clients may use it as a global storage (for storing telephone numbers, etc). Note that RELOAD defines "nodes" (complex stuff) and "client" (simple stuff), an XMPP client may only implement "client" functionality, it's quite simple, you don't need to join Chord DHT, only to parse RELOAD packets and support DTLS.

  171. zinid

    so it's not that scary as it might be seen

  172. zinid

    but again, this depends on global CAs, so, a lot of people to convince, hehe

  173. Ge0rG

    zinid: re EAX: §3.1 references two rather complex related works, would it be possible to explicitly list all those requirements in §3.1 so one doesn't need to parse the other docs as well?

  174. zinid

    Ge0rG, just a second, I will look at 3.1

  175. Ge0rG

    "General requirements"

  176. zinid


  177. Zash

    Could someone set a proper name and description in this rooms config?

  178. zinid

    well, the first is well understood I guess, so only bullet 2 requires explanation?

  179. zinid

    Ge0rG, ?

  180. Ge0rG

    zinid: I'd prefer to have a summary of both, so that as a reader I can see whether it is common sense or whether I need to invest some hours hunting down the rabbit hole

  181. Ge0rG

    non-normative summary would be ok

  182. jonas’

    mv this_discussion xsf@?

  183. zinid

    Ge0rG, well, the point is that the following 3.2 section explains what to do to fullfill the requirements

  184. zinid

    I will probably just rephrase it

  185. Ge0rG

    it is like in other places of XMPP. You read something harmless like "MUST conform to PRECIS profile XY" and then you end up spending half a day following unicode mapping tables

  186. zinid

    Ge0rG, 3.1 directly follows from 3.2

  187. Ge0rG

    zinid: ah, from reading the protoXEP I would have assumed that 3.1 is _in addition to_ 3.2

  188. zinid

    Ge0rG, yes, I agree it's confusing, I'll rephrase it

  189. Ge0rG

    zinid: maybe you should define certificate profiles, so that I can use EAX for XMPP auth without fulfilling "SubjectAltName field in the certificate MUST contain a single RELOAD URI"

  190. zinid

    Ge0rG, RELOAD URI is used as a device identifier

  191. zinid

    otherwise I need to invent another field

  192. Ge0rG

    i.e. "For the purpose of using a certificate in RELOAD, the certificate MUST fulfil the criteria of RFC6940"

  193. zinid

    > Even if XOR extension (XEP-XOR) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.

  194. Ge0rG

    it will be hard enough to get an xmpp cert signed by a public CA :>

  195. pep.

    "Ge0rG> Because we want the CS to reflect current best practices, right?" re oob, you mean the current ~~best~~ practices

  196. zinid

    Ge0rG, I think no public CA will sign you certs with XmppAddr, I might be wrong though

  197. zinid

    how will it validate it?

  198. Ge0rG

    zinid: I think so too. But then again, you can get a cert for from a public CA, so I wouldn't bet any money on it.

  199. Ge0rG

    pep.: something doesn't need to be good to be best.

  200. zinid

    Ge0rG, so, if it signs with XmppAddr, then why some uri (reload in our case) should be a problem?

  201. pep.

    And you're happy to just recommend The Conversations Protocol when there are actually extensions doing what this is trying to do?

  202. Ge0rG

    pep.: I'm not happy. I'm merely giving in to pressure from the most-widely-deployed peer-group client.

  203. pep.

    Well don't, please

  204. zinid

    Ge0rG, okay, I will add SHOULD there

  205. Ge0rG

    zinid: I'm just trying to understand.

  206. zinid

    and regarding, do you mean that recent DigiCert's fuckup?

  207. Ge0rG

    As I read EAX, I wonder if it is actually useful for other use cases than RELOAD

  208. Ge0rG

    zinid: yeah, that

  209. zinid

    Ge0rG, yes, it's absolutely useful, nothing prevents you from using it in c2s sasl external

  210. zinid

    or in any other place where you need to identify a peer by JID

  211. Ge0rG

    zinid: but I don't need all the RELOAD stuff for c2s SASL

  212. zinid

    Ge0rG, that's true, so I agreed to add SHOULD for RELOAD URI

  213. zinid

    and regarding forming the profile, well, I don't know how to formally do that

  214. zinid

    need a lot of stupid readings again

  215. Ge0rG

    zinid: I'd suggest to split §3.2 into multiple sections, where each section describes the requirements for a given e2e use case.

  216. zinid

    do we want to hardcode the use cases? I'm not sure

  217. Ge0rG

    as I understand EAX, it is first a description of the possible CA tree structures, and then the formal requirements when checking a certificate.

  218. zinid


  219. zinid

    and certs discovery

  220. Ge0rG


  221. Ge0rG


  222. zinid

    Ge0rG, won't we run into situation when users end up with multiple certs for incompatible use cases?

  223. zinid

    I don't see problems in RELOAD URI, it's reload://2342348230948023984@xmpp.org

  224. Zash

    ralphm: Could you set a name and description in this rooms config so that http://logs.xmpp.org/ looks nicer?

  225. ralphm clicks

  226. zinid

    Ge0rG, > The CA MUST generate a cryptographically random 128-bit integer each time it issues a leaf certificate for a new user device. This integer MUST be a part of the RELOAD URI and MUST be included in the certificate as specified under Section 3.2 of XEP-EAX.

  227. zinid

    Ge0rG, it's too complex or what? 😀

  228. ralphm

    Zash: nicer how?

  229. Ge0rG

    zinid: that sounds like a cert serial, except it's now also semantically bound to an obscure P2P network

  230. Zash

    ralphm: I don't see any change

  231. jonas’

    ralphm, also here https://search.jabber.network/search?q=council

  232. Ge0rG

    jonas’: that doesn't look bad if you don't have a well-defined reference MUC

  233. jonas’

    that’s true

  234. jonas’


  235. Ge0rG

    also having the search results below the fold is really unfortunate

  236. ralphm

    Zash, jonas’: I don't understand what you are asking?

  237. Ge0rG

    ralphm: configure the disco#info name and description parameters of this room :)

  238. ralphm

    Oh, I thought you were talking about the room topic

  239. Zash

    ralphm: Configuration dialog for the room itself.

  240. ralphm

    Do you want the description to match the topic, or something else?

  241. Ge0rG

    zinid: not complex, just maybe unneeded for the majority of use cases.

  242. zinid

    Ge0rG, > that sounds like a cert serial right, okay. I said I can do it SHOULD, but I'm not sure we need to hardcode usecases

  243. Ge0rG

    zinid: we need to hardcode the verification requirements, and those are different per use case

  244. Zash

    ralphm: Some description of the purpose of the room. "Room where the council holts its meetings" or something.

  245. ralphm

    ah right

  246. Ge0rG

    zinid: for e2ee I only care about xmppAddr. No, wait. About srvId xmpp? Is that a thing for clients?

  247. Ge0rG

    name="XSF Council Room" would probably be appropriate

  248. Zash

    ralphm: It is a bit funny how we have these 3 different fields :)

  249. Ge0rG

    Zash: and how these fields have even more different names.

  250. zinid

    Ge0rG, so far I can only split it into e2ee/c2s-sasl-externa with XmppAddr and RELOAD use case with RELOAD URI

  251. zinid

    Ge0rG, still, all those cases are documented in the corresponding documents

  252. Zash

    ralphm: Thanks!

  253. ralphm

    No worries

  254. pep.

    Ge0rG: I'm saying that btw because I am currently in your shoes re omemo.

  255. jonas’

    nice, you also set the language :)

  256. ralphm

    The field 'confusion' is one of the reasons why MIX doesn't define a room topic

  257. Ge0rG

    ralphm: but MIX was promised to have sticky messages.

  258. ralphm

    jonas’: yup

  259. jonas’

    I poked muclumbus to make it up-to-date there too

  260. ralphm

    Ge0rG: there's a note to that effect. I'm not sure if it counts as a promise but rather as one way it could be done.

  261. zinid

    Ge0rG, whatever, I need to go now to my family, we can discuss this later today

  262. ralphm

    There's much to be said about having both a room description and a topic.

  263. Ge0rG

    zinid: thanks

  264. dwd

    ralphm, "about", or "for"?

  265. Ge0rG

    Damn, this room is sorted under X now.

  266. ralphm

    dwd: I see a room name and description is more or less constant over time, whereas the topic would be something that changes depending on current affairs. Like how I change the topic of the xsf room during Board meetings.

  267. Zash

    Also different target audience. Room name and description would be for people outside of the room. Topic is for people in the room.

  268. Ge0rG

    ralphm: that doesn't give a rationale for having a description.

  269. Ge0rG

    There is also some significant overlap between these fields in most rooms

  270. Zash

    Name: Test room Description: Room for testing

  271. Zash

    Every test MUC I ever create ^

  272. Ge0rG

    This has now really become off topic

  273. ralphm

    Ge0rG: so me giving my view on things doesn't count as a rationale?

  274. Ge0rG

    ralphm: that's not what I meant. Something being constant over time is not a rationale.

  275. Ge0rG

    ..not for having it at least.

  276. Zash

    A description of the room for people who aren't in it seems a sensible thing to have.

  277. ralphm


  278. ralphm

    And yes, things might be overlapping and not consistent across rooms, partly caused by diverging client UIs and probably mostly because of, well, people.

  279. Ge0rG

    People. The largest problem XMPP faces.

  280. Ge0rG

    I agree that having that description for other people thing is useful indeed.

  281. ralphm

    There's also this innate desire by software developers for things to nicely align with definitions and try and find solutions for things that are better solved by social conventions or interactions.

  282. ralphm

    (technical solutions)

  283. Ge0rG

    ralphm: yeah, we can make people sane if we only make the input boxes strict enough!

  284. Ge0rG

    Did I mention Bookmark Names yet?

  285. Zash

    Naming things...

  286. Ge0rG

    It doesn't help very much to have those names default to the localpart of the room

  287. Zash

    Defaulting to the room name, if set, seems sensible.

  288. Ge0rG

    which defaults to the localpart.

  289. Ge0rG

    Daniel brought up the question on how to discriminate between a default-value of localpart and a manually set value that just happens to equal localpart.

  290. ralphm

    I don't know, I'm pretty with having room identifiers separate from room name and description and topic. I'm not sure if it must be the localpart, though. Being able to refer to such a more or less stable (but possibly mutable) short name seems great.

  291. ralphm

    Like in Slack, I suppose.

  292. Ge0rG

    ralphm: in impromptu MUCs you end up with a random base32 localpart that's not very human-friendly, so you'll want to hide that everywhere.

  293. ralphm

    Section 4.7.4 in XEP-0369 seems to conflate the room name and such a short identifier in the Name field. Meh.

  294. ralphm


  295. Ge0rG

    in Slack you are referencing to "that chat with peter and anne" and not to 5aaheds7@muc.xmpp.org as well.

  296. Zash

    identifier, short name, long name, short description, long description, short subject, long subject, ...

  297. Ge0rG

    well, Slack rooms don't have a JID obviously. But some other kind of ID.

  298. ralphm

    Yeah, I was talking about explicitly created rooms in Slack.

  299. Ge0rG

    Zash: you forgot about i18n

  300. ralphm

    I have a love-hate relationship with 'rooms with multiple people as done in Slack'

  301. Zash

    Ge0rG: That's where I draw the line

  302. Zash

    and leave, to find something to eat

  303. ralphm

    Also probably this is more a topic for xsf@

  304. ralphm

    Dinner, too.

  305. ralphm

    as in me having it

  306. Zash

    Why do board hold meetings in xsf@ but not council ?

  307. dwd

    Zash, History.

  308. dwd

    Zash, As a very loose version, Council always held meetings in an open room designated for the purpose, whereas Board held meetings in camera (ie, in a closed room). When Board decided to hold meetings openly instead, we/they decided to keep the existing Board room closed and held the meetings in XSF@ hoping to gain some interest and involvement.