XSF Discussion - 2019-09-05

  1. matkor has left

  2. neshtaxmpp has joined

  3. matkor has joined

  4. patrick has left

  5. Chobbes has joined

  6. Douglas Terabyte has left

  7. adiaholic has joined

  8. gav has left

  9. Wojtek has joined

  10. adiaholic has left

  11. adiaholic has joined

  12. pdurbin has joined

  13. zach has left

  14. zach has joined

  15. Wojtek has left

  16. UsL has left

  17. UsL has joined

  18. Chobbes has left

  19. Chobbes has joined

  20. pdurbin has left

  21. Douglas Terabyte has joined

  22. zach has left

  23. zach has joined

  24. neshtaxmpp has left

  25. neshtaxmpp has joined

  26. adiaholic has left

  27. Chobbes has left

  28. Chobbes has joined

  29. adiaholic has joined

  30. david has left

  31. david has joined

  32. david has left

  33. david has joined

  34. lskdjf has left

  35. zach has left

  36. zach has joined

  37. Chobbes has left

  38. UsL has left

  39. Yagiza has joined

  40. zach has left

  41. zach has joined

  42. david has left

  43. lumi has left

  44. moparisthebest has left

  45. david has joined

  46. pdurbin has joined

  47. moparisthebest has joined

  48. jrmu has joined

  49. APach has joined

  50. matkor has left

  51. aj has left

  52. matkor has joined

  53. aj has joined

  54. kokonoe has left

  55. kokonoe has joined

  56. kokonoe has left

  57. kokonoe has joined

  58. kokonoe has left

  59. kokonoe has joined

  60. aj has left

  61. !xsf_Martin has left

  62. !xsf_Martin has joined

  63. rion has left

  64. rion has joined

  65. zach has left

  66. zach has joined

  67. arc has left

  68. arc has joined

  69. pdurbin has left

  70. adiaholic has left

  71. adiaholic has joined

  72. pdurbin has joined

  73. Ge0rG

    There might also be some merit in having a structured mapping between XEPs and feature identities.

  74. adiaholic has left

  75. LNJ has joined

  76. kokonoe has left

  77. kokonoe has joined

  78. jabberjocke has left

  79. APach has left

  80. aj has joined

  81. Nekit has left

  82. Nekit has joined

  83. APach has joined

  84. adiaholic has joined

  85. zach has left

  86. zach has joined

  87. Zash has joined

  88. wurstsalat has joined

  89. j.r has left

  90. j.r has joined

  91. LNJ has left

  92. Alex has joined

  93. arc has left

  94. arc has joined

  95. karoshi has joined

  96. ralphm

    I am curious if including the disco section in every XEP actually triggers developers to make sure they handle the discovery bits while implementing.

  97. winfried has left

  98. winfried has joined

  99. jonas’

    dwd, why would you need to change XEP-0001 for that?

  100. Zash

    I'm going to assume that not including it would lead to nobody implementing disco bits.

  101. jonas’

    I agree with Zash

  102. ralphm


  103. ralphm

    While doing some research, I came across the ancient XEP-0038. It uses the following in that section: “To find out if an entity supports Jabber Icon Styles, look for the feature category of http://jabber.org/protocol/icon-styles using jabber:iq:browse or http://jabber.org/protocol/disco. The same feature category can be used with feature negotiation.”

  104. ralphm

    As it doesn't include any example protocol flow, this feels much easier to "miss" while scanning the spec.

  105. zach has left

  106. zach has joined

  107. jonas’


  108. Daniel

    I mean I said this yesterday. But nobody reads xeps. Everyone just copy pastes samples

  109. ralphm

    (also funny that it refers to the pre-disco protocol)

  110. Tobias has joined

  111. winfried has left

  112. winfried has joined

  113. Zash

    On the other hand, if you include too much boilerplate you will likely miss parts too. Hence why you discover something new each time you read XEP-0060 or XEP-0045

  114. Daniel

    Zash: I'm not sure that xep60 and 45 would have been better w/o the disco bits

  115. Daniel

    But I get the point...

  116. ralphm

    I'm glad that for MIX we already have a split now.

  117. Seve

    > I'm going to assume that not including it would lead to nobody implementing disco bits. I think that way as well

  118. ralphm

    jonas’: by the way, thanks for linking to that old mail of yours on References. Taking that into account as well, while working on my overview of pointing to things.

  119. jonas’

    ralphm, \o/ :)

  120. karoshi has left

  121. karoshi has joined

  122. Daniel

    I wish the open source community would be more enthusiastic about MIX

  123. jonas’

    Daniel, I am extremely enthusiastic

  124. jonas’

    I need a server to play with though :)

  125. winfried has left

  126. Daniel

    jonas’: any ejabberd should do

  127. jonas’

    I’m ready to write the aioxmpp code, and I’m ready to make Muclumbus support it

  128. jonas’


  129. winfried has joined

  130. jonas’

    I totally missed that

  131. Daniel

    Ask Holger if you don't want to install your own

  132. jonas’

    they have docker images, I’m fine with that

  133. jonas’

    was MIX support in the newsletter?

  134. Daniel

    jonas’: not that _we_ are currently stuck at where to put the channels if not the roster

  135. Daniel

    That part is not implemented in ejabberd because it's stupid

  136. Daniel

    But normal join / sending messages works

  137. jonas’

    Daniel, PEP-ish thing?

  138. Daniel

    jonas’: yes. Probably

  139. jonas’

    PEP with server-side side-effects seems like a great thing in general.

  140. Daniel

    But someone needs to write down the syntax

  141. ralphm

    Daniel: I think the issue is that it is perceived as really complex and involved. While there is a certain truth to that, the problems it tries to attack aren't really simple, to be honest. However, I believe that there is a simple subset that would be a good start for getting implementations.

  142. Daniel

    ralphm: yes. Full ack

  143. jonas’

    ISTM I have something to do during my vacation in 2w :)

  144. ralphm

    As an example, I don't think you /need/ roster integration from the get go.

  145. Daniel

    jonas’: I mean really an exploratory implementation can be written on a weekend

  146. jonas’

    Daniel, not with my weekends at the moment ;)

  147. Daniel

    And that includes reading the xep

  148. ralphm

    Anyway, I'm currently focussed on rich messaging and pointing to things. MIX might be my next focus.

  149. Daniel

    Client side I mean

  150. ralphm

    Daniel: yes. At VEON we also had a simple implementation relatively quickly. On the server side, too.

  151. Daniel

    Yeah. I don't think it took zinid too long either

  152. pdurbin has left

  153. Daniel

    I mean I said this before but to me the cool thing about MIX is, that while I see the need for it, there is no urgency to ship it, so for once we the community can actually use the experimental state as what it was intented to, and do exploratory implementations that won't be shipped

  154. zach has left

  155. zach has joined

  156. ralphm

    And if you want some kind of backwards compat, maybe it is worthwhile starting with a fresh MIX implementation, and then having a MUC legacy interface to it.

  157. ralphm

    (as opposed to the other way around)

  158. remko has joined

  159. APach has left

  160. kokonoe has left

  161. kokonoe has joined

  162. Steve Kille has left

  163. APach has joined

  164. Steve Kille has joined

  165. winfried has left

  166. winfried has joined

  167. adiaholic has left

  168. adiaholic has joined

  169. jabberjocke has joined

  170. j.r has left

  171. j.r has joined

  172. j.r has left

  173. j.r has joined

  174. mr.fister has left

  175. dwd

    jonas’, The schema for XEPs is in XEP-0001, hence that involvement.

  176. dwd

    ralphm, I had a working MIX-with-MUC-interface in a few days at Threads.

  177. jonas’

    dwd, the schema is not normative, meheard

  178. jonas’

    especially since it’s not validated, only the DTD is

  179. zach has left

  180. zach has joined

  181. ralphm

    dwd: yes, indeed

  182. kokonoe has left

  183. Dele (Mobile) has joined

  184. kokonoe has joined

  185. adiaholic has left

  186. adiaholic has joined

  187. Daniel has left

  188. Daniel has joined

  189. Daniel has left

  190. linkmauve has joined

  191. Daniel has joined

  192. zach has left

  193. zach has joined

  194. Zash has left

  195. Zash has joined

  196. Nekit has left

  197. jcbrand has joined

  198. goffi has joined

  199. goffi has left

  200. goffi has joined

  201. goffi has left

  202. goffi has joined

  203. Nekit has joined

  204. adiaholic has left

  205. goffi has left

  206. adiaholic has joined

  207. adiaholic has left

  208. adiaholic has joined

  209. marc_ has joined

  210. goffi has joined

  211. kokonoe has left

  212. kokonoe has joined

  213. zach has left

  214. zach has joined

  215. marc_ has left

  216. marc_ has joined

  217. adiaholic has left

  218. adiaholic has joined

  219. adiaholic has left

  220. adiaholic has joined

  221. Kev

    Ge0rG / ralphm: I think the option we spoke of to have the apply-to children as siblings of the apply-to isn't needed. Reason being that e.g. for LMC the LMC would be the child of the apply-to, and then the LMC can describe where the applicable payloads should reside.

  222. Kev

    Am I being dense?

  223. Kev

    (r than normal)

  224. jonas’

    Kev, having them as siblings was intended for backward compatibility

  225. jonas’

    so that we don’t have to change the core LMC wire format

  226. ralphm

    Yeah, my feeling was that I have a preference for a sibling

  227. Kev

    Was it? That certainly was not what I thought we were discussing.

  228. jonas’

    (and don’t have to duplicate that information)

  229. jonas’

    that’s what I read from Ge0rGs gist

  230. Kev

    I thought we were discussing having the e.g. <body/> outside the <apply-to/>.

  231. jonas’

    > - for E2EE and legacy Last Message Correction, an <attach-to> without a payload implies that the sibling elements need to be reviewed

  232. Kev

    I have those words in front of me.

  233. jonas’

    I read the "legacy" part as "for backward compat", I may be wrong

  234. Kev

    But I think we got confused.

  235. Kev

    I think it's ok to have something wrapped by the apply-to, and the thing that's wrapped can say to look outside, if it wants to.

  236. ralphm

    Especially because, e.g. for references, in some cases you might attach to another message, and some you don't (because the body is included). Having them in the same place seems better.

  237. jonas’

    Kev, makes sense

  238. Ge0rG

    Kev: but then we end up with the overengineered <look-outside-for element-name="body" namespace="jabber:client"/> element

  239. Kev

    Ge0rG: I think we end up with that whatever happens. Just whether it's going to live inside the LMC or apply-to element.

  240. Kev

    (I also don't think it's overengineered)

  241. Ge0rG

    It's the obvious generic thing.

  242. Ge0rG

    But what happens when: 1. I send a message to a MUC 2. the MUC attaches references 3. I LMC that message 4. the MUC ??? ???

  243. Ge0rG

    But what happens when: 1. I send a message to a MUC 2. the MUC attaches references 3. I LMC my original message 4. the MUC ??? ???

  244. ralphm

    Parses it again?

  245. Nekit has left

  246. Ge0rG

    ralphm: the MUC needs to LMC the attached message, obviously

  247. Kev

    Yes. The MUC will need to understand LMC for this to work.

  248. Kev

    (Yes was to Ralph)

  249. ralphm

    Ah, that is a good point, yes

  250. pdurbin has joined

  251. Ge0rG

    so #4 will be a message attached to two different messages, with different attaching semantics

  252. ralphm

    If it doesn't and the room doesn't understand LMC, it would attach to that LMC stanza instead of the original, as it parses the new body element?

  253. APach has left

  254. Ge0rG

    ralphm: yes

  255. Kev

    I think what we need (which we need for reactions anyway) is a way of un-applying an apply-to. So the MUC would un-apply its previous references, and apply new ones. To the original stanza.

  256. ralphm

    You'd have a chain

  257. Ge0rG

    ralphm: a tree

  258. Ge0rG

    Kev: would an implicit unapply by applying something new work? With a limit of one application per JID and application type?

  259. Kev

    So we need stanza versioning :)

  260. moparisthebest has left

  261. Kev

    I think you want to allow many applications per type, in the case of reactions particularly, but we could always have a 'remove-previous' flag on the application.

  262. ralphm

    Kev: yes, we surely need an unattach. But I'm curious about 'unknown' things being attached. Like if we redo LMC to be edits, with a namespace change and the muc service not understanding it (yet)

  263. Ge0rG

    Kev: we are overengineering it

  264. Nekit has joined

  265. Ge0rG

    This is going to become the MIX of Message References.

  266. ralphm


  267. Kev

    I'm not yet convinced this is over-engineered. It's generic, which isn't necessarily the same. Particularly if we end up with something easier to implement all the edge-cases than doing the under-engineered thing.

  268. Kev

    Let's not make it the MUC of Message References :)

  269. Ge0rG


  270. wurstsalat has left

  271. wurstsalat has joined

  272. pdurbin has left

  273. Yagiza has left

  274. Ge0rG

    So let's say we do Message Edits by means of stanza versioning. What kind of wire format do you suggest?

  275. Ge0rG

    Will it use Attach-To (in a kind of privileged manner, checking the sender JID), or will it use a new, orthogonal syntax?

  276. Kev

    The stanza versioning was half-said in jest.

  277. Kev

    (Although if we were starting again it's probably the right thing to do)

  278. Ge0rG

    There are some aspects I hate about LMC, but they can be changed without touching the wire format

  279. ralphm

    I'm not sure. If you want to allow correcting other messages, the wire format wouldn't need to change but the semantics will. To separate them you need to up the version of the namespace.

  280. Ge0rG

    ralphm: I argue that we just can introduce a new feature.

  281. Ge0rG

    I still see some merit in allowing room admins to change a message, though.

  282. larma

    I also had a short chat regarding attach-to/MAM 2.0 yesterday. One thing that came up is that 0333 read markers only mention a single message but apply to many. It seems sensible to not send 10 read marker messages if you open a chat with 10 unread messages, so this one kind of requires being attached to multiple messages

  283. Nekit has left

  284. alameyo has left

  285. ralphm

    Ge0rG: how would you introduce the new feature?

  286. alameyo has joined

  287. Ge0rG

    larma: good point, but read markers attach to the latest message

  288. Ge0rG

    which is a dumb thing in a protocol that lacks any kind of message ordering.

  289. Ge0rG

    (I'm speaking of MAM here)

  290. ralphm

    larma: the semantics of markers already say you should squash them? A server should only have one?

  291. Ge0rG

    ralphm: by "feature" I meant a new var in disco#info

  292. Ge0rG

    I've implemented delayed 0184 transmission for MAM yesterday, and that made me realize that even with 1500+ entries in MAM, there is only a handful of not yet sent 0184s

  293. Nekit has joined

  294. ralphm

    Ge0rG: if there are clients implement something that ignores lmc if it is not the last, and don't know your new feature, you are not seeing edits?

  295. larma

    Current markers suck for MAM 2.0 anyways, but the question is more how a good updated version would probably look like: `<message><mark-read /><attach-to id=A /><attach-to id=B /></message>` and not `<message><mark-read /><attach-to id=A /></message>`+`<message><mark-read /><attach-to id=B /></message>` (the latter one would be required if we only allow to attach to a single message)

  296. ralphm

    I don't think you should do read markers for stanzas that attach to others at all

  297. Ge0rG

    ralphm: did you just say "resource locking"?

  298. marc_ has left

  299. marc_ has joined

  300. ralphm


  301. Ge0rG

    ralphm: in the Carbons+MAM world, there is no way to know which features the receiving client will have.

  302. ralphm

    Yes indeed

  303. Ge0rG

    ralphm: so yes, if you allow editing older messages on the sending side, the receiving side is not guaranteed to display those as edits

  304. zach has left

  305. zach has joined

  306. ralphm


  307. Ge0rG

    I can only hope that no implementor is dumb enough to just drop the new messages.

  308. ralphm

    That'd be disappointing

  309. Ge0rG

    ralphm: but bumping the namespace isn't going to improve that in any sensible way.

  310. Ge0rG

    this is BTW the part of LMC that I dislike the most.

  311. ralphm

    Well, you'd at least see all the things?

  312. Ge0rG

    ralphm: what things?

  313. ralphm

    If a client doesn't know the new thing it will just display the body?

  314. Ge0rG


  315. ralphm

    So you have 'double' messages

  316. Ge0rG

    if a client supports LMC and considers an edit as illegal, it will also just display the body, unless the developer is a huge moron.

  317. Kev

    That sounds quite wrong.

  318. ralphm

    And judgemental

  319. Ge0rG

    So you will have double messages if you do an "illegal" v1 LMC, or if you have a v2 Edit.

  320. Kev

    Treating access violations as being something other than what they were intended to be.

  321. Kev

    And LMC doesn't consider correcting previous messages illegal, just negotiated outside 308

  322. ralphm

    Especially in the context of MUC where you can occupy someone's previous nick

  323. Ge0rG

    Kev: yes, and that negotiation can be done by means of a new feature var.

  324. Ge0rG

    What is the correct behavior if you receive a correction for a message that you don't know about?

  325. Ge0rG

    What is the correct behavior if you receive a correction for an older message?

  326. APach has joined

  327. Kev


  328. ralphm

    And because we don't know it is weird.

  329. larma has left

  330. larma has joined

  331. Ge0rG

    So this _is_ the MUC of Message Editing, after all.

  332. ralphm

    Then again, the spec is deferred and would otherwise be experimental. Tough luck.

  333. ralphm

    We can just fix it properly

  334. Nekit has left

  335. Ge0rG

    ralphm: so we don't need to bump the namespace at all!

  336. adiaholic has left

  337. ralphm

    Arguably no. And if you are putting the thing inside an attach-to, it will behave slightly differently anyway for clients out there.

  338. Ge0rG

    Kev [11:34]: > Treating access violations as being something other than what they were intended to be. What would be your suggested approach?

  339. larma

    As I read it, there is no "invalid" LMC, it's just not an LMC if it's using an old or unknown message, so it would become a normal message, because there is no specification that says otherwise.

  340. Ge0rG

    larma: this is also the most sensible thing to do

  341. ralphm

    larma: I think we can agree we don't really know

  342. kokonoe has left

  343. Ge0rG

    Unless silently hiding messages from the user is your fetish

  344. ralphm

    Have to drive now.

  345. Ge0rG

    Me too.

  346. kokonoe has joined

  347. Kev

    larma: I think the right thing to do depends on the nature of the wrongness. If it's an older message than you have, displaying it fresh might be ok (although probably annotating it visually is better). If it's that you're trying to correct someone else's message or something, that seems worse.

  348. Daniel has left

  349. Daniel has joined

  350. adiaholic has joined

  351. Daniel has left

  352. Daniel has joined

  353. larma

    Kev, there is no such thing as "trying to correct someone else's message" in LMC. As IDs are not required to be unique, the only sensible implementation is to understand the ID as referring to the last ID of the sending user (else I could stop you from correcting a message by sending a message with the same ID after yours).

  354. Nekit has joined

  355. larma

    (sending user = full jid, in this context)

  356. Daniel has left

  357. Daniel has joined

  358. adiaholic has left

  359. ralphm

    FWIW, I think introducing a feature where you*can* change the text of a message by someone else is a bad idea, even if that someone is a moderator.

  360. Kev

    Depends very much on context, I think.

  361. Kev

    It's not going to be a good thing for normal IM situations.

  362. ralphm

    Kev: do you have a good example?

  363. pep.

    fwiw, I know Mattermost allows it

  364. Kev

    ralphm: I'm thinking of bloggy type things.

  365. pep.

    Message editing of anybody by admins

  366. goffi

    kev: we have real blogging for bloggy things.

  367. pep.

    (not saying it's a good thing)

  368. j.r has left

  369. j.r has joined

  370. Daniel has left

  371. ralphm

    I _might_ accept textual annotations, maybe with an instruction to forget the original body, but if you start allowing true edits, you can no longer rely on who said what.

  372. Daniel has joined

  373. Daniel has left

  374. pep.

    I agree I wouldn't want that either. I'm fine with retraction-like things though

  375. Daniel has joined

  376. Daniel has left

  377. Mikaela has left

  378. Daniel has joined

  379. Mikaela has joined

  380. ralphm


  381. ralphm

    For blog things you can just use regular pubsub

  382. Nekit has left

  383. Daniel has left

  384. Daniel has joined

  385. Nekit has joined

  386. Daniel has left

  387. Daniel has joined

  388. LNJ has joined

  389. zach has left

  390. zach has joined

  391. lskdjf has joined

  392. sonny has joined

  393. COM8 has joined

  394. eevvoor has joined

  395. linkmauve has left

  396. adiaholic has joined

  397. Ge0rG

    I was thinking of Web forum like functionality, where a Moderator can delete curse words, and the message gets annotated by "edited by $moderator"

  398. !xsf_Martin has left

  399. pep.

    That would also probably be pubsub?

  400. pep.

    Is this new attach thing also going to apply to pubsub?

  401. zach has left

  402. zach has joined

  403. jubalh has joined

  404. COM8 has left

  405. linkmauve has joined

  406. pdurbin has joined

  407. APach has left

  408. APach has joined

  409. adiaholic has left

  410. adiaholic has joined

  411. COM8 has joined

  412. COM8 has left

  413. jcbrand has left

  414. jcbrand has joined

  415. COM8 has joined

  416. pdurbin has left

  417. j.r has left

  418. j.r has joined

  419. kokonoe has left

  420. Kev

    https://github.com/Kev/xeps/blob/fasten/inbox/fasten.xml updated, BTW. I feel this is probably sufficient that reactions could be framed in these terms and both make it to Experimental, although I don't pretend it's perfect.

  421. marc_ has left

  422. jonas’

    https://github.com/Kev/xeps/blob/fasten/inbox/fasten.xml#L88 I don’t particularly like that. Do you think there is a case where it is useful for a receiving entity to know *that* payloads outside of apply-to are used by apply-to, without knowing how the actual apply-to mechanism is supposed to work, i.e. in that case, without understanding what <edit/> means?

  423. marc_ has joined

  424. Kev


  425. jonas’

    can you give an example?

  426. Kev

    If you want MAM2 to be able to include the pertinent data in the grouped responses.

  427. Kev

    There's a note about it at the bottom.

  428. jonas’


  429. jonas’

    (I’m not good at reading uncompiled XEPs)

  430. jonas’

    MAM2 is an argument, I’m not sure if it’s a good one though.

  431. jonas’

    i.e. if it wouldn’t make more sense to make MAM2 return the full stanza in the general case, unless for features where it understands that only a partial stanza is needed

  432. jonas’

    thinking about what happens if a malfunctioning or malicious client omits the <external/> elements here

  433. Kev

    There are questions.

  434. jonas’

    as always

  435. jonas’

    not saying I would block on that basis, of course

  436. Kev

    I'm trying to avoid one of the unfortunate properties of LMC that it has horrible edge cases when you have additional payloads that aren't actually needed as replacements.

  437. Kev

    I think in answer to this question, a receiving client would treat it as malformed without the externals (or that it's trying to edit the origin stanza to have no payloads, possibly).

  438. jonas’

    right, so, this is only tangential, but I was thinking about how you expect a MAM response to look like. would those stanzas containing <apply-to/> be returned in a normal MAM query?

  439. j.r has left

  440. Kev

    Raw MAM1? Yes, probably.

  441. jonas’

    or would a client only get the summary on the stanza to which stuff was "fastened to"

  442. jonas’

    even MAM2

  443. Kev

    MAM2, I expect you to say what you want in the initial query somehow.

  444. jonas’


  445. jonas’

    how would you handle the case where a client has already seen the stanza which was "fastened to", but now wants to catch up on new fastenings?

  446. Kev

    So if you're a MAM2 client that's asking for summaries with stanzas, you'd have the stanzas that were rolled into the summaries elided unless you ask for them specifically.

  447. Kev

    You mean a mid-sized client? Not a fat-client that does full-sync, nor a thin client that requests data when needed?

  448. jonas’

    I mean, even a fat-client could benefit a lot from summaries

  449. jonas’

    as a fat-client author, I’d be interested in that ;)

  450. Kev

    You'd like your fat-client to lose weight? :)

  451. Alex has left

  452. jonas’

    a bit of bandwidth-weight, yes

  453. jonas’

    if MAM can do a restructuring I’ll do myself anyways, I don’t see why I shouldn’t profit off that if it’s possible to do so :)

  454. Zash

    Summary, update UI, fetch actual data. Things look faster than they are 🙂

  455. ralphm

    The cases where we talked about summaries were reactions (debated here quite a bit) and simple polls (Summit). Neither of those cases are about 'external' elements like with LMC, so I'm not quite sure why we need to actuall explicitly mention them. Except maybe for sanity checks.

  456. lumi has joined

  457. moparisthebest has joined

  458. ralphm

    Is this to somehow tell a client that it shouldn't render <body/> if it knows about fastening?

  459. Kev

    LMC is summaryish, though.

  460. Kev

    Or 'edit', at least.

  461. Kev

    To not confuse with current LMC.

  462. ralphm

    Oh, I actually thought it would be a case of replacing.

  463. ralphm

    (which I get that there isn't another fastening to be replaced)

  464. Alex has joined

  465. Kev

    It could be that any fastening that needs a <body> is a special type of summary that isn't really a summary, but just that the archive needs to return a full stanza containing the fastenings.

  466. Kev

    Big question is whether this is Experimental standard, I think.

  467. Kev

    If it is, I should submit it and move on to updating references to use it.

  468. Kev

    Or maybe get lunch.

  469. moparisthebest has left

  470. moparisthebest has joined

  471. adiaholic has left

  472. UsL has joined

  473. adiaholic has joined

  474. jabberjocke has left

  475. Chobbes has joined

  476. gav has joined

  477. adiaholic has left

  478. Alex has left

  479. Alex has joined

  480. Alex has left

  481. adiaholic has joined

  482. Alex has joined

  483. marc_ has left

  484. marc_ has joined

  485. debacle has joined

  486. COM8 has left

  487. debacle has left

  488. jabberjocke has joined

  489. nyco has joined

  490. nyco has left

  491. ralphm

    Kev: do you mean "should I submit this, or are we altering the existing experimental XEP by Sam"?

  492. Kev


  493. Kev

    I was asking whether anyone (mostly Council) felt this was not ready for Experimental, following on from the discussion in yesterday's meeting.

  494. remko has left

  495. Zash

    There is a way to find out

  496. j.r has joined

  497. ralphm

    Kev: from what I read, just submit it, and then later we can figure out what to do with competing specs

  498. zach has left

  499. ralphm

    It is not like we didn't have 3 pubsub specs

  500. zach has joined

  501. ralphm

    Also, you submitting it to the editor makes it possible for us to actually discuss it :-D

  502. Nekit has left

  503. ralphm

    Because I have comments.

  504. adiaholic has left

  505. ralphm

    and questions

  506. Chobbes has left

  507. Nekit has joined

  508. jabberjocke has left

  509. ralphm

    Also, I might not make it for the Board meeting.

  510. jabberjocke has joined

  511. Yagiza has joined

  512. nyco has joined

  513. nyco


  514. Guus


  515. Guus

    ralphm Seve MattJ ?

  516. Guus


  517. Guus

    if this meeting is not going to happen, then I'd like to have an email vote on one of the topics that I scheduled for today.

  518. Guus

    The outcome can affect travel arrangements for people, so I'd like to get it out of the way

  519. Guus

    It regards flow email, the GSoC Mentor Summit stipend.

  520. Guus

    nyco did you get that?

  521. nyco is finishing a call

  522. Guus

    (he cc'ed me, so I definitely got it, unsure if the reset of board did).

  523. adiaholic has joined

  524. Guus

    In short, Flow writes that we have 3 mentors that will visit the GSoC mentor summit. In other years, we'd have two. Flow asks if XSF is willing to reimburse the travel costs of all three mentors (as opposed to only the regular 2). He mentions that travel costs will be relatively low (mentors are largely in the same country as where the event venue is), and that the Google stipend that the XSF received will cover the costs.

  525. nyco

    yes, let's discuss that

  526. Guus

    Well, it's just you and me in this meeting, so we don't have quorum.

  527. MattJ


  528. Guus

    but I'd like to resolve this, so that people can make arrangements.

  529. Guus

    ah, there's Quorum 🙂

  530. Guus bangs gavel

  531. Guus

    0. Role call / agenda

  532. Seve waves

  533. Guus

    I've seen MattJ and Nyco, Seve starts typing now (hi!), Ralph mentions he might be late/missing.

  534. nyco


  535. Guus

    As usual, the agenda is driven by Trello

  536. Guus


  537. Guus

    does anyone want to add something to the agenda for this meeting?

  538. Guus

    I'm taking that as a 'no'.

  539. Guus

    on to the fun part:

  540. Guus

    1. Confirm minute taker

  541. Guus


  542. Daniel

    I can do minutes

  543. Guus

    Thanks Daniel!

  544. Guus

    2. Topics for decisions

  545. Guus

    2.1 GSoC Mentor summit stipend (Flow's mail)

  546. Guus

    I touched on this before the meeting started. Did all of board get Flow's mail?

  547. MattJ

    I did

  548. Seve

    I manage the mailing list, so I probably accepted it to go through but did not read it unfortunately (yet)

  549. Guus

    (I'm unsure if that works, mailinglist permission wise)

  550. Guus

    ok, great. Thanks Seve (for accepting it, not for not reading it 😉 )

  551. Chobbes has joined

  552. Guus

    Can you read it now? If at all possible, I'd like to resolve this in this meeting, as it can affect travel arrangements.

  553. moparisthebest has left

  554. Guus

    To repeat what I typed a short while ago:> In short, Flow writes that we have 3 mentors that will visit the GSoC mentor summit. In other years, we'd have two. Flow asks if XSF is willing to reimburse the travel costs of all three mentors (as opposed to only the regular 2). He mentions that travel costs will be relatively low (mentors are largely in the same country as where the event venue is), and that the Google stipend that the XSF received will cover the costs.

  555. Guus

    To repeat what I typed a short while ago: > In short, Flow writes that we have 3 mentors that will visit the GSoC mentor summit. In other years, we'd have two. Flow asks if XSF is willing to reimburse the travel costs of all three mentors (as opposed to only the regular 2). He mentions that travel costs will be relatively low (mentors are largely in the same country as where the event venue is), and that the Google stipend that the XSF received will cover the costs.

  556. moparisthebest has joined

  557. flow

    I see no reason why we shouldn't reimburse the travel costs for all three mentors FWIW.

  558. Guus

    You asked, so i'm putting it to board 🙂

  559. adiaholic has left

  560. adiaholic has joined

  561. Guus

    I have no issue with reimbursing the travel costs for all mentors, provided that the total remains at or under the stipend we got from Google.

  562. Guus

    (i'd not mind paying slightly more, to be perfectly clear - but as that doesn't appear to be needed anyway, let's not discuss that)

  563. MattJ

    I'm in favour

  564. nyco

    sorry... I'm back

  565. nyco is reading

  566. Seve

    I'm done

  567. Seve

    Yes, makes perfect sense to me

  568. Seve

    I mean, I'm also on the "ok" side

  569. Guus

    Let me put it to a vote then: I'l motion that the XSF offers to reimbursre travelling costs for all three GSoC mentors of this year, to attend the GSoC Mentor summit, provided that the total costs are not more than the stipend that the XSF received from Google."

  570. Guus


  571. MattJ


  572. Seve


  573. nyco

    > I see no reason why we shouldn't reimburse the travel costs for all three mentors FWIW. I see lots of reasons why we should reimburse! :)

  574. nyco

    double negative sucks! :)

  575. Seve


  576. Guus

    +1 then, nyco ? 🙂

  577. nyco


  578. Guus

    motion passed.

  579. nyco has finished reading

  580. Guus

    flow can you make sure the mentors are aware of this?

  581. Guus

    Moving on...

  582. Guus

    2.2 Invite & Provide stipend for GSoC students to visit the XSF Summit

  583. flow

    Guus, will do

  584. nyco

    the coma is important here

  585. Guus

    we started doing this in 2017, I think: we offered a 150 euro stipend for the that-year student to visit the XSF summit.

  586. nyco

    and Thx Daniel for the minutes! :)

  587. Guus

    in 2017, I wrote this invitation to the three students we had that year: > the XSF offers to each of you a reimbursement of up to 150 euro for costs that you have in relation to them if you would like to attend either (or both) of these events. This offer could, for instance, be used to cover some of your travelling or hotel expenses.

  588. Guus

    I'd like to offer the same thing to this years students.

  589. Guus

    The rationale being the same is then: as the XSF, we should try to attract new people to get involved with XMPP. These students are perfect candidates for that.

  590. Guus

    (the events mentioned in the text that I quotes are the XSF Summit and FOSDEM).

  591. Guus


  592. Seve

    I think it has been very positive thing to do, hasn'it it?

  593. nyco

    it was, at least for me

  594. Guus

    I'm unsure if we had students this year (I think we did offer, but I'm unsure if someone took it up)

  595. MattJ

    Guus, I'm definitely in favour of offering to this year's students

  596. Guus

    but I was very happy to see Paul (now a member) and Pawel (continues to be an XMPP contributor to the Ignite Realtime community) the year before!

  597. Guus

    Ok, let me put this to a vote then

  598. nyco

    yes, please

  599. Guus

    I'm motioning that the XSF offers a 150 euro reimbursement to each of this years GSoC students, to be used by them to cover any costs associated to them visiting the XSF Summit and / or Fosdem in early 2020.

  600. nyco


  601. Seve


  602. nyco

    not "or", but "and" in "Summit and FOSDEM"

  603. MattJ


  604. Guus

    I don't want to make them attend both, if they can't

  605. MattJ

    "and/or", a great construction

  606. Guus

    if they're going to show up for either, that'd be a win

  607. Guus

    and they'd likely show up in both.

  608. Guus

    nyco, can you accept "and/or", or do you insist on "and"?

  609. Guus

    I'd +1 that too, but i'd prefer "and/or".

  610. Seve


  611. nyco

    just a joke, I voted +1

  612. Guus

    +1 for me too

  613. Guus

    motion passes.

  614. Guus

    2.3 News from the newsletter

  615. Chobbes has left

  616. Guus

    nyco I'm guessing this is yours?

  617. nyco


  618. nyco

    just FYI

  619. nyco

    JC has done a great job on the newsletter

  620. nyco

    I wanted to give justice

  621. adiaholic has left

  622. pep.

    (Our student (poezio) is in india btw)

  623. nyco


  624. Guus

    justice given.

  625. nyco

    the growth is awesome

  626. Guus

    Thank you to you for taking over, nyco

  627. nyco

    card can be archived

  628. Seve

    That is just... great :D

  629. Seve

    Thank you for sharing!

  630. nyco


  631. Guus

    moving on

  632. Guus

    3 Commitments for week ahead

  633. Guus

    3.1 Contact mray to confirm chosen Badge design

  634. Guus

    this is a shared commitment for Ralph and me.

  635. Guus

    mray asked for a list of possible badge combinations, which I compiled for him. I left the list in the trello item, assuming that Ralph would forward it

  636. Guus

    I'm unsure if anything happened beyond that.

  637. Guus

    I'll take this up with Ralph after the meeting.

  638. Guus

    I don't think there's more to add to that now, is there?

  639. Seve

    I don't think so

  640. Guus

    3.2 Review of Roadmap page

  641. Guus

    This one is Ralphs too. Let's wait for him to give feedback on this.

  642. Guus

    4 Items for discussion

  643. adiaholic has joined

  644. Guus

    4.1 GSoC '19 has ended - do we want to evaluate?

  645. Chobbes has joined

  646. nyco

    evaluate what and how?

  647. pep.

    I'm open to discussion re gsoc

  648. Guus

    At the very least, I'd like to celebrate successes, if there were any.

  649. nyco

    celebrate anyway

  650. nyco

    get feedback from participants: student and mentors that would be nice

  651. pep.

    Yes! Poezio got MAM support (a big chunk of it, still some bits being refactored here and there)

  652. Guus

    also, I'd like to discuss the process - especially as this year was the first time that flow took the lead in things.

  653. MattJ

    I'd like to thank flow for everything, things went very smoothly :)

  654. nyco

    yeah, thx flow!

  655. pep.

    Indeed, thanks

  656. Guus

    I'm thinking flow is doing other things. I'd like to ask him if he feels the need to discuss things, and if not, at least share a short summary of this years involvement.

  657. Kev

    I think we usually try to do a blog post about the summer.

  658. Guus

    That's not the worst idea.

  659. Seve

    That would be perfect thing to also mention on the newsletter

  660. nyco

    content: good

  661. nyco

    each participant could do a blog post, even a small one is better than nothing

  662. Guus

    students have been blogging weekly

  663. nyco

    yes, from them I would expect some kind of summary/synthesis

  664. Guus

    (but we failed to include that on our blog)

  665. nyco

    we mentionned these blog posts briefly on the newsletter

  666. Guus

    nyco, do you want to take this up with Flow, with our commsteam hat on?

  667. nyco

    why not

  668. Guus

    I don't know why not 🙂

  669. Guus

    but I thought it'd be polite to ask.

  670. Guus

    we're running over time. I'd like to conclude the meeting.

  671. Guus

    5. AOB

  672. Guus


  673. Seve

    None here

  674. nyco


  675. MattJ

    None here

  676. COM8 has joined

  677. Seve

    Apart from: Great to have things done :D

  678. Guus

    6 Time / date of next

  679. nyco

    yep, feels good

  680. Guus

    I can't make it next week, but don't let that stop you.

  681. Guus


  682. MattJ

    Next week wfm

  683. Guus bangs the gavel

  684. nyco

    thx all!

  685. Seve

    Awesome, thank you very much all, special thanks to Guus for chairing and Daniel for volunteering with the minutes :)

  686. nyco

    thanks to Seve for thanking everyone! :)

  687. Seve


  688. jabberjocke has left

  689. COM8 has left

  690. Chobbes has left

  691. eevvoor has left

  692. Guus

    I like how ralphm is not here for just one, and the rest of us immediately spend all of the money that we have. 😉

  693. Guus

    I like how ralphm is not here for just once, and the rest of us immediately spend all of the money that we have. 😉

  694. pep.

    Is it possible to query the XSF (financial) accounts?

  695. Guus

    pep. I was kidding, we have plenty of cash to cover this

  696. adiaholic has left

  697. pep.


  698. andy has left

  699. zach has left

  700. Guus

    "this" is "the spendings that we committed to in todays board meeting"

  701. pep.

    Because if it's possible I'd like to at least propose to our student in India as well, if he's interested. What has been voted today is great, but only covers transportation for people close enough

  702. Guus

    Peter, the Treasurer, actually keeps board up-to-date with the state of the financials.

  703. Guus

    so there's no worry there.

  704. pep.

    I'm not worried, I'm just interested to know. We don't seem to spend much money apart from that one diner once a year (why??)

  705. pep.

    So either we don't have money, which I doubt, or it's dormant

  706. Guus

    pep. although I'm sympathetic, it might be difficult to make a judgement that's fair here.

  707. pep.

    Depends how you define fair :P

  708. Guus

    well, exactly. That differs for everyone.

  709. Guus

    pep. I propose that you make a specific proposal and put that to board.

  710. Andrew Nenakhov has joined

  711. Guus

    The amount of money in the bank account has been pretty stable.

  712. pep.

    With the sponsors we have?

  713. Guus

    We got some new ones this year, but I'm not sure if we have more spendings.

  714. Guus

    I'm actually not sure if I can elaborate - I don't see why not, but I don't want to run my mouth 🙂

  715. pep.

    I'm curious why all this is private tbh

  716. Guus

    I'm not sure if it is

  717. Guus

    but I"m not sure if it is not 🙂

  718. pep.


  719. Guus

    I'll ask Peter.

  720. Andrew Nenakhov has left

  721. APach has left

  722. david has left

  723. Guus

    pep. i've sent off a quick email. I'll keep you in the loop if I remember to do that - feel free to ping me again about this.

  724. pep.


  725. Guus

    no problem

  726. zach has joined

  727. Kev

    I've seen the balance of the accounts before, so I don't think it can be privileged.

  728. Guus

    I'll ask Peter - maybe we can properly publish something for everyone to see

  729. Guus

    and get what we can more in the open.

  730. pep.

    That'd be great :)

  731. kokonoe has joined

  732. APach has joined

  733. Guus

    I'm guessing that things like this just died down a little, with lack of interest.

  734. Guus

    but that there's no reason to actually keep things confidential.

  735. flow

    There was a time where the XSF financials where regulary blogged about

  736. Guus

    But like I said, I'd like to check that.

  737. david has joined

  738. Daniel

    Does anyone remember the order of magnitude we are talking about here?

  739. Daniel

    Because I have no clue

  740. flow

    and thanks for your gsoc feedback, much appreciated :)

  741. Guus

    low to medium five digits, iirc

  742. Daniel

    Guus: thanks

  743. kokonoe has left

  744. Kev

    Last I remember was the sort of $15-$25k IIRC, but it was years ago.

  745. winfried has left

  746. winfried has joined

  747. jabberjocke has joined

  748. kokonoe has joined

  749. Nekit has left

  750. kokonoe has left

  751. Nekit has joined

  752. andy has joined

  753. kokonoe has joined

  754. kokonoe has left

  755. kokonoe has joined

  756. kokonoe has left

  757. kokonoe has joined

  758. Chobbes has joined

  759. kokonoe has left

  760. kokonoe has joined

  761. adiaholic has joined

  762. pdurbin has joined

  763. adiaholic has left

  764. Zash

    dwd, jcbrand, in XEP-0402 boomarks 2 there is no mention of how PEP nodes will likely default to max items = 1, which you probably wanna do something about

  765. eevvoor has joined

  766. dwd

    Zash, Give the XEP its full name, at least.

  767. Zash

    I'm going to have to write a bot that expands XEP names at some point

  768. Zash

    dwd, but this time, it *is* serious!

  769. Chobbes has left

  770. Chobbes has joined

  771. adiaholic has joined

  772. COM8 has joined

  773. ralphm

    Guus: let it rain

  774. pdurbin has left

  775. eevvoor has left

  776. COM8 has left

  777. Guus


  778. Guus

    ralphm: ok.

  779. zach has left

  780. zach has joined

  781. Zash

    Plz it just stopped

  782. ths has left

  783. ths has joined

  784. Chobbes has left

  785. Chobbes has joined

  786. COM8 has joined

  787. aj has left

  788. ralphm

    Argh, I wanted to say: make it rain. Never mind.

  789. Chobbes has left

  790. kokonoe has left

  791. Chobbes has joined

  792. dwd

    make: *** No rule to make target 'it'. Stop.

  793. Zash

    bmake: don't know how to make it. Stop

  794. adiaholic has left

  795. kokonoe has joined

  796. adiaholic has joined

  797. wurstsalat

    Zash, doesn't the conversations muc have one?

  798. wurstsalat

    > I'm going to have to write a bot that expands XEP names at some point

  799. pep.

    does it?

  800. wurstsalat

    I think it did at some point

  801. Daniel


  802. Daniel

    we just have smart people who know the xeps by heard

  803. Kev

    At Isode we've got a bot in the (XMPP) chat rooms that just injects XEP details when they get mentioned, based on my old sleekbot stuff updated for Sluift-based stuff.

  804. adiaholic has left

  805. adiaholic has joined

  806. Zash

    But does it use attaching or references or fasten?

  807. Kev

    It should use references, which will use fasten once I update it. But currently it doesn't, no.

  808. kokonoe has left

  809. APach has left

  810. APach has joined

  811. Chobbes has left

  812. jubalh has left

  813. kokonoe has joined

  814. eevvoor has joined

  815. Chobbes has joined

  816. Wojtek has joined

  817. Ge0rG

    Kev: it should also attach the references to the original.

  818. Kev


  819. Ge0rG

    I have a client that will hotlink XEP-####

  820. jcbrand has left

  821. Wojtek has left

  822. zach has left

  823. lovetox has joined

  824. kokonoe has left

  825. kokonoe has joined

  826. adiaholic has left

  827. zach has joined

  828. eevvoor has left

  829. adiaholic has joined

  830. COM8 has left

  831. arc has left

  832. arc has joined

  833. david has left

  834. david has joined

  835. andy has left

  836. andy has joined

  837. winfried has left

  838. Syndace has left

  839. Syndace has joined

  840. winfried has joined

  841. winfried has left

  842. winfried has joined

  843. moparisthebest has left

  844. j.r has left

  845. goffi has left

  846. j.r has joined

  847. marc_ has left

  848. arc has left

  849. arc has joined

  850. arc has left

  851. arc has joined

  852. COM8 has joined

  853. COM8 has left

  854. pdurbin has joined

  855. moparisthebest has joined

  856. Dele (Mobile) has left

  857. Steve Kille has left

  858. Steve Kille has joined

  859. Dele (Mobile) has joined

  860. arc has left

  861. arc has joined

  862. pdurbin has left

  863. Dele (Mobile) has left

  864. Dele (Mobile) has joined

  865. Dele (Mobile) has left

  866. Dele (Mobile) has joined

  867. Chobbes has left

  868. Chobbes has joined

  869. Chobbes has left

  870. Chobbes has joined

  871. remko has joined

  872. winfried has left

  873. winfried has joined

  874. linkmauve has left

  875. linkmauve has joined

  876. moparisthebest has left

  877. Nekit has left

  878. winfried has left

  879. winfried has joined

  880. adiaholic has left

  881. jabberjocke has left

  882. adiaholic has joined

  883. Daniel has left

  884. Yagiza has left

  885. Daniel has joined

  886. zach has left

  887. adiaholic has left

  888. Daniel has left

  889. zach has joined

  890. Daniel has joined

  891. APach has left

  892. sonny has left

  893. moparisthebest has joined

  894. j.r has left

  895. j.r has joined

  896. APach has joined

  897. adiaholic has joined

  898. adiaholic has left

  899. remko has left

  900. Dele (Mobile) has left

  901. APach has left

  902. pdurbin has joined

  903. goffi has joined

  904. goffi has left

  905. goffi has joined

  906. goffi has left

  907. goffi has joined

  908. goffi has left

  909. goffi has joined

  910. goffi has left

  911. goffi has joined

  912. goffi has left

  913. goffi has joined

  914. goffi has left

  915. goffi has joined

  916. goffi has left

  917. goffi has joined

  918. goffi has left

  919. goffi has joined

  920. goffi has left

  921. goffi has joined

  922. lovetox

    ok i googled "fasten"

  923. lovetox

    was this only used because Attaching was already used?

  924. pep.

    never heard of "fasten your seatbelt"? :P

  925. pep.

    I guess so

  926. lovetox

    yeah actually thats the only situation i heard that ever

  927. lovetox

    but yeah forgot about that, now that you say it

  928. moparisthebest

    call it Attareferastench

  929. moparisthebest


  930. pdurbin has left

  931. Nekit has joined

  932. remko has joined

  933. mr.fister has joined

  934. jonas’

    I’m also not convinced this is a particularly great name

  935. jonas’

    or terminology

  936. jabberjocke has joined

  937. zach has left

  938. zach has joined

  939. remko has left

  940. eevvoor has joined

  941. j.r has left

  942. Ge0rG

    I'm sure we can get rid of Attaching and reuse the name

  943. eevvoor has left

  944. LNJ has left

  945. jabberjocke has left

  946. jabberjocke has joined

  947. j.r has joined

  948. Steve Kille has left

  949. marc_ has joined

  950. j.r has left

  951. j.r has joined

  952. Lance has joined

  953. zach has left

  954. zach has joined

  955. winfried has left

  956. winfried has joined

  957. marc_ has left

  958. lovetox has left

  959. pdurbin has joined

  960. remko has joined

  961. Steve Kille has joined

  962. pdurbin has left

  963. marc_ has joined

  964. neshtaxmpp has left

  965. Steve Kille has left

  966. Steve Kille has joined

  967. remko has left

  968. linkmauve has left

  969. adiaholic has joined

  970. xalek has left

  971. Lance has left

  972. remko has joined

  973. zach has left

  974. zach has joined

  975. winfried has left

  976. winfried has joined

  977. adiaholic has left

  978. remko has left

  979. wurstsalat has left

  980. xalek has joined

  981. winfried has left

  982. winfried has joined

  983. winfried has left

  984. winfried has joined

  985. Chobbes has left

  986. Tobias has left

  987. winfried has left

  988. winfried has joined

  989. winfried has left

  990. winfried has joined

  991. Wojtek has joined

  992. Wojtek has left

  993. Lance has joined

  994. j.r has left

  995. j.r has joined

  996. zach has left

  997. zach has joined

  998. goffi has left

  999. alameyo has left

  1000. alameyo has joined

  1001. Mikaela has left

  1002. j.r has left

  1003. j.r has joined

  1004. Zash has left

  1005. Zash has joined

  1006. alameyo has left

  1007. j.r has left

  1008. j.r has joined

  1009. alameyo has joined

  1010. Wojtek has joined

  1011. Wojtek has left

  1012. neshtaxmpp has joined

  1013. andy has left

  1014. zach has left

  1015. zach has joined

  1016. alameyo has left

  1017. alameyo has joined

  1018. pdurbin has joined

  1019. alameyo has left

  1020. karoshi has left

  1021. alameyo has joined

  1022. Wojtek has joined

  1023. Wojtek has left

  1024. UsL has left

  1025. UsL has joined

  1026. arc has left

  1027. arc has joined

  1028. pdurbin has left

  1029. j.r has left

  1030. j.r has joined

  1031. j.r has left

  1032. j.r has joined