XSF logo 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 Indeed
  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’ +1
  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’ oh?
  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 Dude
  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 Heh.
  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 Huh?
  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 Exactly
  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 yes.
  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 Undefined.
  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 Right
  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 Yes.
  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’ hmmm
  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’ hmm
  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 No.
  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 hey
  514. Guus ola
  515. Guus ralphm Seve MattJ ?
  516. Guus uh-oh.
  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 Hey
  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 _o/
  535. Guus As usual, the agenda is driven by Trello
  536. Guus https://trello.com/b/Dn6IQOu0/board-meetings
  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 Who?
  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 +1
  571. MattJ +1
  572. Seve +1
  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 Haha
  576. Guus +1 then, nyco ? 🙂
  577. nyco +1
  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 Thoughts?
  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 +1
  601. Seve +1
  602. nyco not "or", but "and" in "Summit and FOSDEM"
  603. MattJ +1
  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 Great!
  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 yep
  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 https://trello-attachments.s3.amazonaws.com/5d6e5d8116c843171be2a368/1120x420/068b7f8cb081fb7b2487da4abd8e9643/Capture_d’écran_2019-09-03_à_14.32.52.png
  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 yes
  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 anyone?
  673. Seve None here
  674. nyco nope
  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 +1W
  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 :D
  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. this?
  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. k
  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. thanks
  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 https://igniterealtime.org:443/httpfileupload/bfc8728a-f5fb-4e11-868e-b3771dd7f44a/GkQG0BZ0TAe1LslOiO7I5Q.jpg
  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 na
  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 Yes.
  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 compromise
  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