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 https://www.schneier.com/blog/archives/2015/11/paris_terrorist.html
  32. dwd 1) Role Call?
  33. jonas’
  34. Ge0rG
  35. Ge0rG is very unprepared.
  36. Link Mauve /me
  37. Link Mauve same.
  38. dwd Kev said he'd be missing this one, didn't he?
  39. jonas’ yes
  40. dwd Righty.
  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 zinid’s.
  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’ maybe
  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 Oh.
  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 Indeed.
  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 BuddyCloud?
  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 +0
  97. dwd OK.
  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 sigh
  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 OK.
  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 okay
  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 Nobody?
  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’ +1
  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 ah
  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 192.168.1.1 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 192.168.1.1, 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 yes
  239. zinid and certs discovery
  240. Ge0rG Righ.
  241. Ge0rG Right.
  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’ https://search.jabber.network/search?q=muc.xmpp.org
  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 Indeed
  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 Right
  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