XMPP Council - 2019-02-27

  1. vanitasvitae has left

  2. vanitasvitae has joined

  3. oli has left

  4. lnj has joined

  5. lnj has left

  6. oli has joined

  7. oli has left

  8. ralphm has joined

  9. oli has joined

  10. 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.

  11. zinid

    jonas’, seems like there is no agenda anyway

  12. ralphm has left

  13. Neustradamus has left

  14. Neustradamus has joined

  15. jonas’

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

  16. jonas’

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

  17. lnj has joined

  18. vanitasvitae has left

  19. vanitasvitae has joined

  20. Ge0rG has joined

  21. Ge0rG

    Good morning everyone!

  22. ralphm has joined

  23. jonas’


  24. oli has left

  25. Link Mauve

    ’morning, I’m here. o/

  26. dwd

    I'm here too.

  27. jonas’

    we have TrueDWD

  28. dwd

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

  29. jonas’

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

  30. dwd

    OK, let's go.

  31. Ge0rG


  32. dwd

    1) Role Call?

  33. jonas’

  34. Ge0rG

  35. Ge0rG is very unprepared.

  36. Link Mauve


  37. Link Mauve same.

  38. dwd

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

  39. jonas’


  40. dwd


  41. dwd

    2) Agenda Bashing

  42. dwd

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

  43. jonas’

    no protoxeps I’m aware of

  44. Link Mauve


  45. jonas’

    didn’t we discuss those already?

  46. Ge0rG

    More than the three ones that expired(?)?

  47. Link Mauve

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

  48. jonas’

    that’s true

  49. Link Mauve

    Ge0rG, two for us, and one for board.

  50. jonas’

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

  51. jonas’

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

  52. dwd

    Oh, lots.

  53. jonas’

    yeah, many of them have already started votes

  54. zinid

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

  55. jonas’

    zinid, yes

  56. zinid

    according to Tedd sterr

  57. dwd

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

  58. dwd

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

  59. jonas’


  60. jonas’

    I lost track, too

  61. Link Mauve

    #746 and #747 too.

  62. jonas’

    but the numbers sound realistic

  63. jonas’

    Link Mauve, we started votes on those already

  64. Link Mauve


  65. Ge0rG

    #752 was vetoed already.

  66. dwd

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

  67. Ge0rG

    By Dave and me.

  68. dwd

    Ge0rG, Good spot, it has indeed.

  69. dwd

    So #758 and #760.

  70. dwd

    So with that:

  71. dwd

    3) Items for a Vote:

  72. dwd

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

  73. dwd

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

  74. jonas’

    +1 I think

  75. Link Mauve

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

  76. jonas’

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

  77. Link Mauve


  78. Ge0rG

    It just adds two new fields, without any description?

  79. dwd

    Yes, this looks straightforward and painless. +1.

  80. Link Mauve

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

  81. dwd

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

  82. dwd

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

  83. Ge0rG

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

  84. Ge0rG

    so pubsub#access_model=dwd would be valid.

  85. dwd

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

  86. dwd

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

  87. Link Mauve


  88. dwd

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

  89. dwd

    Link Mauve, But yes.

  90. Link Mauve

    Heh. :)

  91. Ge0rG

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

  92. dwd

    Ge0rG, Really? That seems like a bug.

  93. jonas’

    Ge0rG, that’s the libraries problem.

  94. Ge0rG

    anyway, just trying to understand this.

  95. Link Mauve

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

  96. Ge0rG


  97. dwd


  98. dwd

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

  99. dwd

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

  100. Link Mauve

    I’m obviously +1, ask me anything.

  101. Ge0rG

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

  102. Ge0rG

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

  103. zinid

    wut? another avatar method for muc?

  104. 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)

  105. Link Mauve

    Ge0rG, yes, it is this one.

  106. dwd

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

  107. dwd

    zinid, Avatars for the MUC itself.

  108. Ge0rG

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

  109. 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.

  110. zinid

    dwd: it's already imlemented using vcards

  111. jonas’

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

  112. Link Mauve

    jonas’, NAFAIK.

  113. Link Mauve

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

  114. zinid


  115. jonas’

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

  116. dwd

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

  117. Link Mauve

    dwd, yes, that’s what it does.

  118. dwd

    zinid, As in directly on the vCard?

  119. dwd

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

  120. zinid

    dwd, yes

  121. zinid

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

  122. zinid

    and we're now rolling another one?

  123. Link Mauve

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

  124. zinid

    also, full blown pep node on muc?

  125. dwd

    zinid, Yeah, I hear you.

  126. Link Mauve

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

  127. jonas’

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

  128. jonas’

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

  129. Link Mauve

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

  130. jonas’

    yeah, that’s true, t oo

  131. Link Mauve

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

  132. 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

  133. jonas’

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

  134. Link Mauve

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

  135. 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.

  136. Link Mauve

    jonas’, I could do that yeah.

  137. Ge0rG

    is this PEP or PubSub?

  138. 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.

  139. jonas’

    dwd, that sounds like a reasonable course of action

  140. Link Mauve

    dwd, sounds sensible, thanks.

  141. Ge0rG

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

  142. Link Mauve

    Ge0rG, this isn’t PEP.

  143. Link Mauve

    This is another PubSub profile.

  144. 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?

  145. Link Mauve

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

  146. dwd


  147. dwd

    4) Voting Catch-Up

  148. Zash

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

  149. jonas’

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

  150. Link Mauve

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

  151. Ge0rG

    -1 and agreed to the call to list discussion.

  152. zinid

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

  153. dwd

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

  154. jonas’

    zinid, comments from the floor are always appreciated.

  155. vanitasvitae has left

  156. Ge0rG is guilty.

  157. 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

  158. vanitasvitae has joined

  159. dwd

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

  160. zinid


  161. Link Mauve

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

  162. 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.

  163. jonas’

    I was already +1 on EAX and still am

  164. Link Mauve

    eax: also +1.

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

  166. Ge0rG

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

  167. zinid

    Ge0rG, yes

  168. jonas’

    Ge0rG, pretty much that

  169. zinid

    and with a few typos removed

  170. Ge0rG

    +1 to XOR

  171. zinid

    Ge0rG, and I removed your glitch about MUST

  172. Ge0rG

    Link Mauve: where is the NOP XEP?

  173. Link Mauve

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

  174. dwd

    5) AOB

  175. dwd


  176. Ge0rG

    There was an LC on Compliance Suite 2019

  177. jonas’

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

  178. Ge0rG

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

  179. Ge0rG

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

  180. Ge0rG

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

  181. dwd

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

  182. dwd

    And speaking of next week:

  183. dwd

    6) Next Meeting

  184. Ge0rG

    +1W WFM

  185. jonas’


  186. dwd

    Good stuff.

  187. dwd

    7) Ite, Meetign Est

  188. dwd

    Thanks all.

  189. Link Mauve

    Thanks. :)

  190. 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.

  191. zinid

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

  192. zinid

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

  193. 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?

  194. zinid

    Ge0rG, just a second, I will look at 3.1

  195. Ge0rG

    "General requirements"

  196. zinid


  197. Zash

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

  198. zinid

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

  199. zinid

    Ge0rG, ?

  200. 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

  201. Ge0rG

    non-normative summary would be ok

  202. jonas’

    mv this_discussion xsf@?

  203. zinid

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

  204. zinid

    I will probably just rephrase it

  205. 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

  206. zinid

    Ge0rG, 3.1 directly follows from 3.2

  207. Ge0rG

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

  208. zinid

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

  209. 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"

  210. zinid

    Ge0rG, RELOAD URI is used as a device identifier

  211. zinid

    otherwise I need to invent another field

  212. Ge0rG

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

  213. 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.

  214. Ge0rG

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

  215. pep.

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

  216. zinid

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

  217. zinid

    how will it validate it?

  218. 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.

  219. Ge0rG

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

  220. zinid

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

  221. pep.

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

  222. Ge0rG

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

  223. pep.

    Well don't, please

  224. zinid

    Ge0rG, okay, I will add SHOULD there

  225. Ge0rG

    zinid: I'm just trying to understand.

  226. zinid

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

  227. Ge0rG

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

  228. Ge0rG

    zinid: yeah, that

  229. zinid

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

  230. zinid

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

  231. Ge0rG

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

  232. zinid

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

  233. zinid

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

  234. zinid

    need a lot of stupid readings again

  235. Ge0rG

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

  236. zinid

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

  237. 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.

  238. zinid


  239. zinid

    and certs discovery

  240. Ge0rG


  241. Ge0rG


  242. zinid

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

  243. zinid

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

  244. Zash

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

  245. ralphm clicks

  246. 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.

  247. zinid

    Ge0rG, it's too complex or what? 😀

  248. ralphm

    Zash: nicer how?

  249. Ge0rG

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

  250. Zash

    ralphm: I don't see any change

  251. jonas’

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

  252. Ge0rG

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

  253. jonas’

    that’s true

  254. jonas’


  255. Ge0rG

    also having the search results below the fold is really unfortunate

  256. ralphm

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

  257. Ge0rG

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

  258. ralphm

    Oh, I thought you were talking about the room topic

  259. Zash

    ralphm: Configuration dialog for the room itself.

  260. ralphm

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

  261. Ge0rG

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

  262. 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

  263. Ge0rG

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

  264. Zash

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

  265. ralphm

    ah right

  266. Ge0rG

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

  267. Ge0rG

    name="XSF Council Room" would probably be appropriate

  268. Zash

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

  269. Ge0rG

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

  270. zinid

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

  271. zinid

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

  272. Zash

    ralphm: Thanks!

  273. ralphm

    No worries

  274. pep.

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

  275. jonas’

    nice, you also set the language :)

  276. ralphm

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

  277. Ge0rG

    ralphm: but MIX was promised to have sticky messages.

  278. ralphm

    jonas’: yup

  279. jonas’

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

  280. 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.

  281. zinid

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

  282. ralphm

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

  283. Ge0rG

    zinid: thanks

  284. dwd

    ralphm, "about", or "for"?

  285. Ge0rG

    Damn, this room is sorted under X now.

  286. 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.

  287. Zash

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

  288. Ge0rG

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

  289. Ge0rG

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

  290. Zash

    Name: Test room Description: Room for testing

  291. Zash

    Every test MUC I ever create ^

  292. Ge0rG

    This has now really become off topic

  293. ralphm

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

  294. Ge0rG

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

  295. Ge0rG

    ..not for having it at least.

  296. Zash

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

  297. ralphm


  298. 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.

  299. Ge0rG

    People. The largest problem XMPP faces.

  300. Ge0rG

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

  301. 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.

  302. ralphm

    (technical solutions)

  303. Ge0rG

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

  304. Ge0rG

    Did I mention Bookmark Names yet?

  305. Zash

    Naming things...

  306. Ge0rG

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

  307. Zash

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

  308. Ge0rG

    which defaults to the localpart.

  309. 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.

  310. 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.

  311. ralphm

    Like in Slack, I suppose.

  312. 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.

  313. ralphm

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

  314. ralphm


  315. Ge0rG

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

  316. Zash

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

  317. Ge0rG

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

  318. ralphm

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

  319. Ge0rG

    Zash: you forgot about i18n

  320. ralphm

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

  321. Zash

    Ge0rG: That's where I draw the line

  322. Zash

    and leave, to find something to eat

  323. ralphm

    Also probably this is more a topic for xsf@

  324. ralphm

    Dinner, too.

  325. ralphm

    as in me having it

  326. Zash

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

  327. dwd

    Zash, History.

  328. 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.

  329. Neustradamus has left

  330. oli has joined

  331. oli has left

  332. oli has joined

  333. Link Mauve has left

  334. Link Mauve has joined

  335. oli has left

  336. Link Mauve has left

  337. Link Mauve has joined