XSF Discussion - 2019-08-29

  1. rion has left
  2. pdurbin has joined
  3. pdurbin has left
  4. aj has joined
  5. zach has left
  6. zach has joined
  7. UsL has left
  8. UsL has joined
  9. lskdjf has left
  10. zach has left
  11. zach has joined
  12. pdurbin has joined
  13. zach has left
  14. zach has joined
  15. pdurbin has left
  16. adityaborikar has left
  17. adityaborikar has joined
  18. david has left
  19. zach has left
  20. zach has joined
  21. arc has left
  22. arc has joined
  23. pdurbin has joined
  24. Yagiza has joined
  25. afrogeek has left
  26. arc has left
  27. arc has joined
  28. pdurbin has left
  29. arc has left
  30. arc has joined
  31. pdurbin has joined
  32. zach has left
  33. zach has joined
  34. david has joined
  35. Maranda has left
  36. Maranda has joined
  37. andy has joined
  38. arc has left
  39. arc has joined
  40. arc has left
  41. arc has joined
  42. zach has left
  43. zach has joined
  44. pdurbin has left
  45. rion has joined
  46. pdurbin has joined
  47. ralphm Ge0rG: how so?
  48. Nekit has joined
  49. APach has joined
  50. LNJ has joined
  51. pdurbin has left
  52. j.r has left
  53. jabberjocke has joined
  54. LNJ has left
  55. sezuan has joined
  56. UsL has left
  57. adityaborikar has left
  58. karoshi has joined
  59. Alex has left
  60. Alex has joined
  61. jonas’ has joined
  62. sezuan has left
  63. Ge0rG ralphm: it allows the server operator to derive the user's screen time in the xmpp client
  64. ralphm That has almost nothing to do with the GDPR.
  65. UsL has joined
  66. ralphm And if it has, there's legitimate interest for processing this information, namely for ensuring a particular feature. Actively using it to track screen time, rather than temporarily stalling traffic, however, would require permission.
  67. ralphm Finally, servers don't have control over why/when clients send CSI hints, and the specification leaves that entirely up to clients.
  68. sezuan has joined
  69. Steve Kille has left
  70. jabberjocke has left
  71. jabberjocke has joined
  72. sezuan has left
  73. Steve Kille has joined
  74. adiaholic has joined
  75. adiaholic has left
  76. adiaholic has joined
  77. pdurbin has joined
  78. zach has left
  79. zach has joined
  80. wurstsalat has joined
  81. Ge0rG ralphm: so "using it to track screen time" is the actual issue, yes. Also it's got potential implications in enterprise setups, where unions are very keen on not allowing anybody to measure the employees' activity times
  82. ralphm I understand completely, but that's not what CSI's purpose is. If you continue in that direction, there are many activities one could theoretically track to do that.
  83. adiaholic has left
  84. ralphm Now, if there was a dedicated protocol to explicitly relay user activity stats, that'd be different.
  85. Ge0rG Yeah, but data collection is not solely about the original purpose of the data
  86. ralphm There is difference in processing for legitimate purposes, processing it for analytics, combining it with other data, etc.
  87. ralphm And then if you store it, there are also concerns around retention and deletability.
  88. ralphm I personally think that the issue as you describe it is not a GDPR issue, unless the server is processing the information for more than the purpose of minimizing battery use.
  89. Ge0rG This is getting similar to the discussion we had about the clarification of stored message content
  90. Ge0rG ralphm: I agree with that
  91. ralphm Well yeah, there, if you agreed that the server keeps an archive for you, then that's fine.
  92. APach has left
  93. ralphm And public channels have a clear way of finding this out before joining.
  94. Nekit has left
  95. Nekit has joined
  96. Ge0rG ralphm: the question was whether the content is PII or even special category PII
  97. ralphm PII is an old term not valid for GDPR discussions. There, we have Personal Information, and that's broader than the US term.
  98. jonas’ and article 9.1 stuff
  99. ralphm Personal Data, I mean
  100. Ge0rG ralphm: oh, I wasn't aware those are different things
  101. ralphm Ge0rG: oh yeah
  102. jabberjocke has left
  103. pdurbin has left
  104. APach has joined
  105. ralphm Even if you, for example, have a unique identifier for a person, linked to some data, but you don't know who that is, that's still considered Personal Data.
  106. ralphm So often, just anonimising might not be sufficient.
  107. murabito has left
  108. Ge0rG ralphm: the question was whether the content is Personal Information or even Special Categories of Personal Information
  109. murabito has joined
  110. ralphm Well, I think in this case, since the purpose of the protocol is not at all about knowing if somebody's screen is on, you don't get to the special categories. Especially since the server cannot know in which cases the client is going to send it.
  111. ralphm In principle CSI just says: hold that thought until I say when.
  112. Ge0rG ralphm: but you know the client implementation from disco#info, and you can derive those things
  113. jonas’ yes, but that is being actively evil
  114. jonas’ purposes and such
  115. ralphm Right
  116. jonas’ you *can* do it, but as long as you don’t, you’re fine
  117. ralphm E.g. not storing / logging it would be a good start
  118. murabito has left
  119. murabito has joined
  120. ralphm In any case of doubt, by the way, talk to lawyers.
  121. jonas’ -ENOLAWYER
  122. jonas’ lawyers are expensive
  123. Ge0rG ralphm: lawyers are there to _increase_ your doubt
  124. ralphm jonas’, Ge0rG seems concerned about corporations, they (should) have lawyers as well as data protection officers.
  125. ralphm Usually it is about three things: purpose, consent, and retention.
  126. ralphm I've learned that engineers, including myself, generally don't have sufficient legal knowledge to make proper assertions in this area.
  127. ralphm But I learned quite a bit over the last few years.
  128. jonas’ ralphm, if that was true, the result would effectively be that we have to shut down all operations (free jabber servers and possibly even software development) right now.
  129. jonas’ except maybe daniel, because he might be able to afford a lawyer
  130. Ge0rG While being an engineer as well, I've been doing a large chunk of GDPR consulting in the last two years or so
  131. ralphm jonas’: there are totally things an engineer can do: log as little as possible, or at least not continuously of you're not debugging an issue, only process information for the stated purpose, give control over retention, inform about what is stored/processed.
  132. eevvoor has joined
  133. ralphm Ge0rG: I'm not saying you have to be a lawyer. I said 'generally' and 'when in doubt'.
  134. Ge0rG ralphm: right
  135. jonas’ hooking into the silence: I was thinking that we might want to set up a mentoring process for first-time XEP authors
  136. jonas’ and I’d volunteer right away to be a mentor to those
  137. jonas’ my main issue is with how to present this
  138. jonas’ and where
  139. jonas’ i.e. how to make people make use of that?
  140. Seve How that would be? would it be a document with guidelines and so? (It is a very good idea by the way)
  141. ralphm Well, getting in contact with an Editor before/during submission seems like a good first step in general.
  142. Ge0rG jonas’: I'd suggest adding a paragraph for prospective authors at https://xmpp.org/extensions/
  143. Ge0rG maybe linking to a wiki page that you maintain, listing best practices and mentors
  144. jubalh has joined
  145. ralphm XEPs 0143 and 0134 should be good starting points to highlight, as is XEP-0001.
  146. jonas’ none of those is a good starting point
  147. jonas’ sorry, but no
  148. ralphm Why?
  149. jonas’ they describe processes from the inside, not from the outside
  150. jonas’ I think?
  151. jonas’ something like that
  152. jonas’ there is a lot of information in there, but a lot of that also does not matter for when you’re first writing a XEP
  153. ralphm That doesn't make sense to me.
  154. ralphm How does it not matter?
  155. jonas’ I’m trying to formulate what I mean
  156. jonas’ I mean, those documents are nice and all to get your document in a reasonable state, but I don’t think they deal well with the experience a newcomer has or might have when submitting a XEP while not having had a lot to do with the community before
  157. Vaulor Aixo es el que vull veure
  158. ralphm Vaulor: English, please.
  159. jonas’ ralphm, the mentorship things would be about the non-technical parts of the stuff, really. What interactions to expect on the mailinglist? How to properly process feedback? What to do with a rejection by council?
  160. jonas’ none of that is, to my knowledge, clear from the XEPs you mentioned
  161. Seve Vaulor, hah, wrong tab, right? :D
  162. ralphm jonas’: right, I think that the suggestion by Ge0rG is a great one, except a proper page on the website itself would be nice. Noting some initial tips, suggestion to get mentorship with Editors, and then reference those XEPs as formal procedures and detailed guidance.
  163. Vaulor Yup, sorry wrong tab indeed
  164. Ge0rG a "proper" page is fine with me
  165. ralphm Vaulor: 🙃
  166. sezuan has joined
  167. eevvoor has left
  168. Mikaela has joined
  169. Douglas Terabyte has left
  170. Douglas Terabyte has joined
  171. ralphm jonas’: in any case: yay, go for it
  172. zach has left
  173. zach has joined
  174. jonas’ context: the Message Reactions XEP, I think the silence from the authors speaks for itself. I tried to reach out to them yesterday, no reply yet though.
  175. Daniel jonas’, what part about the process is unclear wrt to the reactions xep?
  176. adiaholic has joined
  177. Dele (Mobile) has joined
  178. ralphm Daniel: it is entirely unclear to me why it hasn't been accepted (yet?)
  179. jonas’ Is your question still open after reading this, Daniel? > 07:33:30 jonas’> ralphm, the mentorship things would be about the non-technical parts of the stuff, really. What interactions to expect on the mailinglist? How to properly process feedback? What to do with a rejection by council?
  180. jonas’ right, I don’t think the rejection was made clear and public in the thread even.
  181. jonas’ that’s something council should probably work on
  182. jonas’ (or maybe the editor)
  183. Daniel > Daniel: it is entirely unclear to me why it hasn't been accepted (yet?) yes. i kinda understand that. but that what raises the question on how 'mentorship of authors' can help with that
  184. edhelas has left
  185. edhelas has joined
  186. larma has left
  187. Daniel jonas’, i'm personally not really under the impression that the authors (of that particular xep) need help with any of these points
  188. ralphm Daniel: so was it indeed rejected? Where can I see this? I tried looking at the recent vote tallies and yesterday's meeting logs
  189. mathieui the council on reactions was one month ago, I think?
  190. Mikaela has left
  191. Mikaela has joined
  192. ralphm Why was it on the agenda (item 5) for yesterday's meeting then?
  193. Daniel wasn’t that retractions?
  194. ralphm Oh wait that agenda was an older one. Sorry
  195. mathieui actually that was exactly one month ago
  196. ralphm I see now that Kev vetoed it
  197. Ge0rG don't confuse reactions, retractions and references with each other.
  198. larma has joined
  199. ralphm I found the minutes of that meeting: https://mail.jabber.org/pipermail/standards/2019-August/036345.html
  200. Dele (Mobile) has left
  201. Dele (Mobile) has joined
  202. Ge0rG this is where "post-factum mail tagging" could come in useful
  203. Kev ralphm: I followed that up with a long mail to the list with an offer to do the needful myself to remove my veto. Although that time has probably now passed as I had the cycles then and don't now.
  204. ralphm Well, maybe having explicit, separate, rejection notifications would help here. I thought we had that done before, or suggested, but I missed this.
  205. Kev Which is about as good as Council can do, I think.
  206. jonas’ re XEP-0353: 15:17:20 dwd> I'm +1 for this. Seems widely deployed and sensible. Daniel claims otherwise on-list. Fight!
  207. ralphm Right, I am looking for that mail
  208. ralphm Oh, crap, it was buried in the thread of the initial submission. Sorry, Kev
  209. flow A pitty that we only require two implementations before a xep can advance only for 'final'
  210. ralphm flow: because we have that problem a lot?
  211. Daniel so reactions passed?
  212. ralphm Daniel: no
  213. flow ralphm: the problem that xeps advance without much implementation experience nor feedback? I think so
  214. ralphm flow: we were talking about accepting XEPs in the the first place.
  215. flow ralphm, I was responding to jonas' comment regarding xep353
  216. ralphm Which moved to Draft, right?
  217. mathieui Daniel, vetoed on list by Kev
  218. flow and regarding accepting XEPs: I really think we are missing a IETF I-D equivalent. Where people can just create a stable home for their ProtoXEP to work on
  219. ralphm I don't see why that's a problem. I have concerns about XEP-0353, but it is not set in stone.
  220. ralphm flow: we do, it is called proto xep
  221. ralphm And also
  222. Nekit has left
  223. flow ralphm, I'd argue we do not
  224. Daniel ralphm, you can’t really edit a protoxep tho?
  225. Daniel or can I? maybe i should try
  226. Nekit has joined
  227. flow Daniel, it's not really specified or at least promoted that you can
  228. ralphm Generally council should accept those. I understand that Kev tried to prevent chaos by not accepting Reactions at this stage, but I am not sure I agree.
  229. flow I guess you could PR against XEPs in inbox
  230. flow But if this is encouraged then we should promote it more
  231. flow Otherwhise establish something like xmpp.org/extensions/protoxeps/my-kewl-new-xep.html
  232. flow where authors could PR against without much review
  233. Daniel because I actually wanted to edit the aesgcm uri scheme one
  234. Daniel so let me try that and see what happens
  235. flow go for it :)
  236. ralphm If a XEP is not accepted, an author is encouraged to address the feedback. I don't see how you can have it reevaluted without submitting a new version to the inbox.
  237. ralphm Re-evaluated
  238. ralphm But again, I think in general most of this should happen in experimental.
  239. Kev ralphm: I note that Kev didn't really 'not accept' in practical terms, given that he was ready to make the changes right away so it could be resubmitted.
  240. ralphm I believe the concern with reactions specifically is that seems undesirable to have this end up in production clients in its current state
  241. Daniel the expected quality for an experimental xep varies between councils and moods
  242. flow What if I want to develop a protoxep without submitting it right away? Could I simply PR it into inbox?
  243. ralphm Kev: I appreciate that of course, but the end result now is limbo?
  244. Kev Yes, I wasn't anticipating the authors not taking me up on the offer.
  245. Daniel > I believe the concern with reactions specifically is that seems undesirable to have this end up in production clients in its current state I'm not sure that blocking it from becoming experimental will help that
  246. ralphm flow: eh, that's a good question
  247. Daniel i'd implement reactions now if it weren’t for other problems in Conversations
  248. flow Daniel, it probably does not prevent it, but then again, what's the gain for having it accepted if it does not prevent it?
  249. ralphm Kev: I don't notice that offer, so maybe they haven't either? Maybe we should make non-acceptance notifications explicitly a new thread.
  250. ralphm Didn't
  251. ralphm Daniel: even given the concerns?
  252. flow And why not raise the bar a little bit for experimental to not accept XEPs with issues *and* a solution?
  253. Daniel flow, that is an interesting question. probably stable home + discoveribility
  254. flow Daniel, well you could argue that stable home is already extensions/inbox/reactions.xml
  255. flow err .html
  256. flow And I'd say that it is a feature that it is, in its current state, not easily discoverable
  257. ralphm We've had tried discussion before, I think Experimental is that state, and adding another one just moves names around.
  258. Daniel ralphm, what if i don’t share the concerns? (to be clear we are talking very hypothetical here because i'm not going to implement it anyway any time soon)
  259. Daniel but i can see the point of 'my users want this now and it is good enough for me and i don’t want to wait for the very complex problem of archive message collapsing to be solved beforehand'
  260. debacle has joined
  261. ralphm I agree with Kev that there are issues, I don't like that we now have a proposal with issues that is not Expirimental and now people can't, you know, experiment. I also think it would be bad to have in production clients with the expectance of large changes, but YOLO.
  262. Daniel but if experimental is that state than reactions shouldn’t have been blocked?
  263. ralphm ^
  264. Nekit has left
  265. Daniel > I also think it would be bad to have in production clients with the expectance of large changes I agree but i don’t think the xsf should try to prevent that
  266. Daniel because it won’t be able to anyway
  267. Daniel and the attempt has other problems
  268. Nekit has joined
  269. Daniel also 'experimental' comes with the warning of 'do not use this in production'
  270. ralphm My concerns: 1) Unclear what ids should be used, and if that works properly in all cases, particularly in MUCs. Document doesn't state it, and the single example seems to use the original stanza id. 2) Interaction with MAM. There are various situations where you can retrieve message from the archive without having the referred message. 3) There should likely be a summary/counts feature. 4) I'm not sure if I like the way updates are done.
  271. flow I still wonder why nobody hasn't simply wrote a quick "Reference Other Stanza" XEP, doesn't appear to hard. And would probably kickoff the discussion and steer it hopefully into the right direction
  272. ralphm Daniel: I agree that the XSF shouldn't block stuff implemented in clients when in experimental. I just think it is not a great idea. And I also think that we may need to move a bunch of things from Experimental to Draft.
  273. pdurbin has joined
  274. mathieui flow, that’s kind of 367 though?
  275. zach has left
  276. zach has joined
  277. mathieui (except 367 is not enough for reactions)
  278. flow mathieui, possibly, but I think it is broken
  279. flow mathieui, why is it not enough for reactions?
  280. Daniel ralphm, https://dino.im/xeps/reactions.html#business-id?
  281. ralphm indeed, XEP-0367 would need some work, and maybe a rename, but this was discussed here before as a possible basis.
  282. Daniel regarding (1)
  283. ralphm Daniel: is this a progression on the not-accepted specification
  284. ralphm ?
  285. Daniel ralphm, oh tbh i didn’t check
  286. ralphm Well, I don't think it is wise to discuss alternative documents that aren't somehow covered by our IPR
  287. ralphm policy
  288. Daniel i wasn’t aware that the documents didn’t match
  289. flow Another argument to establish an I-D equivalent for XEPs
  290. Daniel that link was just the first one to shop up in my browser history
  291. adiaholic has left
  292. mathieui flow, no support for updating or removing an element
  293. mathieui Daniel, the documents are strictly identical as far as I can tell
  294. Kev See, I was really thinking that what I was doing was the pragmatic thing to do that a) Got the XEP published ASARP b) Got us to a state where further XEPs could do consistent things c) It wouldn't be obviously harmful to have in production clients.
  295. ralphm Daniel: they don't seem to be different. And what I meant is that it is a bit vague even with that text. More examples would help.
  296. Kev I wasn't expecting it to end up with the protoXEP being abandoned instead.
  297. Kev I thought the outcome would be that the XEP got accepted a fortnight later, in a much better state.
  298. Daniel ralphm, sure. there are things that can and should be improved.
  299. mathieui pings larma about it
  300. ralphm Without insight into the author's intentions, I'm not sure if it has already been abandoned. Maybe vacation got in the way.
  301. Daniel on the other hand we also have experimental XEPs that are literally 60% TODOs
  302. Ge0rG Kev: in that case you should have just moved on with your offer to make a PR
  303. ralphm Having at least a response on Kev's extensive notes would help.
  304. ralphm Kev waiting for a response seems reasonable.
  305. Kev Ge0rG: Hindsight is a harsh mistress.
  306. Ge0rG flow: IIRC, sending a PR against inbox will mean that the editors trigger a resubmission.
  307. Ge0rG Kev: indeed.
  308. lskdjf has joined
  309. Daniel Kev > Which is why I offered to the authors to fix this now so the XEP could be accepted, as I had some spare cycles at the time, but that offer wasn’t taken up. I very much want a reactions XEP published, and was willing to put the time in to make it happen. How would that fix have looked like?
  310. Daniel using attachments?
  311. Daniel (or just link me to the 'offer')
  312. ralphm Kev: do you foresee a clearing in your time? I'd happily collaborate on this.
  313. Ge0rG If I got the authors right, they talked to Sam about 0367 and got told that it's not acceptable for Reactions.
  314. ralphm Maybe they should instead come here or on list.
  315. eevvoor has joined
  316. ralphm Including Sam
  317. Ge0rG ralphm: maybe this is one of the non-obvious things for new authors that jonas’ was talking about earlier
  318. ralphm yeah
  319. jonas’ and I don’t think all of those non-obvious things can be written down
  320. jonas’ but someone who has more knowledge of the internal workings of the XSF and the process will be quickly able to answer it
  321. adiaholic has joined
  322. jonas’ and it’d be good to have a person assigned to each newbie-proto-xep who’ll deal with that type of questions
  323. ralphm I like Sam a lot, but I don't think he's been aware of all the discussions that were had on this topic (and all other things concerning things 'attached' to messages).
  324. ralphm Also, Message Attaching, References, etc. all need work.
  325. Kev I think the easiest thing if Sam doesn't want Attaching to be used for this might be to either ask Sam to let someone else take over Attaching, or to submit a ~= identical XEP intending to be used more generally, and retire Attaching.
  326. Ge0rG ralphm: what do you see missing from Message Attaching?
  327. Ge0rG Kev: let's hope nobody rejects that ~= identical XEP on the grounds of it being duplication of Attaching, then.
  328. adiaholic has left
  329. ralphm Ge0rG: particularly around how we all store and retrieve these things from archives
  330. Ge0rG Kev: I think that asking Sam would be the polite route, while Council could easily take over Attaching, assign it to anybody standing up for it and let it be the right vehicle.
  331. debacle has left
  332. Zash Maybe gather everyone at a Summit and reinvent all these message relation things from first principles? 🙂
  333. Kev I deliberately said 'ask', not 'reassign', yes.
  334. Ge0rG ralphm: this is a hugely complex topic that's absolutely deserving its own XEP
  335. pdurbin has left
  336. ralphm Ge0rG: yes, but if we don't start to address it early on, this might be a lot of pain
  337. Ge0rG ralphm: we are already half-in into that pain.
  338. ralphm Ge0rG: I don't think we've barely scratched the surface.
  339. Ge0rG ralphm: we have north of four different ways to reference one message from another.
  340. Nekit has left
  341. Nekit has joined
  342. ralphm Zash: I've been toying with the idea of having a spec-writing-sprint on this indeed. The Summit is too far out.
  343. Ge0rG maybe the Reactions authors are actually right. We won't get rid of those legacy ways, and having four or five different legacy ID lookups in the server isn't such a big piece of work, compared to the other challenges.
  344. Ge0rG (I mean: the difference between having four vs five)
  345. ralphm well, isn't the text about ids in reactions not a copy-paste from XEP-0353?
  346. ralphm This alone is reason to think that one should use the other
  347. Ge0rG ITYM 0367
  348. Daniel well if we had (or can create in a timely manner) a general id referencing mechanism that we know for sure to be a one size fits all solution we can use that
  349. ralphm I meant 0367 of course
  350. larma I talked with several people about Reactions XEP as well as general purpose referencing. I personally think we are running in completely wrong direction with that right now (including the blocking of ProtoXEPs, but also with general purpose referencing in general), but as announced on the list, I am happy to do any changes to Reactions XEP or other XEPs needed to get it accepted if there was council advice what is the best/acceptable way to do it. Last status I am aware of is that there are at least two ways to do it and there is no consensus which is the right or better way
  351. Ge0rG Speaking of 0367, I think its biggest conceptual problem is that the payload to be attached is not inside of the <attach-to> element
  352. Ge0rG That makes it impossible to use <attach-to> as a general vehicle for a LMC to a message that is attached-to another message.
  353. Ge0rG (do I need to draw ASCII art?)
  354. mathieui Ge0rG, but then having it inside will break the LMC fallback for clients not implementing it
  355. ralphm Ge0rG: I'd like to see that art, indeed. I think I understand what you mean, but not sure if it really is a problem.
  356. Ge0rG mathieui: right. bummer.
  357. Daniel to be fair the introduction of 367 even mentions emojis. so it seems like a somewhat good fit?
  358. Daniel and creating Message Attaching 2.0 that is 95% identical might only be more confusinig
  359. Ge0rG <message from=romeo id=1>cat-pic</> <message from=juliet id=2><attach-to 1/>awww, this is ctue!</> <message from=juliet id=2><attach-to 1/><attach-to 2><lmc/></>awww, this is cure!</>
  360. Ge0rG ralphm: ^
  361. ralphm larma: I didn't see your response to the comments by Kev on list, in the thread, or on the council minutes. Great that you want to move forward!
  362. linkmauve has joined
  363. ralphm Ge0rG: oh, you mean attaching with a body?
  364. ralphm Ge0rG: well, this is what we have threads for. I don't think I'd see what you have there as a valid case.
  365. Daniel i think the issue occurs when lmc uses attach-to
  366. Daniel then you don’t know which attach-to is which
  367. ralphm ah
  368. Ge0rG ralphm: attach-to is an element that's not embedding what you are attaching but going side by side with it. So if you reference two different messages in one, the recipient doesn't know the meaning of the individual attach-to elements
  369. adiaholic has joined
  370. ralphm I'm not sure if I'd like to see multiple attach-to elements in one stanza ever.
  371. ralphm So maybe, LMC (or hopefully a more general message editing proposal) shouldn't use attach-to. Storage wise it also seems different from attaching.
  372. ralphm LMC (etc) are basically versioning on an original message
  373. larma attach-to is *not* suitable for general purpose referencing in its current versions as it can not be used when two messages are being referenced for different reasons. It would work for the purpose of Reactions though, at least I don't see any conflict with existing XEPs at that point if its done (but one needs to be careful in the future about it)
  374. Daniel well if the content of the attach-to were to be a child of the attach-to element you could simply treat it as to indivudal attaches. but yeah i agree that lmc is different to attaching and therfor should not use attach-to
  375. Ge0rG Daniel: but if you stuff the payload into the attach-to element, you lose backward compatibility.
  376. eevvoor has left
  377. Daniel well for some things that's good
  378. eevvoor has joined
  379. Daniel because for reactions we don’t want a fallback anyway
  380. Ge0rG ralphm: what about delivery receipts or read markers? Are those suitable for <attach-to>? How many different reference mechanism are actually needed?
  381. ralphm XEP-0367 currently also says you can't have multiple.
  382. Ge0rG Daniel: who is "we"?
  383. Daniel Ge0rG, in that case the majority of people on the mailinglist
  384. larma If we can't / don't want use attach-to for LMC, we need something else than attach-to for the general purpose referencing for thin client MAM
  385. mathieui Ge0rG, most people who can envision how hellish a reactions fallback would be
  386. larma Because both LMC and Message Attaching should be attached in the thin client MAM usecase
  387. Ge0rG > Ge0rG, in that case the majority of people on the mailinglist 🤷
  388. Daniel putting the stuff inside the attach-to element would also limit what a MAM archive has to store
  389. ralphm Ge0rG: I am not sure if receipts or markers are a good fit either, indeed. When I think of attaching I think of use cases currently covered by References, SIMS, reactions.
  390. Ge0rG ralphm: yeah, so what's the cut-off point for use-case specific syntax vs. using a general attach-to vehicle?
  391. Ge0rG The current Attaching XEP is _obviously_ good for everything that appends visible content to another message.
  392. ralphm And MAM wise, you probably want entirely different handling between: 1) LMC/editing, 2) reactions, 3) References/SIMS, 4) receipts, 5) markers.
  393. Ge0rG but then again, a receipt checkmark icon is also visible content attached to the message.
  394. ralphm Ge0rG: I see the latter more as meta data than an attachment
  395. Ge0rG ralphm: let's see... 1) store all edits together, deliver them all together 2) store all reactions together with the message, deliver them all together 3) same as 1 and 2 4) _maybe_ send receipts on behalf of the archive; don't forward receipts from each client of the user because once is enough(?) 5) same as 4?
  396. pep. “ralphm: I also think it would be bad to have in production clients with the expectance of large changes” < it's probably been said already, but what goes into "production", whatever that means, is up to the dev and not the xsf.
  397. larma Btw, I'd also like to bring up the issue of SCE because we don't have enough complexity on this issue yet: When we have SCE and want to use thin client MAM, the reference must be outside of the encryption so that the server can attach. However the encryption usually also provides authenticity, thus the reference must also be inside the encryption. The thing outside the encryption should also carry minimal information, so should only be <ref id=A/> or similar as any information what kind of reference it is leaks information outside ot SCE (which kind of is its sole purpose). Additionally the server can't do any merging on content in SCE cases.
  398. Ge0rG Daniel: is conversations making any use of per-contact-device markers/receipts?
  399. ralphm pep.: I said I agreed with that indeed.
  400. Ge0rG larma: agreed. but there most probably will be a set of elements that a sending client must put both into and outside of SCE
  401. pep. “flow: I still wonder why nobody hasn't simply wrote a quick "Reference Other Stanza" XEP, doesn't appear to hard” < if you read the reactions thread, Marvin volunteered
  402. Ge0rG the interesting thing is when you put content inside of the <attach-to>
  403. Ge0rG ...and if you read today's discussion in here, it IS hard.
  404. pep. And no it's not exactly 367. From what I understand 367 wasn't meqbt to be used how council is pushing it to be (quote from the author, Sam)
  405. adiaholic has left
  406. pep. And no it's not exactly 367. From what I understand 367 wasn't meant to be used how council is pushing it to be (quote from the author, Sam)
  407. Ge0rG pep.: a ref to that quote please?
  408. ralphm Ge0rG: 1) Not sure you want to deliver all edits. Maybe just the last one. 2) Store together (probably a separate dimension), retieve a summary, when needing more info (like when hovering), retrieve them all. 3) I'm not sure actually 4/5) markers are interesting in that you may have a bunch in groups, and you may want summaries, like with reactions
  409. Ge0rG ralphm: so we need four different ways to reference messages, for the purposes of Future MAM?
  410. ralphm pep.: The goal of Council is to give guidance on protocol development. This might indeed conflict with an author's original intentions, and I am not sure if this is a problem.
  411. zach has left
  412. zach has joined
  413. ralphm pep.: i.e. once a document is in the process, we rely on general consensus with guidance by council.
  414. ralphm Ge0rG: well, I'd say that the id handling is the same for all of them, but how such things are processed is different. I'm not sure if it should all be forced into a single element.
  415. ralphm Ge0rG: and yes, MAM handling itself is going to be much more involved than the currently naive single dimension.
  416. Ge0rG ralphm: from a MAM service implementers point of view, I don't just want to know the relationship graph (IDs), but also the type of edge invovled, so that I can do useful processing
  417. adiaholic has joined
  418. ralphm yes
  419. Ge0rG ralphm: so maybe "this message is some kind of reference of that message" is only useful if you want a naive two-dimensional store where the original messages are stored as a relationship group
  420. Ge0rG but not if you plan the things you outlined above
  421. pep. “Ge0rG: pep.: a ref to that quote please?” < either I got it from the reactions thread from Marvin, or I heard it directly from Marvin who asked Sam when writing reactions
  422. pep. (Still catching up with messages on this channel)
  423. Ge0rG pep.: the last mails from Sam were purely sarcastic, it seems
  424. larma Ge0rG, what I wanted to say: the general purpose referencing XEP would have to have some kind of usage attribute on it, so we can do something like `<ref id=A usage=attaching /><ref id=B usage=lmc />` (not necessarily this combination, but I am certain it will happen that we want one message to reference two others). Now if we put these <ref />s with usage outside of encryption we are leaking information. I am arguing for the ref outside of the encryption being somehow different than the ref inside. As the ref outside may be manipulated by a MITM, it shouldn't be trusted by the recipient at all and be completely ignored. It should become a server annotation only, which is not relevant for the message as displayed in a client, but can be used for thin client message attaching (in which case a MITM attacker can only manipulate the message such that it is not displayed in thin clients at all, which they can anyway). I'd prefer if we somehow write up what will be the usecases of the general purpose referencing so that we can actually find its requirements, before we force XEPs like Reactions to use something that makes little sense in practice later on.
  425. ralphm Ge0rG: well, I suppose the storage itself could be multiple tables or a DAG, or whatever. I'm not sure t.b.h., but the retrieval patterns differ.
  426. eevvoor has left
  427. Ge0rG larma: this is an interesting point in the current discussion ralphm and I have
  428. pep. Ge0rG: mails from larma
  429. ralphm larma: what is SCE again?
  430. adiaholic has left
  431. jonas’ stanza content encryption
  432. Ge0rG ralphm: Stanza Content Encryption
  433. adiaholic has joined
  434. pep. 420
  435. Ge0rG pep.: those don't count.
  436. Ge0rG pep.: I'm looking for a statement from Sam, directly.
  437. pep. Ge0rG: same
  438. ralphm Larma: I'm not sure about the various cases in-or-outside encryption. I'd expected you'd want to encrypt all the things.
  439. Ge0rG ralphm: you can't encrypt for the MAM store
  440. ralphm Ge0rG: yes of course
  441. Ge0rG This is conflicting with "encrypt all the things"
  442. ralphm Ge0rG: I'm not sure if having some bits encrypted and some not is a useful thing.
  443. Ge0rG ralphm: nobody said it would be easy.
  444. ralphm I.e. I don't think having server side archiving mixes with e2ee
  445. Ge0rG ralphm: it has to mix
  446. ralphm Why?
  447. Ge0rG you could argue that you can't have a "thin e2ee client", but I think there are people doing OMEMO in Converse.js
  448. larma People will want to a) have e2ee and b) use MAM and thin clients. We must make sure that it works.
  449. Ge0rG personally, I think that XMPP and E2EE don't mix well, and that XMPP should be used in scenarios where E2EE is not wanted. But my opinion is very unpopular.
  450. ralphm I mentioned this before, I am a bit skeptical about OMEMO and e2ee in XMPP context in general. You can't have all the things, I think.
  451. Ge0rG ralphm: we have to accept what the users want and try to make it work out
  452. ralphm larma: how, bar the protocols itself, do you think this is achievable?
  453. Ge0rG we already are the blackberry of instant messengers.
  454. ralphm Ge0rG: I haven't got any offers for narcotics yet.
  455. Ge0rG ralphm: didn't you complain about spam just some days ago?
  456. ralphm yes, no narcotics :/
  457. Ge0rG I'm sure there were also offers for illegal drug markets.
  458. Ge0rG maybe you couldn't read them because they were encrypted with Russian.
  459. ralphm hm
  460. larma ralphm, e2ee works with thin clients if minimal thin client annotations are attached outside the encryption. You are not leaking a lot of information by that, but still get the advantage of thin clients
  461. Daniel Ge0rG, in my very personal experience a not insignificant amount of users are fine with the limited scope of omemo/otr/27 only encrypting the body
  462. Daniel i rarly get asked for sce
  463. pep. Daniel: do they even know?
  464. ralphm larma: you mean that the act of referring is outside the encryption, but not the payload of said referencing
  465. pep. What kind of user tells you that
  466. larma ralphm, exactly and also the reason for referencing should not be mentioned outside
  467. ralphm larma: that might theoretically work, but it is probably a pain for proper handling of all the use cases I mentioned above.
  468. Ge0rG > ralphm, exactly and also the reason for referencing should not be mentioned outside this conflicts with Smart MAM
  469. ralphm SMAM :-P
  470. Ge0rG ralphm: maybe a useful degradation would be "store all the grouped message in bulk, deliver them in bulk"
  471. Daniel pep., good question. i don’t know. the ones that are just using e2ee for the good feels probably not. but we don’t need to 'fix' it for them
  472. ralphm Ge0rG: I guess.
  473. Ge0rG Given that meta-data kills, XMPP E2EE is a huge scam.
  474. Daniel other than that i reckon it is not 'unknown' that the existing e2ee methods don’t do sce
  475. larma Ge0rG, Not sure how smart your MAM should be, but if your server-side information is limited, obviously you cannot be super-smart
  476. Daniel Ge0rG, i'd argue that the meta data that kills is mostly the who with whom
  477. Nekit has left
  478. Daniel and not 'has read a message'
  479. larma Also IMHO this is mostly hypothetical, the smart MAM will probably be adopted as fast as MIX
  480. Ge0rG Daniel: speaking of which, somebody just complained over in prosody@ that their Conversations is sending a file encrypted via socks5 bytestream to gajim, but gajim doesn't decrypt it
  481. Nekit has joined
  482. Ge0rG larma: normally I'm the one with the pessimistic adoption rate estimations
  483. ralphm larma: standards development is a) not easy, b) not fast. MIX has a lot going for it, but these concepts are hard and people's time is limited. If somebody would be hire me to work on this full time, I would.
  484. Ge0rG yeah, can't we get our own cryptocurrency billionnaire sponsor?
  485. Ge0rG I'd be glad to work on XMPP full time as well.
  486. larma A "MAM delivering grouped messages in bulk" would work and is rather easy to implement both server and client side. It's not a perfect optimization, but it solves the problem of thin clients.
  487. aj has left
  488. ralphm And just to be sure, the reference itself should also be inside the encypted payload, to prevent spoofing, right?
  489. Ge0rG right
  490. ralphm Anyway, I am still curious: in which cases would one have to reference two different messages from one stanza?
  491. Ge0rG a type-less reference outside, and a typed reference (LMC / reaction / ...) inside
  492. Ge0rG ralphm: the current go-to example is an LMC of a message with a reference
  493. ralphm Yeah, I don't see that use case.
  494. Ge0rG why not?
  495. Ge0rG because you want a dedicated protocol for LMC?
  496. ralphm No
  497. ralphm I think that you'd either have loosely coupled messages in threads (using thread ids), or actual attachments. If you want to LMC the former, you can. I am not sure the latter would need to support edits.
  498. ralphm Other than, maybe retraction, which is still not LMC
  499. Ge0rG technically, LMC and retraction are very close
  500. Ge0rG except for the moderator use case
  501. ralphm But for retraction you can just refer to the thing you are retracting. You don't need the whole thing.
  502. Ge0rG so you mean a retraction lacks a payload?
  503. ralphm I think so
  504. ralphm Like in PubSub
  505. Ge0rG I'd actually like to see retraction re-worded as a payload-less LMC, but I see there are reasons against that
  506. ralphm I'd like edits instead of LMC
  507. Ge0rG OTOH, we could extend LMC with a @by attribute denoting who did the edit
  508. ralphm and retractions separate
  509. Ge0rG I'm using LMC as a synonym for arbitrary edits. The "last message" limitation is the worst thing about that XEP
  510. ralphm let's kill it then
  511. Ge0rG If I had unlimited time, I'd rewrite LMC into "Message Edits"
  512. Ge0rG ralphm: what would you do differently with "Message Edits", in comparison to LMC?
  513. Daniel has left
  514. Daniel has joined
  515. adiaholic has left
  516. adiaholic has joined
  517. ralphm Make sure it has the same id handling as the other things we've been discussing, lift the limitation on the last message, change the title?
  518. ralphm I /don't/ think we should support editing messages by others in any form. This is why I think we should have a separate thing for deletion.
  519. ralphm eh. retraction
  520. Ge0rG ralphm: speaking of ID handling, we haven't figured out yet all cases of how to edit a message that we didn't receive back from a MAM yet.
  521. ralphm Moderators should surely be able to retract others' messages
  522. ralphm Ge0rG: I think all of this discussion hinges on figuring that out
  523. Ge0rG ralphm: I think it's useful to have editing of messages by moderators.
  524. ralphm Ge0rG: why?
  525. Ge0rG You could remove expletives for example. mod_pastebin could be implemented in terms of editing.
  526. ralphm I think that opens quite a can of worms
  527. ralphm Either a message is acceptable, or it isn't.
  528. Ge0rG Because we have a good server side mechanism to enforce what's acceptable, that can be used by moderators?
  529. ralphm I'm not thrilled about a way that allows moderators to edit random messages. It makes it hard to see whose message it was. I suppose you also need to be able to trust the MUC server in any case.
  530. zach has left
  531. zach has joined
  532. ralphm I'd much rather have a situation where people are in control of their own words, and if that's not acceptable, the message is retracted in its entirety.
  533. ralphm That also makes it much easier to have edits override the original. If others can edit, you need to also be able to retrieve the original.
  534. adiaholic has left
  535. Guus Is having the XSF not wanting to deploy specific features reason to prevent a XEP that implements exactly that feature from being standardized?
  536. Guus I'm not liking content editing by third parties either - but should we therefor not allow such a XEP to exist?
  537. ralphm Reading back, it still isn't clear to me how Sam thinks XEP-0367 should be used, and how Council wants something else.
  538. Guus I'm not liking content editing by third parties either - but should we therefor not allow such a XEP to be standardized?
  539. ralphm Guus: well, I don't think it is wrong for Standards JID to have an opiniated process.
  540. matkor has joined
  541. ralphm Guus: we deal with privacy and security concerns, so maybe yes that could mean we won't standardize a particular feature.
  542. ralphm Guus: and that in turn might mean that you'd have to have a private extension, or write an IETF draft
  543. flow > larma: "However the encryption usually also provides authenticity, thus the reference must also be inside the encryption." I am not sure about the "must" here. And I also think this is a good example for something we should not bother with at this stage. I do believe can't solve the metadata issues with e2ee in XMPP right now, and probably ever.
  544. ralphm flow: I have the same feeling about metadata
  545. Nekit has left
  546. Nekit has joined
  547. flow \o/
  548. matkor Hi! By who's lack of activity https://xmpp.org/extensions/xep-0396.html is Deferred?
  549. ralphm matkor: usually this means the Author, but in principle 'all of us'
  550. flow matkor, everyone. As in, someone just needs to work on the XEP
  551. flow matkor, but why do you bother about it being deferred?
  552. flow if you implemented it, then please provide feedback
  553. flow ideally that leads to an update of the XEP, un-deferring it
  554. flow Re attach-to/reference: Why not simply have a <reference-ohter-stanza/> without childs which references at most one stanza regarding one concern?
  555. flow s/at most/exaclty/
  556. matkor flow, I am just newbie XMPP user trying to transfer files encrypted between gajim and conversations. Not sure what is "right way" to do it
  557. flow matkor, that's the question we ask yourselfs here daily: What is the right way :)
  558. matkor Seems Conversation uses XEP-0396 with success I wondered why gajim is lacking it.
  559. Ge0rG flow: "references exactly one stanza regarding one concern" so what do I do if I want to reference two stanzas regarding different concerns?
  560. flow matkor, the answer is usually because nobody implemented it
  561. ralphm flow: yes, I was just discussing with Ge0rG whether there are cases you'd need to refer to multiple messages, and I stated that I don't think there is one, really.
  562. flow Ge0rG, send two stanzas
  563. ralphm Ge0rG: still like to see that use case
  564. Dele (Mobile) has left
  565. flow or maybe it is not clear to me what "want to reference two stanzas regarding different concerns" means
  566. Ge0rG flow: what, if the same content relates to two stanzas in different ways?
  567. flow Ge0rG, send two stanzas?
  568. Dele (Mobile) has joined
  569. flow also, please provide a more-or-less real-world example
  570. matkor flow, sure, but there are usually reasons why sth is not implemented like a) there is better way, b) sth is obsolete
  571. flow otherwise it is hard to reason about it
  572. ralphm matkor: c) nobody has found the time, yet
  573. flow matkor, the most common reason is because nobody did it
  574. Ge0rG ralphm, flow: I don't have a convincing example at hand, but I'm pretty sure we'll end up wanting to edit a message that's attached-to another message.
  575. flow Ge0rG, edit as in? LMC?
  576. Ge0rG flow: yes
  577. Ge0rG flow: see my discussion with ralphm above regarding "edit" vs LMC
  578. flow Ge0rG, the LMC that message that is attached-to another message with the yet-to-be-invented generic attach-to mechanism
  579. flow *then LMC that
  580. Ge0rG flow: but I want LMC to use the generic attach-to mechanism!
  581. Ge0rG it's not generic if it doesn't cover LMC
  582. flow then bump LMC to do so
  583. Ge0rG flow: but then I have double references.
  584. larma `<message><body>this and that message</body><ref id=A start=0 end=4 /><ref id=B start=8 end=12 /></message>` = message referencing two other messages, although these references are probably not relevant at all for thin client MAM
  585. Nekit has left
  586. Nekit has joined
  587. flow Ge0rG, double references?
  588. Ge0rG flow: two references in one message
  589. flow Where?
  590. ralphm larma: that is a good use case indeed
  591. Ge0rG flow: 1) this is an edit of my message X; 2) this is a reaction/attachment/whatever to message Y
  592. Ge0rG ralphm: I'm sure Message References does cover that one ;)
  593. ralphm Ge0rG: except if you want to use XEP-0367 for doing referring to another messages.
  594. flow larma, how often do you reply in one mail to two mails in a mailing list? That is one of the seldom uses features of mailing lists and MUAs
  595. flow the mail protocol allows it, but is very seldom used
  596. Ge0rG flow: in the context of Message References, you can also reference users, URLs, etc.
  597. Ge0rG flow: so it would be perfectly fine to have a message with 64 references, containing the nickname of each other occupant of this MUC
  598. flow Ge0rG, probably, but that is not the context discussed here
  599. Ge0rG flow: if only we had thread references.
  600. wurstsalat has left
  601. flow We are strictly taking about referencing stanzas, and the question is: Do we want to introduce additional complexity by allowing one stanzas to reference more then one other stanza
  602. wurstsalat has joined
  603. larma flow, so you are proposing to change from "seldom used with XMPP" to "I use email instead because XMPP doesn't support it"
  604. pdurbin has joined
  605. Ge0rG ralphm: but only because 0372 lacks support to reference messages ;)
  606. ralphm There's a difference between pointing to a message with some id (which can be documented seperately), and use cases thereof: creating a secondary message that attaches to, or edits, a particular message, v.s. a separate message that wants to 'refer' to what was said before. FWIW, I'm not sure how to render larma's example.
  607. Ge0rG flow: I've given an example above.
  608. flow larma, no, I am saying that I never once in my life found myself in the situation that I wanted to reply two more than one "post" with a single "post"
  609. flow be it xmpp or mail
  610. flow and I believe this to be true for the majority of users
  611. Ge0rG I was multiple times in a situation where I wanted to reply to multiple mails from subthreads of the same thread. On standards@.
  612. Ge0rG Arguably, I'm not the majority of users.
  613. flow Ge0rG, then why didn't you do?
  614. ralphm I think larma is more like including hyperlinks
  615. ralphm larma's example
  616. Ge0rG flow: because I had no idea how.
  617. larma flow, But what does that imply? That we shouldn't be able to handle it on a technical level?
  618. adiaholic has joined
  619. flow larma, I don't believe the increased complexity is justified. Please note that I am strictly talking about referencing stanzas
  620. ralphm XEP-0372 has a way to include hyperlink references to URIs and we may want to construct a way to express a pointer to a particular message, either in private context, or in MUCs, but I don't think this is the same as the other use cases.
  621. flow Ge0rG, let's assume you didn't know how is because your MUA either does not provide the feature or because it is very well hidden. Then you can ask yourself why that's the case…
  622. larma `<message><body>look at that previous message</body><reply-to id=A /><reference-back-to id=B /></message>`
  623. ralphm I.e. you can still have a URI that points to an XMPP message, or a tweet, or a something else.
  624. flow that that URI potentially would not be processed by the message archive in any way, which is probably fine
  625. ralphm larma: we don't have reply-to, really, we have threads
  626. ralphm flow: indeed
  627. Ge0rG but nobody uses threads, so we should replace them with generic references.
  628. ralphm god no
  629. larma ralphm, we don't have X so we should never ever support it
  630. Ge0rG but if we do that, we have a convincing example of why it makes sense to have two references in one message.
  631. flow so we can have references with a exactly-one limit, which is processed by the message archive, and references with a one-or-more semantic, which are then not processed by the archive. That sounds like a good comprosmise
  632. Ge0rG references and References.
  633. flow although I am not sure if we need the one-or-more semantic references ever
  634. ralphm larma: not at all. We do have 20 years of prior work, and Ge0rG's assumption that nobody uses threads is probably not true.
  635. Kev It's probably not true, but it's pretty close to it.
  636. ralphm In the end this discussion is about the tightness of coupling
  637. flow larma, it's not "never support it", but be obviously should not design protocols with things that do not exists (and are not going to exists in the near future) in mind
  638. pdurbin has left
  639. Ge0rG flow: I disagree on this one. We should take into account the long-term delelopment of the protocol when adding new XEPs
  640. Ge0rG Otherwise, we end up with MAM and Carbons.
  641. Kev I can't catch up with all the backlog, but re: multiple references, I think you have one "This message follows on from this other message" reference (attaching, if you will), but potentially have a message reference many other things (some of which may be messages). e.g.: "re: Ralph's mesage<AttachmentReference> Hey @<Reference>Ralph, I agree, but did you see @<Reference>Ge0rG's <reference>message earlier?"
  642. flow Ge0rG, I did not say that we should not take the long-term development into account. But I have never heard of anyone talking about introducing reply-to
  643. Kev Which is why I'm quite happy with the idea of keeping attaching and references distinct.
  644. Nekit has left
  645. Kev Be it the two XEPs, or two different annotation types in a single XEP.
  646. flow Kev, does that matter much?
  647. Ge0rG Kev: I'm not quite sure what you mean by "follows on"
  648. Kev Yes, and I realise there's essentially three reference types, as you say that.
  649. Ge0rG Kev: but I assume 0372 is about showing a kind of hyperlinks inside of the body, whereas 0367 is about structural order of messages in the archive, delivery and display?
  650. Ge0rG Kev: three?
  651. Kev There's In-Reply-To, which was my first reference in that message, there's "Here are some other data relevant to the message", which were the others, but there's also "I am hanging this message off the other and it doesn't make sense in isolation", like Reactions and Editing/Correction.
  652. ralphm If a message is strictly about another message (this message is marking up that other message with hyperlinks, and I'm referring to characters 4-6 in this other message, References), Reactions, Edits, Markers, then I'd say we can come up with a generic mechanism for including such a singular reference. E.g. by using attach-id. If you want to point to other things loosely (again References, but the *target* of the link is elsewhere) you can use URIs or somesuch.
  653. Ge0rG In-Reply-To is what threads are for. But isn't a Reaction also In-Reply-To?
  654. Kev I am happy to limit 372 to the second type. I originally intended to cover everything, but I'm not dogmatic about that.
  655. ralphm Ge0rG: you can model it all kinds of ways. In e.g. Slack, a textual reaction is a separate thing, that itself can have emoji reactions, marking up (references), etc.
  656. Ge0rG ralphm: I'm trying to understand all the implication, and maybe to find a good way forward.
  657. Ge0rG I think that the trinity proposed by Kev is a good approximation
  658. ralphm Kev: I'm saying that in 372 you have two types of things to refer to: 1) the plain text you are marking up, with char refs, 2) hyperlinks to tie to those hot texts.
  659. andrey.g has left
  660. Nekit has joined
  661. Kev (Incidentally, I don't think threads necessarily are fit for purpose, but I'm happy with just saying it's a distinct requirement and excluding it from discussion)
  662. Kev ralphm: There are two halves of that type of reference, yes.
  663. ralphm for 1) you need something like attachments, 2) URIs are great
  664. Ge0rG ralphm: for 1 you need what's written in 0372
  665. Ge0rG unless you want to make the marking-up a separate message from the original text
  666. Kev Ge0rG: Which I think has value.
  667. Ge0rG in which case, you attach-to the original message a set of reference-markups
  668. Kev e.g. a MUC service that annotates a message once it's fetched an async resource.
  669. ralphm Ge0rG: this is about 'anchor' v.s. 'uri'
  670. ralphm Ge0rG: we can replace 'anchor' with 0367.
  671. Ge0rG ralphm: now I'm totally confused.
  672. ralphm And then make it easier to mark up multiple parts of the text without having to repeat the anchor.
  673. Ge0rG ralphm: to quote from 0372, which is anchor and which is uri? 1 <reference xmlns='urn:xmpp:reference:0' 2 begin='72' 3 end='78' 4 type='mention'
  674. ralphm Ge0rG: a link has two parts: the text you want underlined, the URI you want to jump to. Clear?
  675. Kev Let's see if I can avoid distraction long enough to gist some example thoughts.
  676. LNJ has joined
  677. Ge0rG 5 uri='xmpp:juliet@capulet.lit'/>
  678. Ge0rG ralphm: so 2+3 is the anchor, and 5 is the uri
  679. Ge0rG ralphm: and if you want to make the <reference> a stand-alone message, you need to attach-to the list of <references> to the original message.
  680. ralphm Ge0rG: XEP-0372 has two examples: one with a plain text included, there's no anchor here, because you are referring to the included body. The other has no body element, so you want to reason over some other, earlier message. So that example has an anchor attribute, and I'm saying that we can replace the latter with 0367.
  681. ralphm Ge0rG: yes
  682. andrey.g has joined
  683. ralphm The former is section 3.2, the latter is 3.4.
  684. Ge0rG <message id=1><body>Hi Juliet</body></message> <message id=2><attach-to id=1> <reference xmlns='urn:xmpp:reference:0' begin=3 end=9 uri='xmpp:juliet@capulet.lit'></reference> </attach-to></message>
  685. Ge0rG Something like this maybe?
  686. ralphm One flaw with XEP-0372 as it is now is that you can have a single message that has references with two different anchors. I think that's confusing and stupid, and having that replaced with XEP-0367 would be a lot cleaner.
  687. linkmauve has left
  688. Ge0rG ralphm: wwhen do you need two different anchors?
  689. ralphm Noever
  690. Kev https://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a
  691. ralphm Never
  692. Ge0rG ralphm: it's not long ago that you argued this would never be needed.
  693. Ge0rG Ah.
  694. Kev Ok, I'm suggesting we could do something like this, which is an advancement of 372/367
  695. zach has left
  696. zach has joined
  697. Kev I think it's what Ralph's describing.
  698. Kev But if not, I've not understood and would like to :)
  699. Kev attach-to is the thing that could be 367, or something like it.
  700. ralphm yes
  701. Ge0rG Kev: the metatext inside your gist is confusing.
  702. Kev reference is the thing that's 372-ish.
  703. ralphm yes
  704. Ge0rG yes
  705. Ge0rG yes to what, actually?
  706. Kev Ge0rG: Which bit of metadata? Happy to update the list, I'm trying to balance brevity and clarity.
  707. ralphm a confirmation of Kev's interpretation of me
  708. Kev I guess I should add a reaction to that too, hang on :)
  709. ralphm Kev: do you have an opinion on nesting stuff inside attach-to v.s. sibling?
  710. Ge0rG Kev: I'd like to see an approximation of the XML for @target; I think I get the start/end things, even though they are distracting my OCD
  711. Ge0rG Kev: what do you think of the XML I posted above?
  712. Nekit has left
  713. Ge0rG it would also solve ralphm's issue with multi-anchoring
  714. Ge0rG and it would solve the issue with "dumb" MAM grouping.
  715. ralphm I don't have an issue with multi-anchoring, we should not have it.
  716. Kev ralphm: I do, I think it's nested.
  717. Nekit has joined
  718. Kev Ge0rG: Let me have a look at your XML, 2s (Gist's edit mode isn't working for me so I can't update my proposal for reactions).
  719. Ge0rG and you could do SCE with low effort:
  720. Ge0rG <message id=2> <attach-to id=1/> <ENCRYPTED><attach-to id=1><reference xmlns='urn:xmpp:reference:0' begin=3 end=9 uri='xmpp:juliet@capulet.lit'></reference></attach-to></ENCRYPTED> </message>
  721. Kev Yes, I think your 12:04 XML is roughly equivalent to what I pasted in intent.
  722. ralphm Kev: but at most one, right?
  723. larma I'd also like to consider that there is semantically two types of attachments: Those that only the original sender and maybe a MUC (admin) can do (LMC, Retraction, Attaching?) and those that everyone can do (Reactions, replies)
  724. Ge0rG okay, "low effort" actually means you need to extract attach-to skeletons
  725. Kev Ah, hi larma.
  726. balu_der_baer has joined
  727. Kev Yes, I was thinking about ACL on this stuff earlier. I suspect this doesn't affect the wire protocol, but I'm aware a MUC might need to e.g. whitelist attach-to payloads.
  728. balu_der_baer has left
  729. ralphm larma: that is a good point, clients would need to check for this
  730. Kev https://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a updated
  731. Ge0rG <message id=1><ENCRYPTED><body>Helo tere</body></ENCRYPTED></message> <message id=2> <attach-to id=1/> <ENCRYPTED><attach-to id=1><lmc-marker/></attach-to><body>Hello there!</body></ENCRYPTED> </message>
  732. flow larma, good point
  733. Kev https://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a updated again
  734. larma Ge0rG, why is the body outside the attach-to? looks wrong to me
  735. Ge0rG larma: because of backward compatibility to pre-LMC clients
  736. larma But semantically what you wrote is "attach the lmc marker to the message and have a message with this body"
  737. Ge0rG the lmc-marker is meant to signify that.
  738. flow is backward compatiblity really something we should be concerned in this case?
  739. Ge0rG flow: yes.
  740. ralphm This is also why I wondered if it wouldn't be just as fine to have the attach-to be empty and a sibling.
  741. UsL has left
  742. Kev I think, in as far as we do fallbacks at all, we might have to consider having duplicate content here.
  743. ralphm Kev: you last example, message 6, would have backwards compat issues
  744. Ge0rG ralphm: it's not elegant, and only workable as long as you have at-most-one attach-to. Also it makes parsing in "Smart" MAM way harder.
  745. ralphm Ge0rG: still want that more than one example.
  746. Ge0rG ralphm: just because we two can't come up with one, it doesn't mean there is none
  747. larma I think having attach-to a sibbling makes sense for those messages that do work as standalone, i.e. when you don't have the previous message (LMC, replies), but not for those that don't (reactions, retraction)
  748. Ge0rG larma: good point
  749. Kev Updated.
  750. Ge0rG Kev: what's wrong with my <lmc-marker/>?
  751. ralphm larma: for reactions, retraction, you wouldn't point to two different messages in one stanza.
  752. Kev Ge0rG: Maybe just that I missed it in the flow.
  753. larma Kev, I totally dislike the duplication of the body for backwards compat
  754. Kev larma: Good, me too :)
  755. Ge0rG Kev: 12:12:49
  756. larma ralphm, that's for those that only point to one (attach-to, not references)
  757. Kev Ge0rG: That might work.
  758. Ge0rG ralphm: what about reaction retraction?
  759. Ge0rG larma: 0372-style references are a different topic
  760. Kev Ge0rG: https://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a ?
  761. Syndace has left
  762. ralphm Ge0rG: you can just retract the stanza of the initial reaction, like message 4 in Kev's example
  763. Ge0rG Kev: yeah
  764. larma Kev, that's implying that you can only change the body with LMC
  765. ralphm Yes, that's what it is for.
  766. Ge0rG ralphm: no, it's for any kind of payload.
  767. larma > Correction MUST only be used to change the logical content details of a stanza (e.g. the message body) and not to change the nature of the stanza
  768. Kev In this example, the attachment payload is still within the attachment element, which is good, it's just that it's then a pointer (careful not to say reference) elsewhere in the stanza.
  769. Kev You're both right.
  770. Kev Or all three.
  771. Syndace has joined
  772. Kev You can replace any payloads, but not rewrite the logical-type of the stanza.
  773. Ge0rG Kev: rename the element to <message-edit/>
  774. Kev You mean s/body-is-edit/message-edit/?
  775. Nekit has left
  776. Ge0rG Kev: yes. or maybe message-is-edit
  777. Ge0rG edited-message
  778. Ge0rG Bike shedding!
  779. Dele (Mobile) has left
  780. Kev These are details I feel don't need to be in a pseudo-exmaple.
  781. Dele (Mobile) has joined
  782. Kev What's really relevant, I think, is that the LMC instruction lives within the attach-to.
  783. Kev And that references can also live within an attach-to, as can reactions.
  784. Ge0rG And that we can have multiple attach-to elements with different payloads in one message!
  785. ralphm Why is that better than as a sibling (trying to get my head straight)
  786. larma I think having the message a sibbling of the attach-to but still put something inside the attach-to is semantically broken. Either the content of the attach-to is attached, or the sibblings, but this combination is just awkward
  787. ralphm Ge0rG: or we stop thinking we need multiple.
  788. Ge0rG ralphm: it makes processing for Smart MAM easier, because you don't need to analyze all the siblings and derive conclusions from their presence
  789. Kev ralphm: Clear hierachy. Sometimes you have 'extra noise' in stanzas, and it's much more convenient to be clear which bits apply where.
  790. Kev Ge0rG: I don't yet understand the need for multiple attach-to in a single stanza.
  791. Kev And yes, what Ge0rG says about nesting, too.
  792. Ge0rG Kev: nobody does, but in a year we've codified that There Can Only Be One, and somebody comes up with a compelling use case that can't be implemented any more
  793. Ge0rG Kev: 0184 would have been so much better with multiple payloads
  794. ralphm Kev: ok. I'm asking because back in the day, Blaine thought we should have originally gone with allowing Atom payloads next to the pubsub event wrapper, so that you could interpret the notification even if you didn't understand pubsub.
  795. flow Ge0rG, I am not sure that this means that it can't be implemented any more
  796. Ge0rG but nobody came up with the use case of offline message mass-acking
  797. Kev So SMAM would see an attach-to, and process its children (this is also a motivation for having the LMC body within attach-to, not external)
  798. flow I sure would require a ns bump
  799. Ge0rG flow: an ns bump and server-side conversion modules.
  800. flow point is, it is easy to go from a exactly-once to one-or-more semantic, but not the other way around
  801. flow or "easier"
  802. Ge0rG flow: or clients adding multiple versions of attach-to elements with different semantics into one message.
  803. Kev I'm not sure I'd say it was 'easy', but 'easier', yes.
  804. Ge0rG with the proposed semantics, is there a reason NOT to have multiple attach-to in one message?
  805. ralphm flow: well, since it moves into attach-to, you don't actually need to change the namespace for backwards compat. Of course older clients now see multiple messages, because they don't know attach-to
  806. Kev Ge0rG: If everything is properly nested, no. But if we allow leakage outside the attach-to, kinda yes.
  807. flow Ge0rG: and if we ever go from a esactly-once to a one-or-more semantic, you can say "told you so"
  808. ralphm flow: and then file bug reports for clients that only hanlde one
  809. Ge0rG > point is, it is easy to go from a exactly-once to one-or-more semantic, but not the other way around I think the opposite is true: if you have implemented parsing for N elements, and the message only may contain one, your code just works™
  810. flow "feature requests"
  811. Kev I do find flow's argument about ease of switching fairly compelling, though. We could publish with one, and see if anyone has a counter-argument while it' sexperimental.
  812. Nekit has joined
  813. Ge0rG Kev: "A receiving entity SHOULD be able to process multiple attach-to payloads"
  814. zach has left
  815. zach has joined
  816. flow Ge0rG, I don't see how parsing is the heavweight thing yo'd have to change here
  817. Kev Ge0rG: That's the worst of all worlds, isn't it? :)
  818. Ge0rG Hey, I could edit all my messages to the same text with one message!
  819. Ge0rG flow: not parsing but interpreting.
  820. ralphm :headdesk:
  821. ralphm That's exactly what I want to prevent.
  822. Ge0rG flow: `AttachTo message.getAttachToPayload()` vs. `List<AttachTo> message.getAttachToPayloads()`
  823. flow implementing interpreation of exactly-once is probably way easier than one-or-more
  824. ralphm We've removed batch stuff in several protocols, like pubsub.
  825. larma If we have Unencrypted: `<message to=room from=ralph id=4><attach-to id=3><reaction>👍🏻</reaction></attach-to></message>` Encrypted: `<message to=room from=ralph id=4><attach-to id=3 /><ENCRYPTED><attach-to id=3><reaction>👍🏻</reaction></attach-to></ENCRYPTED></message>` This confuses me a bit: Is attach-to now to be semantically understood to a) attach sibbilings b) the full message c) the content of the attach-to element
  826. Kev larma: The content of the attach-to. Although in the case of LMC there's this open question about whether it's ok to referer out to the body or not.
  827. Ge0rG larma: what about <attach-to id=3><ENCRYPTED/></>
  828. larma Ge0rG, that would be the logical consequence, but then this is going to be terrible with legacy fallbacks
  829. pep. Kev: btw, nit (but not really), you don't need the "@" if you have References type mention.
  830. Ge0rG or rather: <attach-to id=3><external-sibling name="ENCRYPTED" ns="urn:xmpp:sce:0"/></>
  831. pep. (More garbage in body is never really welcome)
  832. Ge0rG and <external-sibling/> is a reference to the element name and xml:ns of the external sibling. MAXIMUM FLEXIBILITY!
  833. ralphm pep: but it might be what the user typed
  834. larma `<message><attach-to id=A><ENCRYPTED>actual</ENCRYPTED></attach-to><ENCRYPTED>fallback</ENCRYPTED></message>` definitely sucks
  835. Ge0rG ralphm: the user's client should replace `@user` with `user` and a reference, then! :P
  836. larma Ge0rG, how would you do if you attach multiple subblings?
  837. ralphm Ge0rG: if could
  838. Ge0rG larma: have multiple <external-sibling/> elements. Or just define the ns if they all share one
  839. ralphm Ge0rG: I meant 'it could'
  840. Ge0rG ralphm: I'm clearly thinking of the Slack UX here
  841. ralphm Ge0rG: Slack doesn't actually remove the @
  842. wurstsalat has left
  843. Kev Showing the @ is fairly usual in modern clients, I think.
  844. wurstsalat has joined
  845. Kev But I don't think this is the most important of the discussed details :)
  846. ralphm nah
  847. ralphm I like how this is shaping up.
  848. Ge0rG Kev, ralphm: am I overengineering things with <external-sibling>?
  849. ralphm Ge0rG: yes
  850. Ge0rG Much?
  851. ralphm yes
  852. Ge0rG A more pragmatic alternative?
  853. Kev I don't know, honestly.
  854. Kev I don't entirely understand why it needs to be alongside rather than nested, yet.
  855. Ge0rG I mean, the reference-tracking implications of that are really bad.
  856. Ge0rG Kev: the default would be nested
  857. ralphm I think having an empty attach-id is fine. If the encrypted payload is unwrapped, it can override it.
  858. Kev When would you external it?
  859. Ge0rG the only real use-case I see is message edits with legacy.
  860. Kev ralphm: I think an empty attach-id is pointless. It doesn't allow the archive to do anything useful, and other recipients are able to decrypt.
  861. Ge0rG Kev: it allows the archive to group related messages
  862. ralphm Kev: this was discussed arelier
  863. ralphm Kev: so that you could still have a limited two-dimensional grouping in MAM, even though you don't know about the encrypted bits.
  864. Ge0rG Kev: a thin E2EE client still benefits from that grouping
  865. Kev Ge0rG: I am seriously considering whether the best thing for legacy fallback might be to have <fallback/> inside the attach-to, and then clients will need to understand <attach-to/fallback> in order to show a fallback.
  866. ralphm I.e. retrieve all the encrypted attachments in one go
  867. Kev ralphm: But you can't have any grouping if there's no id, can you?
  868. Ge0rG Kev: what would <fallback/> mean?
  869. ralphm Kev: I mean no payload
  870. Kev Ge0rG: It'd be a plaintext that can be shown to the user if your client doesn't support that type of attachment.
  871. Kev So you need your client to understand attach-to/fallback, but once it does it can render a fallback sensibly for any other attachment type.
  872. Ge0rG Kev: wait, what?
  873. ralphm Kev: <message to=room from=ralph id=4><attach-to id=3 /><ENCRYPTED><attach-to id=3><reaction>👍🏻</reaction></attach-to></ENCRYPTED></message>
  874. ralphm Kev: MAM can know that this thing belongs to 3, but the real thing is inside
  875. Kev ralphm: Yes, that seems arguably ok. That's not an empty id though :)
  876. ralphm I didn't say empty id
  877. Kev "I think having an empty attach-id is fine" :)
  878. ralphm oh, I did
  879. ralphm whoops
  880. Kev If you didn't mean an empty attach id there, I don't know what you meant :)
  881. ralphm See, now I need edit
  882. Kev But yes, empty attach-to other than the id seems reasonable.
  883. Kev Suboptimal, but the best you can get if you want encrypted payloads.
  884. larma Is `<message id=A><body>First</body></message>`+`<message from=B><attach-to id=A><any-attachment /></attach-to></message>` then considered to be compacted to something like `<message id=A><body>First</body><attached from=B><any-attachment /></attached></message>` server-side? (the not so smart version of thin client MAM, the smart version would probably look into `<any-attachment />` and make some special handling for it)
  885. Ge0rG larma: could you please reformat your messages for the XML to begin at new lines, and maybe have some more structure?
  886. Kev I don't think it's compacted, no.
  887. rion has left
  888. rion has joined
  889. ralphm What do you mean compacted?
  890. larma ralphm, for the usecase of thin client MAM
  891. larma (which seems to be the main use-case of all of this after all)
  892. Kev The attach-to lives in its own right, linked to the first message, rather than replacing the message itself.
  893. Kev So you'd be able to query the attachments of a message through SMAM.
  894. ralphm larma: the only optimization a MAM server should do in this dumber case, is to ensure that when you retrieve a message, you get the attachments, too.
  895. Kev But, by default, when requesting through MAM you'd not get them.
  896. Kev Wait, what? :)
  897. Ge0rG ralphm: also vice-versa? When you query for an attached message, to receive the original first?
  898. ralphm larma: for the slightly smarter interaction, you probably don't want to retrieve all the things. Like with reactions, I'd say we'd have an element with a summary of reactions that's returned when you receive a message from MAM, but you need to query for all the individual ones to show who sent them.
  899. larma ralphm, OK makes sense to me, just want to ensure we are not missing the actual goal of all of this, as we already talked about over-engineering
  900. ralphm (like in Slack, you only see the counts, until you hover over them)
  901. Ge0rG but that means you need to deliver a map(reaction -> count)
  902. ralphm yes
  903. larma If we don't have any special semantic meaning of the content of <attach-to> I'd say it is better to not actually put stuff in there and make it always a sibbling
  904. Kev I'm happyish to punt solving how you do the archive queries to later, as long as we're confident we're encoding enough in teh protocol that we /can/ solve it later.
  905. Kev I'm happyish to punt solving how you do the archive queries to later, as long as we're confident we're encoding enough in the protocol that we /can/ solve it later.
  906. ralphm Kev: oh, MAM is a going to be quite another topic, indeed
  907. Kev larma: I think we do have semantic meaning of the children of attach-to.
  908. Ge0rG larma: but we actually _want_ to have semantic meaning for the children
  909. Ge0rG just not generally.
  910. Ge0rG the two exceptions being E2EE and legacy Edits
  911. pep. “ralphm: Slack doesn't actually remove the @”, then the other side can put it back, but this has nothing to do on the wire.
  912. Kev pep.: And thus isn't worth discussing at the moment :)
  913. pep. still trying to catch-up with what's been said in here
  914. larma > but that means you need to deliver a map(reaction -> count) Ge0rG, yes this implies that the SMAM server understands reactions, has special handling of it and doesn't make use of the generic attach-to feature (which is kind of funny as we are mostly talking about the generic feature for exactly that usecase)
  915. Ge0rG larma: oh, of course it would rely on the generic attach-to feature
  916. Kev Sorry, why isn't SMAM using attach-to?
  917. zach has left
  918. Ge0rG it would just make better use of it
  919. zach has joined
  920. ralphm pep.: what I believe Slack does is always send the original thing (plaintext) and then updates to it to mark it up. On slow connections you can see this happening sometimes.
  921. larma Kev, Ge0rG, If the server needs to be able to understand what reactions means in `<attach-to id=A><reactions /></attach-to>` it could also just understand what reactions means in `<reactions id=A />`
  922. aj has joined
  923. Kev But it doesn't /need/ to understand what reactions mean, does it?
  924. ralphm larma: the idea is definitely that a MAM server with knowledge about attachments, will have a more efficient storage retrieval.
  925. Kev There may be value in it doing so, but it doesn't fall apart if it doesn't.
  926. ralphm RIght
  927. larma Kev, If it wants to build a map(reaction -> count) as suggested by Ge0rG it needs to understand
  928. Kev Yes. If it wants to be very smart, it can (and that is a good thing).
  929. ralphm Yes, it would be a discoverable feature.
  930. Kev But a somewhat-less-smart option is also available.
  931. Ge0rG larma: yes; but when we introduce another kind of attached-to payload, SMAM will automatically provide the grouping for it, just without an improved summary
  932. Kev And it's already smart enough that it can know that it's a {ns}reaction child in the attach-to, so a client that doesn't support those won't bother retrieving them, even if the server doesn't do the mapping and summary.
  933. larma So there is GMAM (grouped MAM) and SMAM (smart MAM). GMAM would rely on attach-to and SMAM would actually look into the reactions?
  934. Kev There's a hierachy of smarts, yes, if you want to call them GMAM and SMAM.
  935. Kev So SMAM is an improvement on GMAM is an improvement on MAM.
  936. ralphm You could have a way to say: give me all the messages (but without attachments), and then if it knows about reactions might include summaries. Then later you might retrieve the attachments.
  937. Kev Do I need to make another gist once I've thrown some lunch in the oven?
  938. ralphm Yes
  939. ralphm Doing the same
  940. ralphm Hmm bapao
  941. Kev This is very much not what I needed to get done today!
  942. ralphm Kev: yes you did. Your boss may complain to me.
  943. ralphm Also thank you
  944. larma I'd like to see an example of a message attachment being edited
  945. Ge0rG speaking of gists https://gist.github.com/ge0rg/a255cb521e45bbcb89573aa3218f0cd5
  946. ralphm larma: I don't really
  947. Ge0rG is that a valid summary of today's discussion? ^
  948. Kev "Can be sent by anyone" - unclear to me, more thought needed.
  949. ralphm larma: I'd rather see retraction and then a new one
  950. Kev "wide consensus, except for Ge0rG" - I think I'd like to hear if anyone has an example where it's beneficial; I'm not dead-set against it.
  951. Kev "i.e." - you mean "e.g." ;)
  952. Kev "an without a payload" - missing some words, I think.
  953. Kev But yes, I think that's pretty close to a summary, and is useful to capture, thanks Ge0rG.
  954. larma > You could have a way to say: give me all the messages (but without attachments) ralphm, but you'd actually want to also put some attachments directly, like message retraction, no?
  955. Kev I don't believe retraction should be an attachment.
  956. Kev Because it has different semantics from attachments, for exactly this reason.
  957. matkor has left
  958. ralphm Indeed. And retractions should be consolidated by the server
  959. matkor has joined
  960. Kev Ah, are we talking about retracting an attach-to, or retracting a source message?
  961. ralphm both, I suppose
  962. Kev I think they're very different.
  963. larma Kev, so you'd want always special handling for retraction, even in GMAM. Obviously makes sense in SMAM
  964. larma In case of SCE, do we encrypt the retraction element?
  965. ralphm Kev: they are, but the protocol doesn't have to be
  966. Kev ralphm: Yes, it does :)
  967. Kev Or, rather, makes a lot of sense to be.
  968. ralphm Kev: why? You can retract the stanza. If the stanza is an source message, then everything goes. If the stanza is an attach-to, then its payload goes?
  969. Kev Because I don't think that retracting attach-to by the id of the carrying stanza is entirely sensible.
  970. ralphm why?
  971. ralphm (is there a way for Gajim to show typing notifications in MUCs?)
  972. Kev So I think it makes more sense to have <message><attach-to><retract-message/></attach-to><message> for retracting a source message, and <message><attach-to type='remove'>describepayload</attach-to></message>
  973. Nekit has left
  974. larma I agree that one shouldn't reference attach-to messages at all
  975. Kev I'm just thinking of the pain of implementing things in the server archive at the moment. This is all going to be moderately painful (desirable features, so pain we have to accept, but still painful), and I'd rather keep the pain as low as we can. I believe that different paths for removing attachments and for redacting messages is simpler.
  976. Nekit has joined
  977. ralphm I was thinking more about: `<message><retract id='...'/></message>` for both.
  978. pep. Kev: on these channels, "the moment" is whenever somebody talks about it, so here it is. It's not relevant for this discussion but it's relevant nonetheless.
  979. Kev And I also believe that storing attachments as attachments is probably easier than storing them as messages.
  980. ralphm Kev: yeah, we talked about dimensions before, and I'm not sure yet what the MAM protocol should look like.
  981. larma Kev, but often the message containing the attachment has relevant information, like the person that attached the message
  982. pep. Also re reactions being "compressed", "I have a use-case" for wanting individual payloads that have been sent (that is, even for just one user, have all the intermediate payloads they've sent)
  983. ralphm But semantically, calling a retraction an attachment is a bit odd.
  984. zach has left
  985. zach has joined
  986. larma Matrix does the same IIRC 😀
  987. Kev ralphm: Yes, I would be happiest with just <message><retract...></>
  988. Kev pep.: I don't think we're suggesting not storing them, just that it's most useful to present to a client as a summary usually.
  989. ralphm pep.: didn't I say we would have the ability to retrieve all the things?
  990. Kev larma: Yes, there's some metadata involved.
  991. Kev We did talk about all this at the summit, I wonder if any of it was captured in the minutes.
  992. ralphm http://logs.xmpp.org/xsf/2019-08-29#2019-08-29-24812f82e1f8a8be
  993. ralphm Kev: if you'd be happier with my example, what is the problem with it then?
  994. ralphm Kev: the lookup?
  995. Kev Your example was to retract attach-to message wrappers in the same way as to retract messages, wasn't it?
  996. Kev I'm certainly not happier with that.
  997. Kev I'm happier when messages are retracted in one way, and attach-to retracted in another.
  998. ralphm So like we have retract item and delete node in pubsub?
  999. adiaholic has left
  1000. Kev Somewhat, yes.
  1001. ralphm I thought it might be easier to just say to undo a stanza being sent, but not a hill for me to die on
  1002. pep. ralphm: OK i right have misread
  1003. ralphm No worries. Things were going FAST
  1004. Nekit has left
  1005. Nekit has joined
  1006. adiaholic has joined
  1007. zach has left
  1008. zach has joined
  1009. sonny has joined
  1010. pdurbin has joined
  1011. pdurbin has left
  1012. adiaholic has left
  1013. adiaholic has joined
  1014. adiaholic has left
  1015. adiaholic has joined
  1016. zach has left
  1017. zach has joined
  1018. Ge0rG Sorry, I had to vanish into a call. Now that I'm back, the last hour of log doesn't make much sense to me.
  1019. MattJ You had to be there
  1020. Ge0rG You want message retraction to explicitly use a different mechanism than Attach-To? What about Message Edits, should that stay Attach-To?
  1021. Zash Which direction does the relation go?
  1022. Ge0rG Zash: the new message references the old message
  1023. adiaholic has left
  1024. adiaholic has joined
  1025. pep. That doesn't specify the relation between the two though. Is there a case of a new message becoming the parent of an older one
  1026. Zash But does the new message belong to the old message or the reverse?
  1027. adiaholic has left
  1028. adiaholic has joined
  1029. Ge0rG can we leave the philosophical questions for later, please, and focus on the protocol?
  1030. zach has left
  1031. zach has joined
  1032. adiaholic has left
  1033. adiaholic has joined
  1034. adiaholic has left
  1035. adiaholic has joined
  1036. nyco has joined
  1037. nyco test
  1038. waqas has joined
  1039. Guus a+
  1040. ralphm .
  1041. adiaholic has left
  1042. adiaholic has joined
  1043. Seve Test passed
  1044. Guus we meet?
  1045. zach has left
  1046. zach has joined
  1047. nyco ouch
  1048. MattJ Oh wow, it's Thursday again :/
  1049. Guus Welcome to my thoughts, 10 minutes ago.
  1050. Guus (only because I got a calendar reminder 😉 )
  1051. ralphm 0. Welcome
  1052. ralphm Hope everybody is reconnected, there was a strange disconnect with xmpp.org from here.
  1053. Guus I've seen everyone say something.
  1054. Seve Hi
  1055. MattJ wfm
  1056. ralphm yay
  1057. ralphm 1. Minute taker
  1058. Guus assuming we can't find someone from the floor, I'll do 'm this time
  1059. ralphm Thanks!
  1060. ralphm 2. Badges
  1061. nyco thx
  1062. ralphm I have reached out to mray. He responded and asked the following:
  1063. ralphm “I'd be interested in the kind of combinations that the system needs to cover. Maybe you can break it down for me without the entire context of XMPP compliance. Eventually even a complete set of possible combinations?”
  1064. ralphm Who can create such a list?
  1065. nyco other submissions did that, no?
  1066. Guus combinations of what, exactly?
  1067. nyco each requirements
  1068. Seve Levels of compliance I guess
  1069. ralphm All combinations of thingies to appear in the badges
  1070. ralphm So basically, he did 3 examples, and we now come up with all the combinations we'd like him to construct as actual badges
  1071. Guus from the XEP: > This document defines Categories based on typical use cases (Core, Web, IM, Mobile) and Levels (Core, Advanced) based on functionality in the respective category.
  1072. Guus so, we need each combination of Category with Level, and add a year / edition to it?
  1073. Guus Although Core/Core 2019 seems weird.
  1074. nyco 2019 would be cool
  1075. ralphm He doesn't want to read the document, he just wants: (XMPP LOGO) | CLIENT | Advanced ) IM | 2019 (XMPP LOGO) | SERVER | Advanced ) IM | 2019 etc.
  1076. adiaholic has left
  1077. adiaholic has joined
  1078. ralphm or somesuch
  1079. Guus I'll wrap up a list
  1080. ralphm Thanks!
  1081. ralphm Also thanks nyco fo sending the results out to the list.
  1082. Seve Thank you guys
  1083. nyco in a spreadsheet?
  1084. ralphm maybe
  1085. ralphm 3. Roadmap
  1086. ralphm Apart from this huge discussion this morning, afternoon, I haven't gotten to this.
  1087. ralphm Good progress on the former, though.
  1088. ralphm 4. AOB
  1089. ralphm ?
  1090. MattJ None here
  1091. Guus I've got two
  1092. Seve None here
  1093. ralphm Guus: shoot
  1094. Guus isn't it about time we organize new elections?
  1095. nyco you mean Boris Jonhson?
  1096. ralphm Usually Alex picks this up in September.
  1097. Guus ack.
  1098. nyco missing id
  1099. nyco_ has joined
  1100. ralphm Next Guus?
  1101. Guus 2) I've been approached by https://openvoipalliance.org/ - they're interested in involving XMPP in this.
  1102. nyco has left
  1103. nyco has joined
  1104. Alex yes, elections are on my radar, have a reminder in my cal for Sept. 1st. Will open the application process after our current voting period
  1105. Guus I'd like to see if there's benefit for us in actively becoming a partner in that effort.
  1106. Guus (Thanks Alex)
  1107. ralphm Guus: interesting. I see they already use XMPP and converse.js
  1108. Seve I didn't know about it
  1109. ralphm But yes, I'd be interested to know how they would like us to get involved.
  1110. ralphm Guus: can you send me the e-mail? I'd be happy to follow-up.
  1111. Guus what email? we're talking over XMPP. 🙂
  1112. nyco has left
  1113. ralphm oh hehe
  1114. Seve Niiice :)
  1115. adiaholic has left
  1116. adiaholic has joined
  1117. Guus I'll see if we can arrange for a groupchat of sorts
  1118. ralphm Thanks
  1119. zach has left
  1120. zach has joined
  1121. ralphm Anything else?
  1122. Guus FIN
  1123. ralphm 5. Date of Next
  1124. ralphm +1W
  1125. ralphm 6. Close
  1126. MattJ wfm
  1127. ralphm Thanks all!
  1128. ralphm bangs gavel, and retroactively at the start of the meeting
  1129. Seve I really like this " You can chat with us through our XMPP server to see if your project fits." but would need to check exactly what it is and what can we do
  1130. Seve Thank you for the meeting, glad to see all of you today
  1131. nyco has joined
  1132. nyco thx all
  1133. adiaholic has left
  1134. adiaholic has joined
  1135. lumi has joined
  1136. nyco more glitches from the xmpp.org server?
  1137. Zash Glitches?
  1138. nyco has left
  1139. adiaholic has left
  1140. adiaholic has joined
  1141. matkor has left
  1142. matkor has joined
  1143. Guus ralphm I've updated https://trello.com/c/J97CukTU/358-contact-mray-to-confirm-chosen-badge-design with the requested list of badge element combinations.
  1144. pep. Zash: ip6 issues apparently? Says Ge0rG
  1145. nyco has joined
  1146. Ge0rG The connection hung. Looks like a kick against the tires helped.
  1147. matkor has left
  1148. zach has left
  1149. zach has joined
  1150. matkor has joined
  1151. nyco has left
  1152. adiaholic has left
  1153. adiaholic has joined
  1154. Ge0rG But then it dropped out again.
  1155. nyco has joined
  1156. nyco has left
  1157. adiaholic has left
  1158. adiaholic has joined
  1159. linkmauve has joined
  1160. waqas has left
  1161. Guus https://igniterealtime.org:443/httpfileupload/41c708d3-4197-408d-98a6-3e2d2b5fbfea/image.png
  1162. Guus harhg
  1163. Guus that was _not_ the copy/paste that I intended - sorry
  1164. pep. Features
  1165. Guus PEP mandates filtered-notification support
  1166. adiaholic has left
  1167. adiaholic has joined
  1168. Guus are all PEP services therefor always filtered, or can the feature go unused?
  1169. Ge0rG Instant dick-pic upload!
  1170. patrick has joined
  1171. UsL has joined
  1172. Chobbes has joined
  1173. pdurbin has joined
  1174. zach has left
  1175. zach has joined
  1176. pdurbin has left
  1177. andy has left
  1178. andy has joined
  1179. matkor has left
  1180. matkor has joined
  1181. Chobbes has left
  1182. adiaholic has left
  1183. adiaholic has joined
  1184. eevvoor has joined
  1185. jubalh has left
  1186. zach has left
  1187. madhur.garg has left
  1188. zach has joined
  1189. sonny has left
  1190. ralphm Guus: if you don't have the filtered notification, isn't it just regular pubsub on an account?
  1191. patrick has left
  1192. Guus ralphm: pep adds other restrictions
  1193. ralphm My point is that if you don't do one one these, it is no longer PEP but some other subset of PubSub on an account.
  1194. Guus Right
  1195. ralphm Curious about the use case, though
  1196. Guus Filtering is mandatory then, for pep
  1197. jabberjocke has joined
  1198. Guus No use case. Bug hunting / code reviewing
  1199. Zash Is it PEP if there's no filtered notifications, but instead dynamic presence based subscriptions?
  1200. jabberjocke has left
  1201. jabberjocke has joined
  1202. Guus Can clients even apply such configuration?
  1203. ralphm Well the whole raison-d'être of PEP is not having to explicitly subscribe, so you have auto-subscription + filtering instructions via CAPS.
  1204. ralphm Zash: there's a difference?
  1205. Zash Not in practice
  1206. ralphm Also not in theory?
  1207. Zash Implementation detail I suppose
  1208. ralphm Although I suppose you can think up another magic to get the notifications you want.
  1209. eevvoor has left
  1210. Zash I'd like to have negotiation for the thing ejabberd did, where it'd just ignore your caps and send all notifications
  1211. Zash expecting the receiving end to filter
  1212. ralphm Really? That seems terrible.
  1213. ralphm One of the use cases when PEP was created was User Tunes.
  1214. Guus Not in an environment where you want everyone to get all notifications
  1215. ralphm Initially people would just include that in presence directly.
  1216. zach has left
  1217. UsL has left
  1218. zach has joined
  1219. ralphm So you got presence updates, once per 3 min. for each user.
  1220. Zash If you filter and fork notifications on the receiving server it works, and has some benefits like MAM potential
  1221. Guus Which presumably is less IM, more IOTish
  1222. Zash But this isn't what the PEP XEP says, so it leads to madness.
  1223. Zash Hence why I'd like some opt-in between servers for that
  1224. Guus Note that I was not looking for a XEP change, I was just trying to get clarification.
  1225. ralphm Zash: if you are taking about subscriptions on account level instead of resource level, along with s2s dedupe, that seems like a worthy cause.
  1226. ralphm Especially also for MIX.
  1227. Zash ralphm, yeah
  1228. sezuan has left
  1229. matkor has left
  1230. Zash Not having to keep (a subset of) disco#info for remote entities seems like a nice thing to me as a server dev.
  1231. ralphm As long as information is public that works. And identical between subscribers.
  1232. lovetox has joined
  1233. j.r has joined
  1234. zach has left
  1235. zach has joined
  1236. zach has left
  1237. zach has joined
  1238. eevvoor has joined
  1239. goffi has left
  1240. Steve Kille has left
  1241. Wojtek has joined
  1242. zach has left
  1243. zach has joined
  1244. Wojtek has left
  1245. Steve Kille has joined
  1246. sezuan has joined
  1247. pdurbin has joined
  1248. adiaholic has left
  1249. adiaholic has joined
  1250. Wojtek has joined
  1251. zach has left
  1252. zach has joined
  1253. pdurbin has left
  1254. Wojtek has left
  1255. arc has left
  1256. arc has joined
  1257. matkor has joined
  1258. waqas has joined
  1259. waqas has left
  1260. aj has left
  1261. goffi has joined
  1262. Nekit has left
  1263. sezuan has left
  1264. zach has left
  1265. zach has joined
  1266. eevvoor has left
  1267. jabberjocke has left
  1268. lovetox has left
  1269. lovetox has joined
  1270. zach has left
  1271. zach has joined
  1272. linkmauve has left
  1273. linkmauve has joined
  1274. linkmauve has left
  1275. linkmauve has joined
  1276. sonny has joined
  1277. eevvoor has joined
  1278. zach has left
  1279. zach has joined
  1280. madhur.garg has joined
  1281. karoshi has left
  1282. adiaholic has left
  1283. zach has left
  1284. zach has joined
  1285. zach has left
  1286. zach has joined
  1287. xnamed has joined
  1288. Yagiza has left
  1289. adiaholic has joined
  1290. debacle has joined
  1291. debacle has left
  1292. karoshi has joined
  1293. xalek has left
  1294. adiaholic has left
  1295. adiaholic has joined
  1296. Alex let's start our member meeting in 3 minutes
  1297. zach has left
  1298. zach has joined
  1299. Alex bangs the gavel
  1300. Alex here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2019-08-29
  1301. Alex 1) Call for Quorum
  1302. Alex as you can see 36 members voted via memberbot. So we have a quorum
  1303. Alex 2) Items Subject to a Vote
  1304. Alex new and returning members, you can see the application pages here: https://wiki.xmpp.org/web/Membership_Applications_Q3_2019
  1305. Alex 3) Opportunity for XSF Members to Vote in the Meeting
  1306. Alex anyone here who has not voted yet?
  1307. MattJ Erm, did I?
  1308. Alex Memberbot is still online and will accept votes
  1309. Zash Do it! Do it now!
  1310. Alex MattJ: don't think so
  1311. MattJ Ok, I'm on it
  1312. Alex go for it
  1313. jonas’ oh!
  1314. jonas’ I did vote, didn’t I?
  1315. MattJ I'm done, probably made a massive difference to the outcome :)
  1316. Guus I wonder if Santa is making notes for his naughty list.
  1317. Alex MattJ: have your vote
  1318. ralphm Yay
  1319. Alex anyone else?
  1320. Alex looks like we have all votes
  1321. Alex Will start counting the votes then
  1322. Alex 4) Announcement_of_Voting_Results
  1323. zach has left
  1324. zach has joined
  1325. Zash *drumroll*
  1326. Alex if you reload the page at: https://wiki.xmpp.org/web/Meeting-Minutes-2019-08-29#Announcement_of_Voting_Results you can see the voting results
  1327. Alex all new and returning members are accepted
  1328. Alex congrats to everyone
  1329. Alex very high yes votes,, stands for high quality members
  1330. Alex 5) Any Other Business?
  1331. jonas’ or `yes | send_xmpp.py memberbot@xmpp.org` ;)
  1332. jonas’ congrats to the newly accepted members, Natalie Wirth and Marvin Wissfeld! :)
  1333. jonas’ larma,
  1334. jonas’ .
  1335. Zash Congrats to everyone
  1336. jonas’ No AOB from me
  1337. larma \o/
  1338. Alex just wanna mention that annual elections are coming up
  1339. Ge0rG Alex: what's the timeline?
  1340. Alex will work on the application page soon
  1341. Guus Please consider running!
  1342. Guus and/or motivate others to run.
  1343. eevvoor has left
  1344. Ge0rG I need to ensure my campaign funding
  1345. Alex last year the meeting was November 22nd
  1346. Alex trying to stick close to that, so that board and council has same term length (12 month)
  1347. Guus Sounds reasonable
  1348. Alex see: https://wiki.xmpp.org/web/Meeting-Minutes-2018-11-22
  1349. Ge0rG Natalie and Marvin can take over the Council now
  1350. Alex 6) Formal Adjournment
  1351. Alex I motion that we adjourn
  1352. Zash 👍
  1353. Alex bangs the gavel
  1354. jonas’ wfm
  1355. jonas’ thanks, Alex
  1356. Alex thanks everyone
  1357. jonas’ thanks everyone
  1358. Guus Thanks again, Alex.
  1359. Alex will send out mails tomorrow morning to members and update website and lists
  1360. waqas has joined
  1361. pep. Thanks Alex
  1362. Dele (Mobile) has left
  1363. xalek has joined
  1364. mathieui Thanks Alex
  1365. zach has left
  1366. zach has joined
  1367. matkor has left
  1368. xnamed has left
  1369. waqas has left
  1370. waqas has joined
  1371. xalek has left
  1372. xalek has joined
  1373. APach has left
  1374. APach has joined
  1375. sezuan has joined
  1376. zach has left
  1377. zach has joined
  1378. sezuan has left
  1379. sezuan has joined
  1380. sezuan has left
  1381. sezuan has joined
  1382. eevvoor has joined
  1383. wurstsalat has left
  1384. LNJ has left
  1385. wurstsalat has joined
  1386. lorddavidiii has joined
  1387. lorddavidiii has left
  1388. pdurbin has joined
  1389. pdurbin has left
  1390. zach has left
  1391. zach has joined
  1392. UsL has joined
  1393. xnamed has joined
  1394. jubalh has joined
  1395. zach has left
  1396. zach has joined
  1397. eevvoor has left
  1398. sezuan has left
  1399. sezuan has joined
  1400. sonny has left
  1401. jubalh has left
  1402. linkmauve has left
  1403. jcbrand has left
  1404. Nekit has joined
  1405. sonny has joined
  1406. sonny has left
  1407. sonny has joined
  1408. karoshi has left
  1409. sezuan has left
  1410. jubalh has joined
  1411. lovetox has left
  1412. Nekit has left
  1413. xnamed has left
  1414. xnamed has joined
  1415. jubalh has left
  1416. Tobias has left
  1417. sonny has left
  1418. andy has left
  1419. pdurbin has joined
  1420. jabberjocke has joined
  1421. linkmauve has joined
  1422. pdurbin has left
  1423. sonny has joined
  1424. zach has left
  1425. zach has joined
  1426. goffi has left
  1427. UsL has left
  1428. UsL has joined